Exciting development. It sounds like we're getting near to a v10 of the mini CD.

I'm afraid I can confirm, at least on a 1.5Ghz Mac Mini, the mouse freezing issue is still there. Oh well :-)

Y'know, I have to comment on this again: by now I must have rebooted the mini from 50 to 100 times since the new ROM, and the mouse freeze glitch bug did not happen even once.

But I think I'm closer to understanding what's going on: @fergycool, if you can and are willing to try, assuming from now on you only use the 10.2.1 ROM for the mini, can you zap the NVRAM and then see if you ever get it ever again?

Basically, something BIZARRE happened when I was using Mac OS 9.2.2 recently, which made many pieces click together: I got System Sounds and FULL volume control e.g. on the Control Strip for me to adjust on the mini. "Suddenly". This is completely unprecedented to ALL of us Mac OS users on the mini.

I go through the findings a bit more in detail on this post. (Recommended read for any Mac OS 9.2.2 user on the mini.)

This is / these are a bizarre and unexpected positive side-effect of this project (or of the stock 10.2.1 ROM itself once it has the mini patches). But I very much welcome it!

metric halo channelstrip is on every track of mine since ages. all their other stuff especially their recent collab with rick "make believe" i do not like.

Top five for best customer support:

    Metric Halo

why i am not suprised.

i would never try to patch a system releated file while it is beeing loaded, it seems more safe to patch a copy, then switch files, then reboot.

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.

I mean we will see what we can do here as far as an emulated G4 system in Qemu with PCI Passthrough of the 2496. I should have the card this week and start work on it, the real hangup is how slow the FPU is in emu-system-ppc vs the real G4's. Any realtime processing on the CPU is going to hammer the FPU and that's our weak point, but I can speed it up.

I already implemented Hard Float and that speeds things up, but we can offload FPU calls to SSE in x86 hosts as that is what Apple did with Rosetta I when people wanted to use PPC versions of Logic and such on x86, and that works pretty well, or it worked well enough at the time.
 

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