Why no SE/30 L2 Cache Card?

[obsolete]

I know that there are adapters that allow a card designed for a IIci cache slot to plug into the PDS on an SE/30, and the IIci has the Apple 32KB cache card and various aftermarket 64KB and 128KB cards as options. So, why has nobody made an SE/30 cache card? Does the SE/30 lack something that would be required for L2 cache to work, or is it just because the slot is so much better occupied by an accelerator (with or without cache) instead?

 

[Fizzbinn]

I remember reading somewhere that it has to do with the Iici having an cache controller (implemented somewhere on the logic board) and ROM that understands how to use a cache card, where the SE/30 does not. There were cache cards for the IIsi but I think that is because it shares the same cache controller and ROM as the Iici.

 

[zigzagjoe]

On a read, assuming your data was found in cache, the cache needs to service that access and terminate the bus cycle, instead of addressing whatever device/memory is desired (ie ROM/RAM/Framebuffer). Cached accelerators have an independent local bus on which the cache resides, which allows the ability to either service the request from cache OR to perform external (logic board) bus cycle on a cache miss to retrieve the data. The IIci must have something similar built into the logic board, though I don't know the details.

On the SE/30, there is no hardware support to allow that distinction. You can implement the "is the data in cache" logic, but not the logic to service access from cache instead of the addressed device.

As to why: In 1988, I suspect that a 16mhz 68030 was considered adequately fed by the RAM and the CPU internal caches. Where a year later the IIci would suffer from the RAM latency remaining more or less constant (despite the increased system clock), and RAM based video reducing memory bandwidth, so somebody thought it was a good idea to build the possibility of a cache into the bus control logic.

Fun fact: The IIci accelerators don't really use the cache control logic on the logic board, which is why they can work in other systems without that logic since they manage their own bus cycles/cache accesses and essentially are just using the cache slot as a PDS slot.

On a DiimoCache 030 accelerator, the caches are able to supply data as quick as the 68030 can ingest it, if cache hits, though there are a few cycles of penalty on a cache miss (which is normal). Daystar Powercache claims a 90%+ cache hit rate, which agrees with what I've observed and with what is commonly stated for a direct mapped cache as used in Diimo and Powercache. I've attached an IDT cache application note for some related reading.

For data, here's a DiimoCache in a SE/30 running @ 20mhz w/ 64KB cache vs the stock 15.66mhz. Multiply these numbers by 0.78 to compensate for the clock speed difference, and you get essentially same results as stock. Seems to prove the hypothesis: no real benefit to L2 cache at 16mhz.

 

[obsolete]

Thanks @zigzagjoe for the great explanation and data. Perhaps the cache logic is in the IIci's MDU chip. And since the IIsi is like a decontented IIci, it was possible/practical for a card like the Applied Engineering Quicksilver to be implemented for it, but not for earlier Macs.

 

[hauke]

As to why: In 1988, I suspect that a 16mhz 68030 was considered adequately fed by the RAM and the CPU internal caches. Where a year later the IIci would suffer from the RAM latency remaining more or less constant (despite the increased system clock), and RAM based video reducing memory bandwidth, so somebody thought it was a good idea to build the possibility of a cache into the bus control logic.

The IIci was also the first Mac that supported the '030 burst mode, allowing to fill a 1st level cache line / four long words in one go. That mechanism would profit from a fast 2nd level cache.