Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long)

[Dave Haynie]

In article <1991Mar22.053324.8867 at kessner.denver.co.us> david at kessner.denver.co.us (David D. Kessner) writes:
>In article <20030 at cbmvax.commodore.com> daveh at cbmvax.commodore.com (Dave Haynie) writes:
>>In article <1991Mar20.100122.1717 at kessner.denver.co.us> david at kessner.denver.co.us (David D. Kessner) writes:

>Hmmm.  On the original AT, it was found that using a busy loop rather than 
>DMA was faster (although I forgot the exact reason for this).  

The reason is you're not talking about real DMA here.  Read on...

>To the best of my knoledge, all controllers have the ability to do DMA 
>transfers, but the controller BIOS has ultamate say as to which method is 
>used.  

Only the high end of PC bus controllers, usually SCSI things on a EISA or MCA
bus, do real DMA.  What you're thinking of is "DMA" using the standard PC
DMA controller rather than the CPU.  This DMA controller was faster than a
busy PIO loop on an 8088 machine.  Not because it ran bus cycles any faster;
it didn't.  But it pretty much eliminated the overhead of the PIO loop, since
it could read from the disk controller, dump to memory, and loop, all without
fetching instructions.  Once you got to PC-AT level, the 80286 chip could do
the PIO move faster than the DMA controller, so most '286 and '386 systems do
just that.  Neither is an acceptible method in a real multitasking OS.

>and the developers of UNIX on a 386 may have done just that-- thinking that 
>DMA on a multi-tasking system is better...

I doubt it.  Using the DMA controller would still tie up the bus just as much
as the '386 would, doing the move.  The DMA controllers still run real slow.
The way they address memory beyond 1MB, as I recall, is a kludge (or at least
was in the original PC-AT implementation).  No matter what, you still end up
with two bus crossings, wait states, and no buffering.  Most '386 systems use
disk interfaces that, like the '386, probably go faster than the DMA 
controller.  While I don't know what the UNIX folks do either, other than
maybe pray you have a real DMA (eg, bus mastering) hard disk controller with
FIFO or cache, I doubt they use the DMA controller, it is archaic.

>If disk speed becomes a problem, you could always add four meg of RAM and 
>increase the disk cache/buffers (you can get away with this on a cheap 
>system).  

That'll help performance on a system with a low performance non-DMA controller.
It may actually hurt performance on a system like the A3000, though it's not
obvious to everyone.  Certainly a little bit of intelligent caching helps by
eliminating extra seeks, on any system.  But, as long as you have a DMA driven
hard disk controller that runs bus cycles as fast as the host CPU (as on the
A3000), a transfer from the hard disk controller is twice as fast as a CPU
cache hit, ignoring cache detection time (which would increase the difference).

>You could also go for a cached controller board (that has UNIX drivers).  

That's exactly what you want in the above fast DMA controller senario.  With a
slower hard disk interface, the host system needs to do the caching.  The
A3000 sits somewhere in the middle, caching can help out on the hard disk and
to some extent in the host filesystem.

>There is another issue here...  The BEST CASE 030/25 machine I have seen (of 
>any brand) gets no more than 9000 dhrystones/sec.  I came up with this
>figure by looking at EVERY figure given to me via mail or magazines.  Most 
>were in the high 7000's, but there were several (30%) in the 8500 range.  
>giving the 030 the benifit of a doubt I'll say the best case was 9000.  I did
>thow out one figure of an 030/25 doing approx 12,000 because it was only one
>in a list of about 60 figures.   

You shouldn't do that.  That was an HP '030 workstation, the only one in the 
list, I'll wager, with an external cache.  Many '030 systems: Mac IIs (except
IIfx), Amigas, NeXT, some of the cheaper workstations in the Sony, Suns, and
Apollo lines, have no external cache.  Cache isn't the only architectural 
issue, either.  Some of the old Sun video displays, for example, steal lots 
of time from the main memory bus.  VGA isn't fast, but it doesn't intrude on
purely CPU intensive benchmarks, either.

>Keep in mind that there were for 030/25's in general rather than just the 
>A3000-- so most were cached...

Don't count on it.

>On the other side, none of the 386/25 (cached or not) figures I have seen (via
>the same method/sources as the 030/25's) were under 10,500.  It was closer to
>11,500 for cached systems.  This is all assuming that the 386 benchmark was not
>running under MS-DOG, where  the speed would be HALF that.  

Actually, the fastest benchmarks you can get on a PC Clone are under MS-DOS
with a DOS extender, where you run 32 bits wide but the benchmark has complete
ownership of the system.

>Hmmm.  Can someone tell me what the latest news from CeBit is?  I guess I
>missed that one...

A3000T.  See the new AmigaWorld...

>It's comming back to me now...  Ahh, drive music!  On another topic here,
>someone was telling me that the 3.5" drive for the C64 (the 1581?) has a 
>faster 6502 in it-- like 4mhz or something.  Is this true?  I sold my 64
>before it came out.  If it is true, why?  Better fidelity with drive music?

It might be 2MHz, I'm not sure.  Not 4MHz, real production quantities of
4MHz 6502 compatible chips didn't exist back then.  Greg Berlin, the designer
of the 1581, also designed the A2232 serial card (with 3.56MHz 6502 compatible)
and worked with me on the A3000 (he designed the Gary and RAMSEY chips).

>David Kessner - david at kessner.denver.co.us            | do {

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
      "That's me in the corner, that's me in the spotlight" -R.E.M.