[comp.sys.amiga] Wishlist for A3000

sims@stsci.EDU (Jim Sims) (11/02/87)

This is not a lame, but an honest attempt to try to steer Commodore in the
direction that Amiga owners want to go.

 I think a lot (evan a little!) prior planning and input from the USERS
(that's CUSTOMERS to you marketing types) would go a long way toward:

 (1) Better machines for US

 (2) More SALES for commodore


 After seeing all the flames and dissappointment from the release of the 2000,
I think it's up to US to speak out in a positive way to insure the next
generation is what we want.

So, my list looks like this:

 (1) Use the 68030 CPU (sample quantities are available now)

 (2) Incorporate changes in ADOS to allow VIRTUAL memory

 (3) Use the NUBUS (I think apple made a pretty good choice and compatibility
                    would only hurt IBM) (have you looked at uChannel? sick!)

 (4) Built-in SCSI or ESMD controller (DMA, please)

 (5) 256 out of 16 meg colors (current industry standard IS good enough)

That's my top five. I don't think COST is TERRIBLY important. I'd buy the
above if it cost comparable to the MAC II.

P.S. Un*x support would be nice also. (notice I said nice, not req)

Lets let Commodore know what we want and what we'll pay. Otherwise, we
have only US to blame if they leave out YOUR favorite item.
-- 
            Jim Sims
            Space Telescope Science Institute
            Baltimore, Md. 21218
            sims@stsci.edu

cmcmanis%pepper@Sun.COM (Chuck McManis) (11/08/87)

[Apologies in advance if anyone is offended by this posting.]

In article <74@mithras> sims@stsci.EDU (Jim Sims) writes:
# This is not a lame, but an honest attempt to try to steer Commodore in the
# direction that Amiga owners want to go.
# So, my list looks like this:
#  (1) Use the 68030 CPU (sample quantities are available now)
    Would you settle for a 20Mhz '020?
#  (2) Incorporate changes in ADOS to allow VIRTUAL memory
    No problem, but it ain't ADOS.
#  (3) Use the NUBUS (I think apple made a pretty good choice and compatibility
#                     would only hurt IBM) (have you looked at uChannel? sick!)
    How about VME Bus?
#  (4) Built-in SCSI or ESMD controller (DMA, please)
    Got this one covered.
#  (5) 256 out of 16 meg colors (current industry standard IS good enough)
    Check.
# That's my top five. I don't think COST is TERRIBLY important. I'd buy the
# above if it cost comparable to the MAC II.
    What if it cost just a teeny bit more?
# P.S. Un*x support would be nice also. (notice I said nice, not req)
    This ones easy.
# Lets let Commodore know what we want and what we'll pay. Otherwise, we
# have only US to blame if they leave out YOUR favorite item.

You know where I'm leading don't you? You guessed it, we're talking 
workstation here, how about a Sun 3/60? $12K mono, $19K color? 4meg + ethernet
+ 19" monitor etc.

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

Wishing won't make it happen, damn good engineering might, lower costs
definitely would. Anyway, workstations are getting cheaper so don't
give up hope it will just take a while longer...

Note I work for Sun so I am biased. 

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

jimm@mitsumi.UUCP (Jim Mackraz) (11/08/87)

In article <33314@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
)[Apologies in advance if anyone is offended by this posting.]
)
)In article <74@mithras> sims@stsci.EDU (Jim Sims) writes:
)# This is not a lame, but an honest attempt to try to steer Commodore in the
)# direction that Amiga owners want to go.
)# So, my list looks like this:
)# [ ... items ... ]
)    No problem
)# [ ... items ... ]
)    Got this one covered.
)# [ ... items ... ]
)    Check.

)You know where I'm leading don't you? You guessed it, we're talking 
)workstation here, how about a Sun 3/60?
):-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 
)Note I work for Sun so I am biased. 
)--Chuck McManis
)These opinions are my own and no one elses, but you knew that didn't you.

Ah, Chuck, but he said AMIGA 3000.  So it went without saying that
he also wants lots of standard equipment which can be assumed by all
software written for the machine.

-Standard color, at least a *majority* of color systems.
-full-logic blitter in every single box
-dma stereo audio, with RCA jacks
-beam-syned coprocessor
-upwards compatible with mass-distributed inexpensive machine to
 insure lots of low-cost sotware, especially games (FirePower
 in particular?)
-slots (is a Sun 3/60 the little one with <2 slots?)
-relatively cheap peripherals

All in good fun, Chuck.  But it leads to an observation that
might provoke thought: I don't think the of the (current) Amiga as a
workstation, but it's increasingly more like a workstation than a
workstation will *ever* be like an Amiga.  (Which is, I suspect, why
we have you around, guy.)

