Xref: utzoo comp.sys.mac.hardware:418 comp.sys.mac.programmer:10433
Path: utzoo!attcan!sobmips!uunet!iconsys!caeco!jose!ken
From: ken@jose.uucp (Ken MacLeod)
Newsgroups: comp.sys.mac.hardware,comp.sys.mac.programmer
Subject: Mac "Accelerators" and "DMA"
Message-ID: <1989Nov15.214527.1212@jose.uucp>
Date: 15 Nov 89 21:45:27 GMT
Organization: Price Savers, Salt Lake City, UT
Lines: 42


  I've just read yet another review on Mac accelerators, and how they've
"attached directly to the CPU, to bypass the 10MHz NuBus access to the
devices," and therefore disabling any use whatsoever of the original CPU.

  Hasn't it occurred to any accelerator developer that the Mac needs
a DMA controller, as well as a faster processor?  Don't their mice
drop dead any time the floppy turns on?  Don't they run Spinning Globe
in the background all the time :-)?  Don't their systems use the CPU
to read in stuff off the hard disk, like my Mac does?

  Why isn't there an accelerator that is _just_ a processor and memory
on a card, and passes I/O commands (at quickdraw, file manager, etc. levels)
on to the motherboard?  For bulk transfers, the motherboard can either
read/write directly into the card's memory instruction at a time, or the
card can include a simple memory-to-memory DMA that the motherboard CPU
sets up.  For control structures, two CPU RAM regions would be logically
mapped so that pointers could point to one from the other.  The M-to-M
DMA unit could also be used for reads/writes into video card RAM (if you
know how QuickDraw or PostScript handles rasterizing, you should drop
your jaw in awe of what that means, CPU handles start/end, DMA handles
between while CPU...).

  It seems to me that the CPU/NuBus technology is already there, and from
enough programming on the Mac it seems simple enough to copy the ROMs into
the card and patch in interfaces that send the relevant commands to the
motherboard, and let the ROMs on the motherboard take it from there.

  A second step, a little more difficult, is putting some structures on card
RAM, others in motherboard RAM, handled by the resource manager and placed
in the RAM closer to the routines that access them most, like offscreen
bitmap on the motherboard, but port/window structure in card RAM.

  With 030s or a PMMU for 020 machines, interlocking could be implemented
easily using the page permission mechanism, as well as mirroring some often
accessed common addresses in both RAMs using "write-through" to get it to
the other RAM.


  Comments?  Job offers? :-)

  -- Ken, ken@jose.UUCP, caeco!jose!ken@cs.utah.edu