Hi dtekle,

Thanks for your reply. Apologies on the community-post doc, it had gone stale and I have now updated it so it's current. My fault.

1) Turns out the 'thng' block was the PPC/CFM ('dlle') path, not Retro68 itself; it fails $F50A at OpenComponent on both Retro68 and CodeWarrior's PPC target. A real 68K 'PROC' code resource fixes it, and Retro68's m68k target builds it (no CodeWarrior/MPW needed). Registers and opens without any problems now.

2) Fully agree on AWACS vs. Toonie — hardware volume is dead, so it's all software PCM scaling. Rather than capture, I register a selectable 'sdev' that opens 'awgc' downstream and scales on the PlaySourceBuffer push path, giving me continuously-variable slider volume (still buggy though). A native Toonie/I²S driver is indeed the proper long-term answer.

3) Fair point on buffer timing. In practice it's just a per-sample multiply+shift, microseconds per buffer, no underrun so far.

Still struggling to overcome the volume slider response (it snaps around randomly) and keyboard volume control keys, which causes crashes (particularly the Volume Down key, using the A1048 keyboard). I'm not sure if the payoff is worth continuing down this route. The CSM is at least stable and does its job reliably.

Regarding to your community challenge for the Mac Mini G4 Audio Fix (https://github.com/UnexpectedBomb/G4-Mac-Mini-Audio/blob/main/COMMUNITY-POST.md):

I have some questions:
1.)

Not solved, but here's the map so nobody re-treads dead ends:...
...
• Registering our own component via a 'thng' resource — so the SM would select it — is blocked by the toolchain: with no 68K compiler we can't build a component file the Component Manager will load (it fails cfragFragmentFormatErr on our PPC-only CFM fragment).

Is it a toolchain-related road-block only because you use the retro68 compiler?

Have you tried it with any native 68k compiler?
- CodeWarrior 4 Pro and earlier have a 68k compiler, look discussion on Macintosh Garden: https://macintoshgarden.org/forum/last-version-of-code-warrior-pro-68k
- Macintosh Programming Workshop (MPW) has 68k assembler, Pascal compiler and C/C++ compilers: https://macintoshgarden.org/apps/macintosh-programmers-workshop)

2.)

...
• Component interposition from an INIT does NOT work here (this corrects an earlier guess). A CodeWarrior INIT can RegisterComponent + CaptureComponent at boot, but the Sound Manager opens BOTH the output device ('awgc') and the mixer ('mixr'/'mixw') before any INIT runs, and keeps those handles — so the captured wrapper is never called at all. I confirmed this with a diagnostic INIT that counts every SoundComponent selector: zero opens, zero calls, for both 'awgc' and the mixer, even with audio playing. Capturing 'awgc' only breaks audio (silence); capturing the mixer doesn't even do that — the SM keeps using the instance it already had. (Runtime capture from an app is later still.)

You are using the driver code for the "AWACS" sound chipset ('awgc'). This hardware is totally different (hardware DAC + mixer) than the plain Toonie chipset (DAC only, no hardware mixer). You will have to replace this driver code, i.e. writing your own driver coder targeted to the Toonie features (sound volume scaling must be made in software by the driver code) and replacing the AWACS driver code either by patching in the Mac ROM directly or at boot-time.

You might have a look at the Linux PPC sourcecode and Apple Mac OS X sourcecode for the Power Macintosh Audio hardware drivers for reference, they have already driver code for the Toonie chipset. (see my post http://macos9lives.com/smforum/index.php?topic=6701.msg59944#msg59944 at Resources #4-1 and #4-2).

3.) Manipulating the sound buffer seems difficult because you must guarantee that the sound volume scaling code is faster than buffer transfer rate to prevent a buffer underrun and distortions in the audio stream.

Insanely cool! Great to see new software for our beloved platform

Thankfully, I am not reinventing the wheel after all 

making this possible for cards which are - unlike the firmtek - actually available is always welcome.

we have those 3 beta system extensions here (elliot involved wheni am not wrong), testing such a "PC" card is on my todo list for years.

And yeah I think eSATA just carries data, not power, correct?

yes, no power. 600 instead of 400 mV, no power, and shielded cable with clamps, otherwise it is the same. at least that is what i have heard.

if this is true, this means you can simply use a breakoutpanel if you want to have eSATA in your mac.