I'd say the key point is the fifth item listed above.  Why I want an
Amiga workstation: good machine for writing A500 software.  Then
again, a Sun works pretty well for this, as I recall.

	jimm

-- 
	Jim Mackraz
	Mitsumi Technology, Inc.		408/980-5422
	{amiga,pyramid}!mitsumi!jimm

richard@gryphon.UUCP (11/09/87)

In article <33314@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>[Apologies in advance if anyone is offended by this posting.]
>
>In article <74@mithras> sims@stsci.EDU (Jim Sims) writes:
># This is not a lame, but an honest attempt to try to steer Commodore in the
># direction that Amiga owners want to go.
># So, my list looks like this:
>#  (1) Use the 68030 CPU (sample quantities are available now)
>    Would you settle for a 20Mhz '020?

Only in a pinch. What I'd really like is the fastest 68030 available, or,
barring that, a reasonably fast 68030 in a *circuit that was spec'ed* to handle
the fastest 68030 available. Swapping chips is pretty popular, and if the
circuit can handle a faster CPU just by swapping one in, plus some pals,
memory, and perhaps *some* glue, that would be one hell of an upgrade
path.

Or a 25 mhz '020...
 
>#  (3) Use the NUBUS (I think apple made a pretty good choice and compatibility

 only hurt IBM) (have you looked at uChannel? sick!)
>    How about VME Bus?

No chance. Too expensive to buy cards for it. I'm really not crazy about
nubus, but the thought of walking into any apple dealers and buying some
of them cheap apple peripherals is a nice idea. Lets exploit their economy 
of scale.

>    Got this one covered.

Mandatory. Hard disks arn't a luxury any more.

>#  (5) 256 out of 16 meg colors (current industry standard IS good enough)
>    Check.

Not bad. But I'd like to see other configurations, like 16 Meg
simultaneous colors (optional) and higher resolutions available
as 'other' video modes. I think the NTSC compatability has done
wonders for the Amiga, and don't ever want to see it go away,
but, if you HAVE the monitor, it'd be nice to be able to tell
the darned thing to pump out 1K by 800 noninterlaced.

># That's my top five. I don't think COST is TERRIBLY important. I'd buy the
># above if it cost comparable to the MAC II.
>    What if it cost just a teeny bit more?

Nahh. Mac ][ is overpriced.

># P.S. Un*x support would be nice also. (notice I said nice, not req)
>    This ones easy.
># Lets let Commodore know what we want and what we'll pay. Otherwise, we
># have only US to blame if they leave out YOUR favorite item.
>
>You know where I'm leading don't you? You guessed it, we're talking 
>workstation here, how about a Sun 3/60? $12K mono, $19K color? 4meg + ethernet
>+ 19" monitor etc.
>
>:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

Apollo's are cheaper :-)

>
>Wishing won't make it happen, damn good engineering might, lower costs
>definitely would. Anyway, workstations are getting cheaper so don't
>give up hope it will just take a while longer...
>
>Note I work for Sun so I am biased. 

Note I work for an Apollo HW/SW house and could'nt let Chuck get away 
with this :-)

>--Chuck McManis


