Finally found a 1MB L2 cache for my 6100

[killvore]

I wasn't even sure they were even around but last week I found one on eBay and jumped on it! I've run some tests this evening, and I've made arrangements to have it reverse engineered. If everything goes to plan, there should be some open sourced schematics which should allow anyone who wants one to build their own will probably still cost a bit since the SRAM is quite expensive just on its own, but at least it should be available - and maybe someone can find some clever improvements once its documented!

Anyway, some numbers. The test machine(s) are:
- a PM 6100/60 and an overclocked PM 6100/80
- 40MB RAM
- 640 x 480 video, 8 bit color
- System 7.6.1 with Speed Doubler
- HDI-45 internal video (with an extra HPV test)

The tests are:
- Quake 1 FPS using software render at 320x200 running "timedemo demo2" right after launch.
- Marathon 2 FPS (shift+?) fullscreened at 640 x 480 (no HUD). Spawn in - location is random, so strafe to the left corner and backpedal until you stop, wait until framerate stabilizes.
- Bryce 2 render. Time to render a test scene with some geometry and a bunch of different material types
- Finder scroll. Time to scroll from top to bottom of a massive folder, sorted by Name. This is me attempting to quantify the subjective experience of a snappier Finder.

MHz	L2 Cache	Quake fps	Marathon 2 fps	Bryce 2 render (sec)	Finder scroll (sec)
60	0	7.6	8.0	646	44.8
60	256kB	8.4	8.4	485	39.4
60	1MB	9.2	9.4	460	34.2
80	0	9.3	9.16	569	43.3
80	256kB	10.5	9.92	394	34.9
80	1MB	11.9	11.43	360	28.8

And finally I ran a test with the HPV card - yes, I cracked 12 fps in Quake on a Family Pizza without a G3!

MHz	L2 Cache	Quake fps	Marathon 2 fps	Bryce 2 render (sec)	Finder scroll (sec)
80	1MB	12.1	12.0	366	29.1

At some point I might get around to making a stripped back Mac OS 8.6 since I've had slightly better performance there but I just hate the long bootup time sooo much

For these very limited tests the bigger cache seems to provide twice the speed boost of the regular 256kB cache - nice! Bryce renders also get a speed increase from the bigger cache but it's dwarfed by the Sick Gainz from having any cache at all.

 

[Fizzbinn]

Great post, interesting!

Is this a 1MB L2 cache module produced by Apple? Can you post some pictures of it?

 

[killvore]

Thank you! And no I don't think its made by Apple, I'm not sure they made them in that size. Here's the front and back - the chip with the missing markings is apparently a switch type 74*257 mux, according to the person who is reverse engineering it:

 

[stepleton]

Amazing! Thanks for doing what you can to get your lucky find reverse-engineered. I hope it will be easy to dump the GALs!
My 6100 has no cache so I'll be keeping an eye out for a clone of this thing.

 

[AlpineRaven]

Damn I was looking but I didnt look for it for past 2 weeks!!

If you can get it reverse engineered and I am keen in for one please!
Cheers
AP

 

[olePigeon]

Wow. That cache module made a huge difference.

 

[obsolete]

the chip with the missing markings is apparently a switch type 74*257 mux, according to the person who is reverse engineering it

Wow, why was that such a big secret that someone saw fit to hit it with sandpaper? Good luck with the reverse engineering effort, I hope the GALs are unlocked!

 

[Melkhior]

For these very limited tests the bigger cache seems to provide twice the speed boost of the regular 256kB cache

Not quite; you have an interesting set of benchmarks here - they all reacts differently to the combinations of parameters! Good choices
If we compute the evolution from one line to the next for the 60 and 80 MHz, and then add the performance gain from 60=>80 MHz for the no-cache case (don't want to clutter the table with too much data), we have:

MHz	Quake (FPS)	Marathon (FPS)	Bryce (s)	Finder (s)
60
60	10,53 %	5,00 %	-24,92 %	-12,05 %
60	9,52 %	11,90 %	-5,15 %	-13,20 %
80	(22,37 %)	(14,50 %)	(-11,92 %)	(-3,35 %)
80	12,90 %	8,30 %	-30,76 %	-19,40 %
80	13,33%	15,22 %	-8,63 %	-17,48 %

Quake and the Finder have similar benefits from the 0=>256 and 256=>1024 change. However, the jump in frequency is useless without cache for the Finder, while it's very meaningful for Quake (super bound gain is 33% for FPS and -25% for time going from 60 to 80). Marathon gains a bit from the small L2 and significantly more from the larger one, and reacts positively but not very well to frequency. Bryce wants 256 KiB of L2 to do anything useful.
My (educated) guesses:
* Quake is likely compute-intensive in a working set that reuse sublinearly - no surprise here, Quake is well optimized.
* The Finder is more unexpected, as scrolling should be basically bandwidth-bound - additional cache shouldn't really help here (I expect no temporal locality and near 100% spatial locality in each read cache line, everywhere but horizontal boundaries of the scrolled area). However, it depends what "scrolling" means here - if it's a one-shot movement, then it is unexpected. If it is repeated movement from continuous scrolling, then we get temporal locality and the benefits from caches can become dependent on the amount of data scrolled.
* Marathon has gain that are double from 256=>1024 than 0=>256 - unlike Quake, it has a working set that probably has more long-distance reuse. Maybe too much and that could be optimized a bit to benefit more from L1 and smaller L2.
* Bryce is compute-intensive in a working set that is basically size(L1)<< working set <= 256 KiB. It cannot live in L1 so the frequency gain is unrealized (limited by memory), but once you give it 256 KiB it's happy, realize most of the frequency gain and doesn't really need the extra L2 cache.

I'd say you want the overclock first for Quake, the (small) L2 first for Bryce, check for potential optimizations in the Marathon code before changing the hardware, and an accelerated video card (hardware blitting) for the Finder

 

[herd]

Nice find, thanks for posting your results!

I wonder if it could go to 2MB or more? The tag chips have extra pads and it looks like there are options for the config resistors. Good luck with the clone project.