top priority for SATA solutions would be anything towards cards with more than 2 ports. real ports, that is, since port multiplying seems to be a no go on OS9.

good luck with the USB, you will be showered with love

Y'know, I haven't had the mouse freezing bug happen ever since November 2025, on my Mac mini G4 1.5GHz model. It was after I started running every version of Mac OS 8 and System 7 I could on it ever since they were made compatible. I mention that further along in that thread.

From what I can tell, something changed in my mini's NVRAM while installing some specific version of System 7 from my mini. And whatever THAT was, it fixed every single issue known to happen to minis, except for the ability to use the internal speakers fully. And on silent upgrade models like mine, there's still that issue in which Mac OS 9.2.2 cannot write most things to NVRAM (fails silently). But other than those? Everything fixed. Including the mouse freeze bug upon boot.

I tried pursuing ways to backup my NVRAM and analyze it so I could pinpoint WHAT in it changed (because all my mini's volumes did NOT get changed, meaning it can only be NVRAM-related), but I kinda got stuck seeking guidance for that in 68kMLA, and just didn't pursue it further.

I'm bringing this up, because there's definitely a "hax-free" way to fix this mouse freezing issue. We just don't know how exactly yet. And I also want to share this benefit with the world, if I can at all.

I will write this too over at Macintosh Garden for wider reach, as a reminder.

wow yllan! This is pretty cool. It's kind of mind blowing seeing my neighborhood in maps in OS9!

Couldn't make the mastodon one work though for some reason the form that requests the auth token and instance doesn't accept any input.

The design isn't perfect yet, the connector position and alignment doesn't match up 100% with real drives so fitting it into any laptop is a pain. I should test it with a Wallstreet again, it might start working now.

I have had the occasional Mini G4 that seems to exhibit the mouse freeze bug less than others. Some have posited that it is related to the version of the interconnect board that links the motherboard to the cd and hdd. The 1.5 I use gets it annoyingly often… or at least, it used to!

Modifying an existing ATI driver is one thing but what about just making this thing into an “appe” background app that resides in extensions. You could call it “ATI UB Extension” and it would form part of the default install for a Mini G4.

Edit: also I wish to correct my post, my Cinema Display is a 20” not 23”.

Congratulations, I believe you have reliably fixed the Mac Mini G4 mouse freezing issue.

This is very exciting to hear, thanks so much for your thorough testing and feedback! Eventually it would be nice if I can somehow get this fix gracefully integrated into the ATI driver itself to eliminate the need of the VBLFix app altogether, but at least we can safely say we are in a better place than we were before.

My personal test case was a 1.42 GHz Mini using a 20" aluminum Cinema Display running at its native 1680x1050, same as your 23". Interestingly, I never got a single mouse freeze in 30+ boots at that resolution; it only happened at the lower non-native resolutions. Perhaps it was a statistical anomaly.

Good afternoon gentlemen

I have a Mini G4 1.5 GHz connected to a 23” aluminum cinema display (running at its native 1680*1050). It has a Kingston SSD in it connected via a cheap amazon msata>ide adapter. My keyboard is an Apple white plastic one connected via USB, and my mouse is a logitech M-BJ58. I have a Ugreen USB>headphone audio adapter connected as well. About one in every seven boots I get the frozen mouse.

I dl’d VBLFix_v1.bin, expanded it on my Mac Mini, gave it 500 kb of RAM instead of the default 1xx kb (force of habit from the old days, I just always give everything more RAM), and placed it in the startup items folder. I have been restarting continuously for 30 mins now. I have not experienced one mouse freeze, which is unusual for this Mini.

I did experience one crash on boot but it occurred before startup items would have loaded and so I don’t think it was related. But if it was, one crash in 30 mins of booting is preferable to a mouse freeze every seven boots.

This is an enormous, earthshaking development.

Edit: I have been restarting this mini for an hour now. Grand total of zero mouse freezes and that crash only happened the once.

Edit again: I carried on restarting a bit more and never experienced a mouse freeze. So I made it possible to launch the VBLFix application with the keyboard and removed it from startup items. First reboot I got a mouse freeze. Launching the VBLFix application with the keyboard immediately unfroze the mouse (the first time I have ever seen a Mini running OS9 recover from that state) and reset the mouse position to absolute top left.

Congratulations, I believe you have reliably fixed the Mac Mini G4 mouse freezing issue.