-- 
Richard J. Sexton
INTERNET:     richard@gryphon.CTS.COM
UUCP:         {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard

"It's too dark to put the keys in my ignition..."

grr@cbmvax.UUCP (George Robbins) (11/11/87)

In article <74@mithras> sims@stsci.EDU (Jim Sims) writes:
> This is not a lame, but an honest attempt to try to steer Commodore in the
> direction that Amiga owners want to go.
> 
>  I think a lot (evan a little!) prior planning and input from the USERS
> (that's CUSTOMERS to you marketing types) would go a long way toward:
> 
>  (1) Better machines for US
>  (2) More SALES for commodore

These are good things.
 
>  After seeing all the flames and dissappointment from the release of the 2000,
> I think it's up to US to speak out in a positive way to insure the next
> generation is what we want.

There have been a lot of flames and some expressions of dissapointment here,
but don't assume that this represents the universal opinion.  Lots of people,
A1000 owners among them have been buying A2000's.  Some of them even think
that the A2000 is a good idea and might even be better than the A1000!

> So, my list looks like this:
> 
>  (1) Use the 68030 CPU (sample quantities are available now)

	At the current pricing, the 68030 costs almost one hundred times
	the price of a 68000 and several times that of a 68020.  In time
	it will come down, but you probably won't see an affordable 68030
	based system for another year or so, regardless of any Atari smoke...
 
>  (2) Incorporate changes in ADOS to allow VIRTUAL memory

	A good idea, but fairly difficult.  Of course you want virtual memory
	without overhead.  Note that most of the people who want big memory
	aren't running one big program, rather they want to have a lot of
	programs resident and a big ramdisk, etc.  The availability of cheap
	hard drives should ease the need for this memory hogging.
 
>  (3) Use the NUBUS (I think apple made a pretty good choice and compatibility
>                     would only hurt IBM) (have you looked at uChannel? sick!)

	We would get shot.  The A2000 bus may not be fancy, but it gets the
	job done.  Changing it again, just when A2000 format I/O cards are
	starting to be available would be silly.  Perhaps some compatible
	extension is needed for 32-bits, or maybe it should be considered
	a 16-bit I/O bus, with 32-bit memory plugged in elsewhere.

>  (4) Built-in SCSI or ESMD controller (DMA, please)
 
	No problem.  Do you mean ESMD or ESDI?  Personally, I've got hundreds
	of megabytes of SMD disk at home, but I'm not sure this would be a
	big seller.

>  (5) 256 out of 16 meg colors (current industry standard IS good enough)

	Uh, it's a good starting point, however one needs to give attention
	to making it extensible, rather than designing in something that seems
	adequate, but can't be enhanced in a compatible fashion.

> That's my top five. I don't think COST is TERRIBLY important. I'd buy the
> above if it cost comparable to the MAC II.

	If Commodore *ever* sells something as overpriced as the typical
	Apple product, we deserve to be shot.
 
> P.S. Un*x support would be nice also. (notice I said nice, not req)

	No problem.  8-)

> Lets let Commodore know what we want and what we'll pay. Otherwise, we
> have only US to blame if they leave out YOUR favorite item.

	I don't mean to criticize your ideas, just to bring up some of the
	arguments surrounding them.  I think you might want to give some thought
	to whether you are trying to define a high-dollar workstation with a
	Commodore nametag on it, or an affordable computer system that can do
	all the things that a brand-x workstation can do today...

-- 
George Robbins - now working for,	uucp: {ihnp4|rutgers|allegra}!cbmvax!grr
but no way officially representing	arpa: out to lunch...
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

klm@munsell.UUCP (11/12/87)

In article <2213@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
>
>Or a 25 mhz '020...

YEAH YEAH!!  (slobber slobber drool drool)

>
>Mandatory. Hard disks arn't a luxury any more.

Got that right.  Unfortunately a lot of us who would *love* to drive a
Porsche are, through financial necessity, stuck with a Hyundai.

Necessary equipment.  Luxury prices. (whimper)

>
>Not bad. But I'd like to see other configurations, like 16 Meg
>simultaneous colors (optional) and higher resolutions available
>as 'other' video modes.

Higher res, yes!  16 meg colors?  WHY??!!  Your eye can't see that many!
Granted that for doing real image processing you need that precision
internally (8 bits each of R,G, and B; or uvL or what have you), but for
display purposes you only need between 2K and 4K colors to get excellent
results on a HIGH RES monitor (at least 1K x 1K.)  Any more colors than that
and you go into overkill mode, which makes your hardware very expensive.
Yes, there are 24 bit frame buffers out there.  Check out the price tag on
one sometime.  Quite a bit more than you paid for your Amiga.

IMHO, you can get just as good display quality with 12 bits out, IF you know
what you are doing.  (i.e., you need to do a little bit more than just linear
compression through a hardware LUT.)  We do something similar to that on the
display section of our electronic publishing system.  We use full color
imagery.  Our display is less than 24 bits and it looks very very good.

Of course, having your monitor calibrated to a reference standard, and having
your software calibrated to your monitor helps too. :-)

-- 
Kevin McBride, the guy in the brace //       | Your mind is totally controlled
Eikonix - A Kodak Co.              //        | It has been stuffed into my mold
Billerica, MA                  \\ //  Amiga  | And you will do as you are told
{encore,adelie}!munsell!klm     \X/   Rules! | until the rights to you are sold

peter@sugar.UUCP (Peter da Silva) (11/13/87)

>  (5) 256 out of 16 meg colors (current industry standard IS good enough)

That's not good enough. You need at least 1024 very carefully selected colors
to get good video for arbitrary scenes. HAM with 4096 is good enough since
most pictures don't require arbitrary croma changes on a pixel basis.

How about 8-bit HAM? Be hard, since 16M = 256x256x256. Something might be
worked out.

