ROM-in-RAM for Quadra performance boost

eharmon

Well-known member
I've long wondered, why doesn't a ROM-in-RAM utility for the Quadras exist? It was common for 030 and 040 accelerators, and the 68k AV machines had it natively (enabled with a PRAM switch, which AV Turbo ROM can flip for you). (I know you're thinking -- is it because performance changes are minimal? Maybe!)

But I think the answer is one does, but the information has been lost to the sands of time. Enter DayStar QuadraBoost: https://macintoshgarden.org/apps/quadraboost

The readme is vague, the internet information non-existant, and there's a strong implication that it requires a cache card...

...but I had a hunch about what it did, and after cracking open the resources, throwing it on my Q800 board, and looking at memory allocations, I feel pretty strongly that QuadraBoost is actually a ROM-in-RAM utility for 1MiB Quadra ROMs requiring no additional hardware.

It offers three settings, which copy and remap various amounts of the ROM into RAM controlled by a page map in its resources. The most aggressive setting copies over 99% of the ROM to RAM, if I'm reading things correctly.

Is it actually faster in practice? I'm not sure. Quadras have pretty fast ROM access speeds. But 60ns interleaved memory is pretty quick, when you get up to the Quadra 800. Maybe with the boosted cache sizes from a PDS cache card it helps even more, but I don't have one to test with.

Unfortunately, benchmark utilities seem really lacking in this department, concentrating on raw CPU and memory speeds and not the speed of the underlying OS. And newer OS patch and replace ROM functionality anyway, meaning running later operating systems may provide similar benefits. So I'm gonna stick with "maybe". Curious if anyone has any deeper insights.

Note that at least on my system, I was unable to boot with maximum performance set on System 7.1.1, however 7.6.1 and 8.1 worked with no issues.
 

David Cook

Well-known member
Quadra 700, 25 MHz 68040, 20 MB RAM, 128KB disk cache, System 8.1 (not stock -- tailored to developer extensions and control panels)
128KB DayStar Quadra Cache, QuadControl 2.3

To hopefully exercise a little bit more ROM code, I compiled 125K lines of commercial C code. The compiler draws text showing the line being compiled, it reads the files, moves around a lot of memory, writes to the resource fork of the destination file, etc.

No Cache Card, no QuadControl software: 4:41
Everything enabled: QuadraBoost Off: 3:43
Everything enabled: QuadraBoost Minimum: 3:40
Everything enabled: QuadraBoost Good: 3:38
Everything enabled: QuadraBoost Best, 3:37

In summary, for this test, the card and software made a significant difference. The QuadraBoost feature maybe made a tiny difference.

For other tests, or earlier operating systems, the ROM to RAM may show better performance.
 

David Cook

Well-known member
The more I think about it, the more I think the cache card limits the value of the ROM->RAM move. That is, the most common code from the ROM will get into the cache card already. So, making the less often accessed ROM code slightly faster to read from RAM is just not much of a benefit.
 

eharmon

Well-known member
Quadra 700, 25 MHz 68040, 20 MB RAM, 128KB disk cache, System 8.1 (not stock -- tailored to developer extensions and control panels)
128KB DayStar Quadra Cache, QuadControl 2.3

To hopefully exercise a little bit more ROM code, I compiled 125K lines of commercial C code. The compiler draws text showing the line being compiled, it reads the files, moves around a lot of memory, writes to the resource fork of the destination file, etc.

No Cache Card, no QuadControl software: 4:41
Everything enabled: QuadraBoost Off: 3:43
Everything enabled: QuadraBoost Minimum: 3:40
Everything enabled: QuadraBoost Good: 3:38
Everything enabled: QuadraBoost Best, 3:37

In summary, for this test, the card and software made a significant difference. The QuadraBoost feature maybe made a tiny difference.

For other tests, or earlier operating systems, the ROM to RAM may show better performance.
Interesting! The cache card does help quite a bit on its own, despite some other claims I've seen. It's nice to know the ROM-in-RAM has at least some effect, instead of just being placebo. But that's not too much on a Q700. I wonder if it's greater on later Quadras which step up RAM performance.
The more I think about it, the more I think the cache card limits the value of the ROM->RAM move. That is, the most common code from the ROM will get into the cache card already. So, making the less often accessed ROM code slightly faster to read from RAM is just not much of a benefit.
Yeah, that's part of what's so weird about it, for me. It seems like it has the most benefit when you have less cache, and yet DayStar snuck it into the utility that shipped with their cache expansion! I kinda wonder if it just juiced the benchmarks a tiny bit and made the whole card seem a bit more worthwhile.
 

cheesestraws

Well-known member
There was another ROM-in-RAM utility for at least the AV Quadras, but I cannot remember for the life of me what it was called. Not by a big name. I think @Phipli might have pointed me to it?
 

Phipli

Well-known member
Oh, I forgot to say -

The reason it isn't really common is that some naughty software is known to casually write to the ROM because 'it doesn't matter, it's read only anyway'... If you copy your ROM to RAM, you can have occasional issues with some software corrupting it. I'm not sure how common it is or if the author was just paranoid, but something I read said it was an issue.
 
Last edited:

NJRoadfan

Well-known member
How wide is the data bus to the ROM on those machines? On PCs, ROM shadowing had a big performance boost (in DOS anyway) since the system BIOS and video ROM were generally only 8-bits wide, while system RAM on a 386+ machine was 32-bits wide.
 

Phipli

Well-known member
How wide is the data bus to the ROM on those machines? On PCs, ROM shadowing had a big performance boost (in DOS anyway) since the system BIOS and video ROM were generally only 8-bits wide, while system RAM on a 386+ machine was 32-bits wide.
On 68k macs it will be 32bit in most instances. Apple needed a fast ROM because there was so many routines stored in the Toolbox in ROM. Doing multiple reads to get each word out of the ROM would have significantly slowed down the computer, more than it was worth in cost savings.
 
Last edited:

eharmon

Well-known member
There was another ROM-in-RAM utility for at least the AV Quadras, but I cannot remember for the life of me what it was called. Not by a big name. I think @Phipli might have pointed me to it?
Here is the 660/840 thing that bbraun made :

Another option for the 660/840:

Here is something for PowerPC macs :
Yes, the difference with the AV versions is, as bbraun notes, it's a built-in ROM function that was never exposed officially for whatever reason. Maybe due to the potential corruption concerns.
Just had to try it, wouldnt boot on maximum on my 475 with 7.5.5. It just freezes on the finder.
Yep, sounds the same behavior as 7.1 for me. I did some more digging and it seems like the QuadControl panel subsumed the functionality of QuadraBoost, which implies it also should work without any DayStar hardware installed. Crucially it mentions some compatibility fixes, especially for 7.5. I'll give it a try later and see if it works and fixes the hanging on some configurations.
 

David Cook

Well-known member
A couple of additional notes of interest:

1. When I first started testing, the Quadra 700 had 20 MB of memory and I boosted the preferred memory size (in File->Get Info) as much as possible for the Metrowerks IDE. With Metrowerks running, the Finder showed a little more than 1 MB as the Largest Unused Block. The test results took a minute more than I posted above, with performance getting worse with the ROM->RAM feature. This surprised me. Then I remembered that the compiler does not use IDE memory (it may use some, of course), but instead allocates temp memory. By boosting the IDE memory and by using up additional memory with the ROM->RAM feature, I was starving the compiler. I then returned the IDE to a reasonable amount of RAM, leaving 6 MB free, and produced the test results that I posted above.

The lessons here:
* Metrowerks uses free memory during compile time. Make sure to leave some.
* The ROM->RAM feature decreases performance in memory starved situations

2. This morning I decided to see if having even more memory would improve compile times further. So, I swapped in new memory modules to give the Quadra 700 a total of 68MB of RAM. Performance was unchanged.

The lesson here:
* At some point, Metrowerks doesn't need more memory to run faster

3. I checked the graph I made for 128KB cache performance on another thread. On that, I concluded the the cache card + software provided about a 11% boost on the Quadra 650. In the test on this thread, it provides about a 30% boost on a Quadra 700.

The memory controller differences (interleaving, etc) could be why the older Quadra 700 benefits more from an L2 cache.

For unrolled loops of 32-bit reads, the 68040 L1 cache provides 2x memory read performance. The L2 cache provides a 1.66x boost.

1706470604906.png
 
Last edited:

eharmon

Well-known member
Very interesting, @David Cook. Quadra 800 memory timings are even tighter (matching 60ns) which is likely why L2 expansion cards fizzled. Just not a big boost for later 040 boards.

Totally makes sense that ROM-in-RAM can be a tradeoff if you're not on a high-memory system. Probably why they suggested the medium setting by default.

I did the experiment to switch from QuadraBoost to QuadControl, and I can confirm I now get compatibility with all OS on my Quadra with it set to maximum (1MiB): DayStar Quad040 Control Panel

If you hold option with the Control Panel open, you can also enable "Write Protect ROM". (I actually recommend holding option-command which stops it from flickering...not sure why, must be a bug).

I'd recommend if anyone wants to get the ROM-in-RAM boost, however large or small, stick with the last version of QuadControl.
 
Last edited:
Top