It's OK because in the long run, I decided a long time ago to use the VMs available in QEMU, Virtual Box, Parallels, etc to create various virtual DAWS that work with the system emulated drivers (NOT a hardware interface), just to load old projects and export files.  You can playback projects, with some lag, but editing is out of the question.

System: G4 MDD (2003 1.25Ghz FW400)

Firstly, I'll cover my mad-cap plan... I wanted to have both a PCI and AGP graphics card inserted so that I could get full acceleration in both 10.4 and 9.2.2 just by switching VGA cables between the two cards (probably with a VGA switch, yet to test that part).

The x800 Pro AGP (converted Fire GL3, reduced 64kb rom) giving acceleration in 10.4 and a converted 9250 PCI (128kb TOME rom, hacked drivers) giving acceleration in 9.2.2, I'd heard of a few people doing this so thought it would be worth a go.

This is kind of working, BUT in 9.2.2, it still detects the AGP card as a basic adaptor, meaning I end up with 3 monitors being found, the third being the PCI card (I guess AGP has priority with 2 DVI ports, not sure). OS X seems to behave a lot better well with it, not making everything active.

Within 9.2.2, this causes problems in various games, some have acceleration some won't even start. Is there a way to disable multi-monitor support in 9.2.2 or disable the AGP card in 9.2.2? Could this be connected with still having a reduced 64KB rom on the X800?

I hope this makes sense!

Anyway, your ResCompare patch on System might work and it might not. For it to work, somebody else's System file before applying a patch should be bit for bit identical to your System file at the moment of creating ResCompare patch.
IIRC, there were several resources inside System file, that were created/modified by various NIC installers. Possibly others too. I also know of one audio software company that created its own resource inside System file for copy protection purposes.

Ah, good point. To be fully sure, people ought to consider respatching in boot 2 and 3 themselves (literal copy+paste) if the patch complains with an error message.

izotope = native instruments now

Using rubber will also increase bass perception, but it reduces the precision of the voice coil's movement, introducing greater distortion in the frequency response, thus resulting in a poor sound. This is why there are no rubber-only speakers on the market (especially in high fidelity). Not to mention that, as it deteriorates, the voice coil could lose alignment and collide with the walls of the magnet, slowly burning out (which I think is one of the causes of premature death). So, here's my concern: to increase bass, larger resonating boxes or bass reflex ports could be considered... of course, we're talking about very small dimensions.
I think the longevity of speakers depends primarily on use and the environment in which they operate (outdoors, hot, cold, continuous use for hours heats up a lot, and the rubber could dry out...). My three aluminum speakers, 1GHz, 1.5GHz, and 1.67GHz, seem to be following the same timeline as speaker deaths... the first one has crumbled tires, the second is dry, the third is moving but burned...
I found the speakers on eBay, 2cm in diameter.

Just FYI.
https://www.production-expert.com/production-expert-1/the-surprising-truth-about-how-audio-professionals-rate-the-biggest-brands

Holy mackerel! 

This was my first time actually using ResEdit OR ResCompare in all my life. But wow, they are easy and nice.

WHAAT? And you call yourself a Mac user?
Kiddin', just kiddin' 

Anyway, your ResCompare patch on System might work or it might not. For it to work, somebody else's System file (before applying a patch) should be bit for bit identical to your System file at the moment of creating ResCompare patch.
IIRC, there were several resources inside System file, that were created/modified by various NIC installers. Possibly others too. I also know of one audio software company that created its own resource inside System file for copy protection purposes.

Mac7News again!

Rairii figured out all that System 7.0.x needed in order to fully use and acknowledge the existence of the Enablers, more appropriately-called "Gibblies", which is to take the boot 2 (and optionally boot 3) resources from System 7.1 and put them on System 7.0.x! So I went ahead and tried exactly that, on the Mac mini G4 as always:

7.0.1 (International English):



7.0 (International English):



Well, that's it. It's completely CRAZY all of this got this far. Incidentally, this patching might also assist older 68k Macs that required an Enabler to boot System 7.1 in a way so that they also boot 7.0.x (at least in theory).

Oh yeah, and it's incredibly stable, too. Played and completed a game of Shanghai II on these. Ran Glider flawlessly (lack of sound aside), too. Things just... work. Smoother than butter, it's playing with lightning!

Anyone can replicate this with easy ResEdit copy + paste, but just in case anyone wants an ever bigger shortcut, I attached a patch for 7.0 and 7.0.1 to this post, which I created with ResCompare 2.6. You double-click it, then click on the button to patch, then select your System 7.0 or 7.0.1 file accordingly. It may or may not require the "International English" version for my patches, though, but I'm not sure. The patches do work on the International English release, though, that much I can say. Also note that the patches create an unmodified backup file called "System (original)", just in case, but make sure you don't leave the backup inside your System Folder by accident.

This was my first time actually using ResEdit OR ResCompare in all my life. But wow, they are easy and nice. (Had to increase allocated memory on Get Info to both, though, which you must if you do any of this patching by hand!)

One way or another, we got ALL versions of System 7 now covered. Insane. Rairii also intends to look into the lack of audio one day, so this might not be over yet from his side.

Just to address our next natural expectation: "WHAT ABOUT SYSTEM 6?"

This one seems like it won't be easy (not that most of this was, as extremely few people on Earth have the ability + interest to do what Rairii did up until this point). Rairii is working on this, but there can't be any guarantees. It seems that even Macsbug is not working in this case? System 6 is just too much of a departure from System 7 and later. Code only present in Old World ROMs will be needed this time around, one way or another.

Now only time can tell what will or will not happen!

what a strange choice to use rubber for the construction of everything which is the only element that deteriorates in classic speakers..

Nothing strange here at all.
A bit of insight into speaker chassis design... Primitively speaking, to get the good bass, you need the low resonance frequency of the speaker. Soft surround (foam, rubber) gets you low resonance, stiff surround (paper, plastic) gets you high resonance, but, as a result, no low bass.
It's obvious that Apple went for good sound in their, exensive at the time, portables. Nobody thought about longevity back then.

https://en.wikipedia.org/wiki/Thiele/Small_parameters#Qualitative_descriptions

You're right that the M-Audio 2496 has its own DSP on the ICE1712 chip that handles a lot of the audio processing, mixing, and routing independently. The card can do:

Hardware mixing of multiple streams
Sample rate conversion
Digital I/O routing
Some effects processing

So for basic audio I/O, recording, and playback, the host FPU speed shouldn't matter much - the card is doing the heavy lifting with its onboard DSP and DMA transfers.
However, FPU performance would still matter for:

Plugin processing - VST/AU effects and instruments running on the CPU
Soft synths - All computed on the host
Real-time effects chains - Reverbs, compressors, EQs running in the DAW
Mixing/bouncing - When the DAW is doing CPU-side processing

The 2496's DSP handles the interface between digital/analog and manages the audio streams, but all the creative processing (plugins, virtual instruments, etc.) still happens on the host CPU's FPU.
Given that your emulated FPU performance is weaker than native G5 (as you mentioned with your Geekbench results), you might hit limitations with heavy plugin chains or complex soft synths, even though basic tracking and playback through the 2496 should be fine.
The real test will be loading up a session with multiple plugin instances and seeing where the bottleneck appears. The 2496's DSP helps, but it can't compensate for CPU-intensive creative tools.Claude is AI and can make mistakes. Please double-check responses.