68020 would be enough for me. Keep the 68030 for the A5000 (or maybe use the
SPARC? It's got 68000 emulation, no?).
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.

peter@sugar.UUCP (Peter da Silva) (11/13/87)

In article <74@mithras>, sims@stsci.EDU (Jim Sims) writes:
>  (2) Incorporate changes in ADOS to allow VIRTUAL memory

How about just supporting memory managment.

I'm leary of VM on the Amiga. It's a real-time system, you know. The only
personal computer that is. Virtual memory and real-time don't get along.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.

mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (11/13/87)

In article <2729@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
<>  (3) Use the NUBUS (I think apple made a pretty good choice and compatibility
<>                     would only hurt IBM) (have you looked at uChannel? sick!)
<
<	We would get shot.  The A2000 bus may not be fancy, but it gets the
<	job done.  Changing it again, just when A2000 format I/O cards are
<	starting to be available would be silly.  Perhaps some compatible
<	extension is needed for 32-bits, or maybe it should be considered
<	a 16-bit I/O bus, with 32-bit memory plugged in elsewhere.

Probably. On the other hand, the options seem to be:

	1) Coming out with a 16 bit A3000 next year. You'd do
	*well* to get shot.

	2) Come out with a 16 bit A3000 in '89. You'd be laughed out
	of the market.

	3) Come out with a 32-bit processor on a 16-bit bus. Why does
	"obsolete at announcement" come to mind?

	4) As you suggested, a dual-bus machine, one Zorro ][, one 32
	bits wide. Even if you make it "for memory", if you have more
	than one slot in it, people will be tempted to market "32-bit"
	I/O cards. Only one slot will leave people with the "What do I
	do with the old memory card" syndrome. Hmm - maybe going with
	Zorro ][ and SIMS, aka the Mac ][?

	5) Going with a real 32-bit bus. This is the *serious* way to
	go. I'd suggest VME, not NuBus. That would provide an upgade
	path to SUNs and the like for your customers. Of course, you'd
	get shot if you failed to provide some Zorro ][ slots in the
	box for an upgrade path. Look where this kind of baroque
	architecture got DEC - #2 computer company worldwide.

<> That's my top five. I don't think COST is TERRIBLY important. I'd buy the
<> above if it cost comparable to the MAC II.
<
<	If Commodore *ever* sells something as overpriced as the typical
<	Apple product, we deserve to be shot.

If Commodore starts designing Amiga without keeping cost strictly in
mind, they're going to wind up getting creamed by Sun & it's
competion.

<> P.S. Un*x support would be nice also. (notice I said nice, not req)
<
<	No problem.  8-)

Ah, but *which* Unix? I want MACH! Or maybe V8 (V9?). None of the
stuff that AT&T employees call Sh*tlix, or that's suffering from
Berkeley Brain Damage.

	<mike
--
I know the world is flat.				Mike Meyer
Don't try tell me that it's round.			mwm@berkeley.edu
I know the world stands still.				ucbvax!mwm
Don't try to make it turn around.			mwm@ucbjade.BITNET

daveh@cbmvax.UUCP (Dave Haynie) (11/13/87)

in article <5888@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) says:
> Keywords: Commodore A3000 Do it RIGHT!
 
> Probably. On the other hand, the options seem to be:
> 
> 	1) Coming out with a 16 bit A3000 next year. You'd do
> 	*well* to get shot. [and two identical stupid suggestions]

Yes, stupid!  Only PClones can get away with a 16 bit bus on a 32 bit
machine.  Even IBM wasn't foolish enough to go that route.
> 
> 	4) As you suggested, a dual-bus machine, one Zorro ][, one 32
> 	bits wide. Even if you make it "for memory", if you have more
> 	than one slot in it, people will be tempted to market "32-bit"
> 	I/O cards. 

There shouldn't be a problem with a 16/32 bit bus.  It's real easy, from a
hardware point of view, to detect the buswidth of the card in question, and
act accordingly, at the expected bus speed.  I'm real surprised that IBM
never did this with their 8 bit cards on their 32 bit machines, though IBM
has never had a rep for doing things right.

> 	5) Going with a real 32-bit bus. This is the *serious* way to
> 	go. I'd suggest VME, not NuBus. 

They're both TOO slow, especially NuBus.   And VME is far too expensive,
and certainly not upward compatible.

> 	path to SUNs and the like for your customers. 

I don't particularly want customers going to Sun, I'd rather keep them here.
Even Sun had to augment VME to run memory as fast as they wanted it, and 
things like that that are viable on a $10,000 machine aren't viable on a
$2000 machine.  But that's OK, cause I can design a faster bus that's also
cheaper, and also supports old Zorro cards.  You might not like it, but
90% of current Amiga users will, and that's what I'm concerned with.  

> <	If Commodore *ever* sells something as overpriced as the typical
> <	Apple product, we deserve to be shot.
> 
> If Commodore starts designing Amiga without keeping cost strictly in
> mind, they're going to wind up getting creamed by Sun & it's
> competion.

Re-read your posting.  WE understand the last paragraph.  Even though you
wrote it, YOU don't.  Or you never would have suggested the VME bus with
Sun extensions.

