Re: companion product for GSBarnDoor

[Eric Rucker <bhtooefr@gmail.com>]

On May 17, 6:23 pm, nyder <nyder...@gmail.com> wrote:
> How does accels that plug into the cpu slot work exactly?

Same way an accelerator plugged into a normal slot works - in fact,
the normal slot is just used for power and access to the DMA lines,
those cards have a cable that goes to the CPU socket. So, the socketed
accelerator won't have support for DMA, unless it has a card that
provides that as an option.

There's something sitting between the CPU and the system bus, and that
chip has some cache RAM attached to it. It tries to fetch things from
RAM as quickly as possible, so that the CPU doesn't get starved for
data, and write things to RAM as quickly as possible, so that RAM and
cache match. The CPU operates from the cache RAM, unless there's a
cache "miss" - when the CPU tries to access RAM that isn't cached - in
which case it sits idle until the chip grabs the data it needs. The
chip can get stuff from RAM faster than the CPU can, because it can
access RAM every cycle, whereas the CPU can only access it every 2
cycles in a best-case scenario, IIRC, which helps - current
accelerators aren't really slowed down by the bus, because the
accelerator can keep the CPU fed with data.

Of course, the cache controller is only able to talk to RAM at 2.8
MHz, whereas the CPU is talking to the cache controller at, in this
case, 30 MHz. At 30 MHz, there WILL be a lot of cache misses, even if
the cache controller is good at prefetching - the CPU can badly outrun
the bus. IIRC the 65816's slowest instructions are 7 cycles. So,
except on small datasets that fit entirely in the cache, anything
faster than approximately 19.6 MHz will be completely wasted.
(However, looking at the cache of, for example, a maxed-out ZipGSX,
which can take 64 kiB of cache, you can fit quite a lot in there -
enough to fit a whole segment of IIGS RAM, or a whole bank of 8-bit
RAM.) 5.6 MHz, IIRC, can actually run at full speed on the 2.8 MHz
bus, and never miss cache, as even the fastest instructions on a 65816
take 2 cycles to execute. From 5.6 MHz on up, the cache controller's
accuracy in predicting the amount and locations of code and data to
load is very important in determining performance - a "bad"
accelerator will be only barely faster than 5.6 MHz at faster speeds,
whereas a "good" one will still provide improvement in performance all
the way up to, and beyond, 19.6 MHz, by getting the right data and
code into cache.

And now I think I'll end this long post about my understanding of how
accelerators work in general, and their performance implications.