> <> P.S. Un*x support would be nice also. (notice I said nice, not req)
> <	No problem.  8-)
> 
> Ah, but *which* Unix? I want MACH! Or maybe V8 (V9?). None of the
> stuff that AT&T employees call Sh*tlix, or that's suffering from
> Berkeley Brain Damage.

But you've already said that you're going to do the Mach port to your
'486 machine which doesn't exist yet, if no one else will port it.  I
really like Mach, but it's not Unix, is it.  Unix is V from AT&T or
BSD4, and you don't like either of these.  So you really don't want
Unix either, do you.

> 	<mike

> I know the world is flat.
> Don't try tell me that it's round.

Ahh, now I understand.  And it's not round, it's roughly spherical.
-- 
Dave Haynie     Commodore-Amiga    Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh
   "The B2000 Guy"              PLINK : D-DAVE H             BIX   : hazy
    "Computers are what happen when you give up sleeping" - Iggy the Cat

richard@gryphon.CTS.COM (Richard Sexton) (11/15/87)

In article <5888@jade.BERKELEY.EDU> Mike (My watch has windows) Meyer) writes:
>In article <2729@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
><>  (3) Use the NUBUS 
>
>	5) Going with a real 32-bit bus. This is the *serious* way to
>	go. I'd suggest VME, not NuBus. That would provide an upgade
>	path to SUNs and the like for your customers. Of course, you'd
>	get shot if you failed to provide some Zorro ][ slots in the
>	box for an upgrade path. Look where this kind of baroque
>	architecture got DEC - #2 computer company worldwide.

Huh ? With the Mac ][ using NuBus, won't that make for cheaper (NuBus)
peripherals than VME bus ?
>
>	<mike


-- 
Richard J. Sexton
INTERNET:     richard@gryphon.CTS.COM
UUCP:         {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard

"It's too dark to put the keys in my ignition..."

richard@gryphon.CTS.COM (Richard Sexton) (11/15/87)

In article <1364@squeaker.munsell.UUCP> squeaky wierd Kevin sez:
>In article <2213@gryphon.CTS.COM> I blathered:
>>
>>
>>Mandatory. Hard disks arn't a luxury any more.
>
>Got that right.  Unfortunately a lot of us who would *love* to drive a
>Porsche are, through financial necessity, stuck with a Hyundai.
>
>Necessary equipment.  Luxury prices. (whimper)

Good point. What i *meant* was that the circuitry to support
hard drives should be standard (ok, if thats to expensive, leave the
damn chips out, just provide the  circuit, and sockets, I'll
stick in the disk controller chip(s) and hook up a drive)

>>Not bad. But I'd like to see other configurations, like 16 Meg
>>simultaneous colors (optional) and higher resolutions available
>>as 'other' video modes.
>
>Higher res, yes!  16 meg colors?  WHY??!!  Your eye can't see that many!

Well, I;m certainly not going to argue color with a guy from Eikonix,
especially one in a bad mood because he can't go skiing.

But.

That number of colors would be required to represent what is
generally accepted to be "true color". To be able to image
ANYTHING, you need that many colors. To do continuous
tone bleeds form one color to another you need a lot of colors
and and and and...

Hey, dammit, I'm the customer, I have 16 Meg colors on other machines,
I want 16 meg colors on my next amiga. Now granted, not everybody
might, ok, start with a baseline of 4 or 8 planes, and LET THE
USER ADD BITPLANES by just stuffing in some chips or SIMS or
whatever.

>Granted that for doing real image processing you need that precision
>internally (8 bits each of R,G, and B; or uvL or what have you), but for
>display purposes you only need between 2K and 4K colors to get excellent
>results on a HIGH RES monitor (at least 1K x 1K.)  Any more colors than that

Huh ? Depends on the width of the dacs. We have 4K colors right now,
but I only have 16 shades of blue at my disposal.

Yes, I know I can play games like:

(0,0,1) (1,0,1) (0,1,1) (0,0,2) etc...

to do continuous tone transition of black to bright blue, and I have done
this, but you can tell. You see a blue band, then a greenish-blue band,
then a reddish-blue band, than another blue band etc. So it's not
the number of colors, but the width of the dacs.

Systems with 8 planes, but 8-bit dacs, can do some spectacular stuff.

>We do something similar to that on the
>display section of our electronic publishing system.  We use full color
>imagery.  Our display is less than 24 bits and it looks very very good.

Oh yeah, so tell us how. Unless of course it's proprietry. In which case
just email it to me :-)

>Of course, having your monitor calibrated to a reference standard, and having
>your software calibrated to your monitor helps too. :-)

You're no fun. Trying to guess what color your print-out or slide
is going to come out is half the fun.

>Kevin McBride


-- 
Richard J. Sexton
INTERNET:     richard@gryphon.CTS.COM
UUCP:         {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard

"It's too dark to put the keys in my ignition..."

grr@cbmvax.UUCP (George Robbins) (11/15/87)

In article <5888@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes:
> 
> 	5) Going with a real 32-bit bus. This is the *serious* way to
> 	go. I'd suggest VME, not NuBus.

You're kidding, right?  Have you looked the prices on those VME bus cards?
Sure we could make all our own stuff, but you need DIN connectors, fancy
hardware and wierd protocol chips.  And when all is said and done, you
can't really put your memory on the bus cause its too slow.  Did you want
the normal dinky cards, or the Sun type double height/triple width jobs?

> 	                                            Of course, you'd
> 	get shot if you failed to provide some Zorro ][ slots in the
> 	box for an upgrade path.

The real choices seem to be between a plug compatible 32-bit extension
to the Zorro-II bus or a separate 32-bit memory area of some sort.
There are many arguments/tradoffs to be considered in either case.
 
> Ah, but *which* Unix? I want MACH! Or maybe V8 (V9?). None of the
> stuff that AT&T employees call Sh*tlix, or that's suffering from
> Berkeley Brain Damage.

I'll make you a deal:  If you can persuade AT&T to give us V9, I'll
try real hard to get it ported.  Unfortunatly, beyond that I'm not
permitted to comment at this point - the BSD vs. SVRx arguments are
pretty well known, even here...

-- 
George Robbins - now working for,	uucp: {ihnp4|rutgers|allegra}!cbmvax!grr
but no way officially representing	arpa: out to lunch...
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

keithd@cadovax.UUCP (Keith Doyle) (11/17/87)

In article <1364@squeaker.munsell.UUCP> klm@squeaker.UUCP (Kevin [Being Weird Isn't Enough] McBride) writes:
>Higher res, yes!  16 meg colors?  WHY??!!  Your eye can't see that many!
>Granted that for doing real image processing you need that precision
>internally (8 bits each of R,G, and B; or uvL or what have you), but for
>display purposes you only need between 2K and 4K colors to get excellent
>results on a HIGH RES monitor (at least 1K x 1K.)  Any more colors than that
>and you go into overkill mode, which makes your hardware very expensive.
>Yes, there are 24 bit frame buffers out there.  Check out the price tag on
>one sometime.  Quite a bit more than you paid for your Amiga.
>
>IMHO, you can get just as good display quality with 12 bits out, IF you know
>what you are doing.  (i.e., you need to do a little bit more than just linear
>compression through a hardware LUT.)  

Uh, I beg to differ.  Think about it.  4k colors are 4 bits each for
R G and B.  16 levels of grey scale is the bare acceptable minimum.
While with 4 bits each of R G B, you can get a full 16 shades of 7 colors,
i.e. red, green, blue, cyan, magenta, yellow, and white, you will be
hard pressed to get a "tinted" greyscale of "bluish-purple" or "purplish-
red" (for example) that presents a smooth scale.

No, 4k is definately NOT ENOUGH.  I don't know just how much *is* enough,
but it ain't 4096.

BTW, doesn't the Mimetics 24 bit 640x400 frame buffer come in at $700-$800?
If that's "quite a bit more than you paid for your Amiga", I'd like to know
where you bought your Amiga.  

Keith Doyle
#  {ucbvax,decvax}!trwrb!cadovax!keithd  Contel Business Systems 213-323-8170

mwm@eris.UUCP (11/17/87)

In article <2762@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
<in article <5888@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) says:
<> Keywords: Commodore A3000 Do it RIGHT!
< 
<> Probably. On the other hand, the options seem to be:
<> 
<> 	1) Coming out with a 16 bit A3000 next year. You'd do
<> 	*well* to get shot. [and two identical stupid suggestions]
<
<Yes, stupid!  Only PClones can get away with a 16 bit bus on a 32 bit
<machine.  Even IBM wasn't foolish enough to go that route.

Stupid indeed. Then again, I was listing all the options. But after
the Zorro I/Zorro ][ change, I wouldn't put them past CBM.

<There shouldn't be a problem with a 16/32 bit bus.

Except for getting CBM to market something done that well a second time.

<They're both TOO slow, especially NuBus.   And VME is far too expensive,
<and certainly not upward compatible.

I'm sure CBMs capability for building things cheap could overcome VME
being to expensive.

<> 	path to SUNs and the like for your customers. 
<
<I don't particularly want customers going to Sun, I'd rather keep them here.

Right - never mind what's good for the customer, let's make sure that
we're going to make lots of money.

<But that's OK, cause I can design a faster bus that's also
<cheaper, and also supports old Zorro cards.  You might not like it, but
<90% of current Amiga users will, and that's what I'm concerned with.  

Oh, I believe you can design it. I'd even like it. But can you
convince CBM to sell it?

<> <> P.S. Un*x support would be nice also. (notice I said nice, not req)
<> <	No problem.  8-)
<> 
<> Ah, but *which* Unix? I want MACH! Or maybe V8 (V9?). None of the
<> stuff that AT&T employees call Sh*tlix, or that's suffering from
<> Berkeley Brain Damage.
<
<But you've already said that you're going to do the Mach port to your
<'486 machine which doesn't exist yet, if no one else will port it.

Unless something really nifty comes along, I expect to wind up working
on that. But something really nifty came along once; it might come
along again.

<I really like Mach, but it's not Unix, is it.

Depends on how you define Unix. All the 4.3 utilities run on Mach. You
can put 4.3 device drivers into Mach (nuts, most of Mach's device
drivers are *from* 4.3!). It even takes a license from AT&T to run it.
Sure looks like a Unix to me.

<Unix is V from AT&T or BSD4, and you don't like either of these.

You've been listening to to many lawyers. Unix is anything that
supports the v7 system call interface - ptrace and the mpx cruft + a
reasonable extension to the tty interface.

<So you really don't want Unix either, do you.

Well, what you call Unix is now 15+ years old, and has been collecting
cruft since v7. Fortunately, there are several rewrites from the
ground up that are what I call Unix. Most of those don't suffer from the
creeping featurism rampant in what you call Unix. Some of them are
available for cheap/free.

	<mike

klm@munsell.UUCP (11/17/87)

In article <1053@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:

>How about just supporting memory managment.

>I'm leary of VM on the Amiga. It's a real-time system, you know. The only
>personal computer that is. Virtual memory and real-time don't get along.

Peter, You have a clue!!!

I was wondering when somebody was finally going to bring this up.

Try running real time applications on a VAX under VMS.  Especially things
like high speed data collection.  You end up dropping a lot of data on the
floor.  On the other hand, a lowly 16-bit DG Eclipse running RDOS will do a
wonderful job for you.  The problem is that the development environment is
a real bitch to live with.

So, where are you going to make your tradeoffs?  You can't have your address
space and use it too.

-- 
Kevin McBride, the guy in the brace //       | Your mind is totally controlled
Eikonix - A Kodak Co.              //        | It has been stuffed into my mold
Billerica, MA                  \\ //  Amiga  | And you will do as you are told
{encore,adelie}!munsell!klm     \X/   Rules! | until the rights to you are sold

kent@xanth.UUCP (11/18/87)

In article <1871@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
>In article <1364@squeaker.munsell.UUCP> klm@squeaker.UUCP (Kevin [Being Weird Isn't Enough] McBride) writes:
>>Higher res, yes!  16 meg colors?  WHY??!!  Your eye can't see that many!
>>Granted that for doing real image processing you need that precision
>>internally (8 bits each of R,G, and B; or uvL or what have you), but for
>>display purposes you only need between 2K and 4K colors to get excellent
>>results on a HIGH RES monitor (at least 1K x 1K.)  Any more colors than that
>>and you go into overkill mode, which makes your hardware very expensive.
[...]
>
>Uh, I beg to differ.  [...]
>No, 4k is definately NOT ENOUGH.  I don't know just how much *is* enough,
>but it ain't 4096.

I remember a demonstration from an old SIGGRAPH publication of an
effect called Mach banding, in which a continuous color sweep in x,
constant in y, seemed to have vertical bands through the picture.  To
get rid of this effect took between seven and eight bits per color gun
depending on the observer.  This is a measure of the color sensitivity
of the human eye.  You probably can't give names to the 16 million
colors, or say whether two isolated blocks are the same or different,
but if you don't have that much color resolution, your eye can
definitely find artifacts due to the bandwidth limitations.

Moral, 4K is NOT "enough"; however, 4K is reasonable for an affordable
machine; that is for the hardware.  It would be nice, but probably not
cost effective, for Intuition to directly support 24 or 32 bit add-on
frame buffers, for those who want quality no matter what the cost, but
think the Amiga is mostly where quality is these days.

Kent, the man from xanth.

"Of course I'm coming. ...  When you leave, the average level of
intelligence will rise six points.  I wouldn't be able to live in so
lofty an atmosphere."  -- "Things in their Season", _High Crimes and
Misdemeanors_, Joanne Greenberg

wolf@ssyx.UUCP (11/19/87)

In article <1382@squeaker.munsell.UUCP> klm@squeaker.UUCP (Kevin [Being Weird Isn't Enough] McBride) writes:
>In article <1053@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>
>>How about just supporting memory managment.
>
>>I'm leary of VM on the Amiga. It's a real-time system, you know. The only
>>personal computer that is. Virtual memory and real-time don't get along.
>
>Try running real time applications on a VAX under VMS.  Especially things
>like high speed data collection.  You end up dropping a lot of data on the
>floor.  On the other hand, a lowly 16-bit DG Eclipse running RDOS will do a
>wonderful job for you.  The problem is that the development environment is
>a real bitch to live with.
>

I've done high speed data collection on a micro-vax.  It worked okay.  The
problem isn't VM, but not having enough real memory.  The micro-vax I was
using had enough memory so it wasn't page swaping all the time.  A well
writen VM system won't slow you down when you have enough memory, and it'll
let you use more memory then you have when you need to.  You should only be
getting a noticable speed drop when you are using more memory then you
really have.  I'd rather use a big application slowly then not be able to 
use it at all.

>Kevin McBride

+------------------------------------+---------------------------------------+
|        Michael Wolf                | An old Scandinavian quote:            |
|  BITNET: wolf@ucscj.BITNET         |   "You can lead a herring to water,   |
|  ARPA:   wolf@ssyx.ucsc.edu        |    but you have to walk real fast,    |
|  UUCP: ...ucbvax!ucscc!ssyx!wolf   |    or else he'll die."                |
+------------------------------------+---------------------------------------+

alex@.UUCP (Alex Laney) (11/19/87)

> > 
> >  (1) Use the 68030 CPU (sample quantities are available now)
> 

ME>  I hope that 68030 issues are examined for v1.3 Dos/Exec. I would love to
     get an '030 someday. Is the on-chip MMU fast? I love the on-chip 128k
     cache!

> >  (2) Incorporate changes in ADOS to allow VIRTUAL memory
> 	A good idea, but fairly difficult.  Of course you want virtual memory
 > 	without overhead.  Note that most of the people who want big memory
> 	aren't running one big program, rather they want to have a lot of
> 	programs resident and a big ramdisk, etc.  The availability of cheap
> 	hard drives should ease the need for this memory hogging.

ME>  I think what is desired is really some sort of paging, which is implicit
     in virtual memory systems. So you could have lots of programs resident,
     which would fight a lot for resources, but their needs would be somewhat
     smaller. Of course, Chip Ram sort of throws this idea a bit...

>  
> >  (3) Use the NUBUS (I think apple made a pretty good choice and compatibility
> 
> 	We would get shot.  The A2000 bus may not be fancy, but it gets the
> 
ME> Someone with the initials mwm maybe?

> >  (4) Built-in SCSI or ESMD controller (DMA, please)

ME> The current hard-disk MOS chip should be migratable to the mother board
    at some point. But what people want more is the cost of the Commodore
    A2090 to drop in price. It is a little high, but it does give you a lot
    of capability. In other words, maybe a simpler built-in drive controller
    would be popular.
> 
> >  (5) 256 out of 16 meg colors (current industry standard IS good enough)
> 
> 	Uh, it's a good starting point, however one needs to give attention
> 	to making it extensible, rather than designing in something that seems
> 	adequate, but can't be enhanced in a compatible fashion.

ME> As long as it doesn't break what already exists!

-- 
Alex Laney   alex@xicom.UUCP   ...utzoo!dciem!nrcaer!xios!xicom!alex
Xicom Technologies, 205-1545 Carling Av., Ottawa, Ontario, Canada
We may have written the SNA software you use.
The opinions are my own.

sean@ms.uky.edu (Sean Casey) (11/19/87)

In article <1382@squeaker.munsell.UUCP> klm@squeaker.UUCP (Kevin [Being Weird Isn't Enough] McBride) writes:

[concerning lack of viability of real time applications under VM]

>Try running real time applications on a VAX under VMS.  Especially things
>like high speed data collection.  You end up dropping a lot of data on the
>floor.  On the other hand, a lowly 16-bit DG Eclipse running RDOS will do a
>wonderful job for you.  The problem is that the development environment is
>a real bitch to live with.

Where I work I do programming on a Masscomp 5500 running Real Time Unix
version 3.0A.  RTU supports real time applications, and does it quite well,
thus showing it can be done.  All one really has to do is give the user
system calls to lock memory and a priority system that allows a process
to take over the machine.


Sean
-- 
--  Sean Casey               sean@ms.uky.edu, {rutgers,uunet,cbosgd}!ukma!sean
--  (the Empire guy)         sean@ms.uky.csnet,  sean@UKMA.BITNET
--  University of Kentucky in Lexington Kentucky, USA
--  "Inconceivable!"