Mac OS 9 Lives
Mac OS 9 Discussion => Mac OS 9, Hacks & Upgrades => Mac OS 9 on Unsupported Hardware => Topic started by: UnexpectedBomb on July 02, 2026, 01:04:07 PM
-
Hi All,
Stumbling upon his forum post a few weeks ago, I was inspired by the progress of "x7x" in solving some of the Mini's OS 9 audio issues: https://tinkerdifferent.com/threads/mac-mini-g4-sound-on-os-9-2.5173/
Using his foundational work, I did some vibe coding of my own and developed a Control Strip Module that does the following:
- automatically enables audio on boot
- provides a mute/unmute function
- auto-detects when headphones are plugged/unplugged in the 3.5mm audio jack
- displays corresponding graphics to indicate mute/speaker/headphones
During development of that CSM, however, I was annoyed by the now-infamous "1-in-5 boot mouse cursor freeze" and decided to tackle that next. It was discovered that the freeze was due a VBL-interrupt issue; I have developed a small app that sits in Startup Items that, upon reaching the desktop, will UNFREEZE the cursor, effectively neutralizing the problem.
I would like your help in testing both of these solutions further, particularly the latter to ensure that my VBL-interrupt theory with the mouse-freeze is accurate. You can review technical notes and download both solutions here:
Audio CSM - https://github.com/UnexpectedBomb/G4-Mac-Mini-Audio
Mouse freeze fix - https://github.com/UnexpectedBomb/G4-Mac-Mini-VBL-Fix
BIG thanks to Elliot Nunn for sending me in the right direction on the VBL-interrupt. When testing this, please keep track of whether you are booting into a native or non-native resolution; if a native resolution causes this freeze even a single time, that would mean I need to re-evaluate my theory.
Additional OS 9 G4 Mini projects that are currently underway:
- A true audio driver that does everything the CSM does, plus enables variable audio levels (via the slider) and fixes keyboard volume controls (such as on the A1048 keyboard)
- Drivers to enable true USB 2.0 speeds both on the Mini directly and also from PCI cards on G3/G4 towers
- Drivers to enable eSATA compatibility when using PCI cards such as the LaCie 130823
- Drivers to enable the Mini's internal Bluetooth module as well as related USB Bluetooth dongles
All feedback is welcome so I can continue to improve these solutions. Thanks in advance.
-UB
-
awsome awsome work thank you so very much
i happen to have come across the Lacie 130823 in one of my PMG4's and I put it in my Mac OS X box.
https://www.seagate.com/content/dam/seagate/migrated-assets/lacie-content/datasheet/pci_esata_sismo_de.pdf (https://www.seagate.com/content/dam/seagate/migrated-assets/lacie-content/datasheet/pci_esata_sismo_de.pdf)
© 2008, LaCie / Mac® OS X 10.2.8 +
did I miss someone getting eSATA to work on OS9?
-
If the mouse freeze bug is fixed that would be huge. I’ll test it out tomorrow. Thanks!
-
did I miss someone getting eSATA to work on OS9?
That is the same exact LaCie card I have in my MDD currently. And no, I don't know of any solution that has gotten eSATA to work in OS 9, which is why I'm spearheading it now. End goals are reading/writing external SATA drives and hopefully even booting from one as well.
-
SeriTek/1VE2 is to my knowledge the only original eSATA solution with OS9 ROM Drivers - including boot support.
What i do not know is if its eSATA connectors are actually delivering a higher voltage compared to SATA (which is the only actualy difference between to two, right?)
-
look into FirmTek SeriTek/1S2 also sold/rebadged as Sonnet Tempo SATA / TSATA
edit: IIO beat me to it
edit2: a eSATA port carries data only - the disk still needs power from an enclosure, except for the 2006 eSATAp or eSATApd (w/USB) who i have never come across but there is a sticker on my SATA museum box that i want one since last week actually :D - they are also no offical specification of the SATA-IO they are vendor proprietory to come across the limitations of eSATA
-
SeriTek/1VE2 is to my knowledge the only original eSATA solution with OS9 ROM Drivers - including boot support.
What i do not know is if its eSATA connectors are actually delivering a higher voltage compared to SATA (which is the only actualy difference between to two, right?)
Interesting, I did not know about the FirmTek cards! I looked into this and they use different chips compared to the LaCIe cards, and the LaCie cards never got OS 9 drivers. Thankfully, I am not reinventing the wheel after all ;D
And yeah I think eSATA just carries data, not power, correct? I plan to eventually have a USB-to-SATA power cable plugged into an MDD USB port to power a SATA drive (if that actually works). We'll see shortly. The USB 2.0 project is coming along nicely as well, hoping to have that one done very soon.
-
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.
-
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.
-
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”.
-
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 (http://macos9lives.com/smforum/index.php?topic=7711.0). 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.
-
Thankfully, I am not reinventing the wheel after all ;D
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 ;)
-
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 (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 (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 (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 (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.
-
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.
-
Thanks for your answers, I also checked your progress report today. ;-)
... Keyboard volume keys are unstable ...
Regarding the keyboard volume key problem, under Mac OS 9, only some PowerBook and iBook models could control the sound volume by keyboard keys.
See also:
- https://www.bumc.bu.edu/it/files/2012/03/macos-quick-reference-9.pdf (https://www.bumc.bu.edu/it/files/2012/03/macos-quick-reference-9.pdf)
- https://whitefiles.org/mac/pgs/m01.htm (https://whitefiles.org/mac/pgs/m01.htm)
- https://whitefiles.org/mac/pgs/mx01.htm (https://whitefiles.org/mac/pgs/mx01.htm)
- https://matias.ca/tactilepro3/support/ (https://matias.ca/tactilepro3/support/) (see: "Eject & Volume keys don't work. Anything I can do?" - Mac OS 9)
Link #2 mentions a method to assign a function to a keyboard key via a 'FKEY' program (maybe an alternative to your component approach?):
FKEYs
By pressing ⌘-Shift in combination with a specified number key you can launch a special kind of mini-application known as an FKEY. This is really a kind of function key that was invented prior to the introduction of real function keys on Macintosh keyboards. Like real keys, FKEYs can be used at any time, no matter what application is running.
Standard FKEYs
The following FKEYs are built into the standard System file:-
FKEY Function
⌘-Shift-1 Ejects diskette in drive 1 (usually internal)
⌘-Shift-2 Ejects diskette in drive 2 (usually external)
⌘-Shift-3 Saves desktop image in a SimpleText PICT file
⌘-Shift-Ctrl-3 Copies desktop image to Clipboard
⌘-Shift-4 Saves selected part of desktop in a SimpleText PICT file
⌘-Shift-Ctrl-4 Copies selected part of desktop to Clipboard
In the latter of these, an area is selected by clicking and dragging and can be constrained to a square by pressing Shift whilst dragging. There’s also another FKEY, activated by pressing ⌘-Caps Lock-Shift-4, which creates a SimpleText PICT image file of a selected window. The bulls-eye that appears should be dragged into the required window and clicked. If you press Control as well, or continue to hold this key down whilst clicking in the window, the image is copied to the clipboard.
Should you use ResEdit to look inside the System file you’ll discover that the first two of the FKEYs listed above aren’t actually kept as FKEY resources, whilst the other four actions are in just two FKEY resources, known as FKEY 3 and FKEY 4, since keys 3 and 4 are used to activate them.
Adding FKEYs to your System
An FKEY can be installed in one of three ways:-
By adding it to the System file’s resources by means of special application or control panel. This is slightly risky as it can damage your system.
By modifying the file containing the FKEY so that it looks like a font suitcase file. It can then be placed in the Fonts folder, inside the System Folder and should then be recognised by the system. Unfortunately, this method doesn’t work with all versions of the Mac OS.
By launching a ResEdit version of the FKEY file from a utility such as OtherMenu.
-
This is really phenomenal news.
I thought there would be pages and pages of accolades in this thread by now. Both the mouse and the audio fixes work great on my 1.5ghz g4 mini. Only issue I found was that booting the OS9 partition through classic on Tiger would hang loading the mouse fix, so I just duplicated the system folder and removed it.
This makes the little mini one of the best OS9 platforms around, and pretty cheep too.
Nice work to all that were involved and thank you!
-
Congratulations on all of the progress, @UnexpectedBomb. I think we are nearing the era of a new version of the Mac OS 9 CD.
-
Thanks, all. Truthfully, this has been a team effort; I'm just glad to hear that it's helping people enjoy the Mini. With these two problems solved (or at least largely mitigated), I think the G4 Mini's day-to-day usability as far as OS 9 is concerned is much improved; a pleasure to use, even. And agreed, @davecom, I hope they can be implemented somehow in a future release of the OS 9 installer. Happy to be a part of this OS 9 journey with you all :)
-
I think the G4 Mini's day-to-day usability as far as OS 9 is concerned is much improved; a pleasure to use, even.
This is accurate.
-
Thankfully, I am not reinventing the wheel after all ;D
mr. firmtek-sata-drivers is a member here.
I plan to eventually have a USB-to-SATA power cable plugged into an MDD USB port to power a SATA drive (if that actually works).
that works for sure, the usual 99 cents adapters makes any SSD an USB stick.
the practice problem with those is only that they are usually greater than 32gig, which means you have to use HFS instead of FAT32, and then this media is basically PPC-to-10.12 only. (for interchanging with windows or mac pro 2010 and above that sucks.)
will be interesting to see what speed you will get with your new USB 2 attempt.
-
Thankfully, I am not reinventing the wheel after all ;D
mr. firmtek-sata-drivers is a member here.
I plan to eventually have a USB-to-SATA power cable plugged into an MDD USB port to power a SATA drive (if that actually works).
that works for sure, the usual 99 cents adapters makes any SSD an USB stick.
the practice problem with those is only that they are usually greater than 32gig, which means you have to use HFS instead of FAT32, and then this media is basically PPC-to-10.12 only. (for interchanging with windows or mac pro 2010 and above that sucks.)
will be interesting to see what speed you will get with your new USB 2 attempt.
Noted on the FAT32 vs HFS issue. I had been exclusively going down the HFS route to just try and get that piece working first. But honestly the whole eSATA effort is getting mothballed until USB 2.0 has been finalized/matured (it's the bigger priority by far) so that I'm not making two sets of custom MDD Mac OS ROM files independent of each other; the goal is to eventually have a single custom "mass storage" MDD ROM that covers both EHCI and eSATA functionality all in one go. I'm still far away from that finish line, but USB 2.0 is making good progress. I plan post an update in the USB 2.0 thread later this week if things continue going well.
-
UPDATE: VBL Fix v2 is up, now Classic-safe!
First off, thanks to everyone for the testing and the kind words. Special thanks to @n8blz for the seriously thorough shakedown: 30-plus restart cycles with zero freezes, then pulling the fix back out and watching the freeze return on the very first reboot. That's exactly the before-and-after I was hoping someone would run. It's the clearest confirmation I could ask for that we're fixing the right thing.
Thanks also to @xc68000 for putting both fixes through their paces and catching an edge-case that I didn't anticipate: booting an OS 9 partition inside Classic on Tiger would hang while loading the VBL fix. The cause makes sense once you see it. Under Classic the display is virtualized by Mac OS X, so there's no real ATI hardware behind the boot display. The fix works by re-issuing the display driver's "enable VBL interrupt" call, and under Classic that call has nothing real to talk to, so it wedges. The freeze itself doesn't even happen under Classic, since OS X is driving the actual display, so the right move is for the fix to just stay out of the way there.
That's all v2 does. At startup it checks (via Gestalt) whether it's running inside the Classic environment, and if it is, it quits without doing anything. On native OS 9 nothing changes at all: the check can only ever make it skip under Classic, never on real hardware, so v2 behaves identically to v1 on an actual mini. It's a safe drop-in over v1, and there's no rush to update unless you run OS 9 under Classic.
@xc68000, whenever you get a chance, could you drop v2 in and confirm your Classic on Tiger boot no longer hangs? That's the one setup I can't test here as I don't have anything booting Tiger/Classic right now, so your confirmation would be helpful.
You can grab it from the v2.0 release here: https://github.com/UnexpectedBomb/G4-Mac-Mini-VBL-Fix/releases/tag/v2.0
Install is the same as before: drop VBLFix_v2 into your Startup Items folder. There's also a VBLAutofix tester build in the release that reports what it did with a beep and a log, if you'd like to watch it catch a freeze in the act.
Thanks again, everyone. It's been a blast seeing this help so many minis. The next milestone will be to fully integrate this solution into the ROM itself for a truly seamless experience. I'll keep you posted!
-UB
-
All, I apologize for the flurry of posts lately... hopefully you don't mind be blowing up the "Hacks & Upgrades" board around here ;D but I am VERY excited about this new update.
I have successfully integrated the VBL fix into the G4 Mini's ROM itself, moving it inside the display driver. The driver now re-arms the interrupt at the tail of its own mode-switch routine, at the moment of the switch, before the desktop draws. No app, no Startup Items, no brief freeze. It simply boots. And because it acts at the switch rather than after boot, there is a real chance it also catches the severe hard-hang and garbled-boot cases the app could never reach. After ten clean boots on my own (five warm, five cold), I've had zero freezes.
The patched ROM is byte-for-byte identical to the standard MacOS9Lives mini ROM apart from that one driver change (verified with a full dump comparison), so every existing boot patch is left alone. It is safe to drop in only if that is the ROM you already run. If your base ROM is different, do not flash mine over it. Use the included patch, which applies the same change to your own ROM.
Install is simple and fully reversible: back up your current Mac OS ROM first, expand the download, boot from another volume or CD, replace Mac OS ROM in the target System Folder (keep the name exactly), and reboot. If anything looks wrong, restore your backup and you are back to stock. And if reflashing a ROM feels like more than you want to take on, the VBL-Fix app from my previous post still covers the mild case.
Download everything here, including the full technical write-up: https://github.com/UnexpectedBomb/G4-Mac-Mini-VBL-Fix
I am especially after testers who get the severe hard-hang or garbled boot, since that is the one case my own mini will not show me. Thanks as always to Elliot Nunn for the diagnosis and the ROM toolchain, and to @n8blz and @xc68000 for the earlier testing. This is the final "native" state I had always envisioned for this solution; being a ROM-level fix, this should also drop naturally into a CD or installer, as @davecom suggested earlier. If broad community testing can prove out this ROM-level fix, we may have finally, truly put the G4 Mini's cursor-freezing bug to bed.
IMPORTANT EDIT: I myself have now experienced at least two cursor freezes with this new ROM so it is still very much a work in progress. I recommend to ALWAYS keep the app fix on hand, either on the desktop where you can easily navigate to it and run it with just the keyboard, or in Startup Items, or attached to a hotkey setting that allows you to run it that way if necessary. The app is still the guaranteed method of reviving the mouse cursor. Eventually I'll get the ROM itself to do it seamlessly and reliably but it seems I have more work to do there.
-
All, I apologize for the flurry of posts lately... hopefully you don't mind be blowing up the "Hacks & Upgrades" board around here ;D but I am VERY excited about this new update.
Nothing wrong with that. On the contrary, it's much appreciated, you're the one doing us all a lot of favors with this!
"MikeTomTom" from the Macintosh Garden seems to be having some issues with the original VBL-fix approach, so he might be the kind of guy you were looking for, for this kind of testing. This is what was reported (http://macintoshgarden.org/forum/it-without-great-regret-i-must-inform-you-the-mac-mini-g4-mouse-freezing-issue-solved#comment-119621).
Regarding sound on the mini.... I recently discovered a lesser-reported audio-related issue all 4 minis seem to have which, if it could be addressed in the future, it'd be really awesome. I'll just share some info on it here, if by any chance it interests you.
Some CD-based Mac games had multiple tracks, as they contained redbook or CD-DA audio in them, to play in-game. But the first few games of its kind on the Mac seem to commonly have an issue with later Macs that use IDE/PATA for CDs (including all New World ROM Macs?), and Mac OS 8.1 ~ Mac OS 9.2.2. This is an issue that affects not only the minis, but lots of other Macs. Games like Quake fixed it on later patches, such as Quake 1.09, and the likes of Warcraft II are new enough not to have the issue, but the original "Warcraft: Orcs & Humans" does, without any patch to fix it.
... Now here's where the mini's own issue, on top of the one above, comes in: even the likes of Quake 1.09 cannot play CD-DA audio on the mini. All other Macs can. In the "Sound" Control Panel, you even notice that if you go to the "Input" tab, click on "CD", then check the 2nd checkbox, it will crash the Control Panel, which is a further symptom that the mini indeed has some issue with this sort of playback, much like how it is also finnicky and buggy regarding the built-in audio (even with the audio fix).
If you feel like looking into this too, it'd be awesome, because then we could have these minis able to play the whole of the Warcraft trilogy in one single convenient machine! Of course, this would also benefit the MDD and the others, too.
Assuming this interests you... I provide all the information I can in this comment (http://macintoshgarden.org/games/warcraft-orcs-humans#comment-119836). Quite a number of people stumbled upon this issue, only to be sad about it... You can see their conversations in links within that comment.
Some people are occasionally also dropping by this Garden page (http://macintoshgarden.org/apps/macmini-audio-fix) to provide feedback about the current audio fix (but that page has yet to mention your control strip, something which we can fix).
-
Some CD-based Mac games had multiple tracks, as they contained redbook or CD-DA audio in them, to play in-game. But the first few games of its kind on the Mac seem to commonly have an issue with later Macs that use IDE/PATA for CDs (including all New World ROM Macs?), and Mac OS 8.1 ~ Mac OS 9.2.2. This is an issue that affects not only the minis, but lots of other Macs. Games like Quake fixed it on later patches, such as Quake 1.09, and the likes of Warcraft II are new enough not to have the issue, but the original "Warcraft: Orcs & Humans" does, without any patch to fix it.
That Mac Garden thread nails the overall cause: old "mixed‑mode" CD games assuming SCSI‑era CD‑audio behavior that breaks on newer ATAPI drives + OS 8.1+, so it's not really Mini‑specific. The Mini just adds one twist: the control‑panel crash on the CD input is the screamer/AWACS spoof advertising a CD‑audio input the Toonie DAC doesn't physically have, so ticking it faults on hardware that isn't there.
Either way it's upstream of the amp fix (that only switches the output on), so it's not something my Control Strip module can touch. The iTunes idea is an interesting workaround that at least gets you some of the original atmosphere more or less, but a true fix would most likely be in the form of a small system extension that patches the CD driver, which should be possible. I'll look into this and see what I can come up with.
-
@UnexpectedBomb, great job!
Due to lack of time I am following this thread with great interest, but only once in a week or so.
I have a question - does your G4 Mini audio fix exists only in form of Control Strip Module?
If so, what about those who never use Control Strip? Like me, for example. ;)
-
[...] a true fix would most likely be in the form of a small system extension that patches the CD driver, which should be possible. I'll look into this and see what I can come up with.
Thank you, that'd be incredibly awesome.
On a side note regarding the SCSI vs. ATAPI and OS 8.1+, it seems the latter is also fine and fully working with Quake version 1.09 specifically. However, all minis were confirmed as non-working with Quake 1.09, meaning that on top of the whole SCSI vs. ATAPI situation, something else is also additionally getting in the way of the minis, whatever it is.
I just hope someday it can be figured out.
@UnexpectedBomb, great job!
Due to lack of time I am following this thread with great interest, but only once in a week or so.
I have a question - does your G4 Mini audio fix exists only in form of Control Strip Module?
If so, what about those who never use Control Strip? Like me, for example. ;)
The audio fix per se is in an Extension, which you can download ready-to-use here (http://macintoshgarden.org/apps/macmini-audio-fix), developed by "matouspikous (https://github.com/matouspikous)" as part of his "MacLegacyLabs (https://github.com/matouspikous/MacLegacyLabs)" project, inside of which is the "MacMiniAudioFix - max sound (https://github.com/matouspikous/MacLegacyLabs/tree/main/MacMiniAudioFix%20-%20max%20sound)" subproject in question.
@UnexpectedBomb's solution requires this to be already installed on the mini as a pre-requisite. His solution, which only comes in the form of a Control Strip Module (CSM), gives this audio solution some further functionality, which is welcome.
While the Control-Strip-based solution could, perhaps, be converted into a Control Panel as the next best thing, it'd require new work when we already have the working Control-Strip-based solution... Which IMO we shouldn't get distracted by: Control Strip is very low in resources, and can easily have its visibility fully toggled on/off with Cmd+Ctrl+S ("S" for "Strip", so it's easy to remember).
-
I just hope someday it can be figured out.
Try this: https://github.com/UnexpectedBomb/MacOS9-CD-Audio-Redirector
-
I just hope someday it can be figured out.
Try this: https://github.com/UnexpectedBomb/MacOS9-CD-Audio-Redirector
Wow, that was fast, thanks!
Unfortunately, I'm getting a 404 GitHub page error. Perhaps the repository is not yet publicly-visible?
-
Unfortunately, I'm getting a 404 GitHub page error. Perhaps the repository is not yet publicly-visible?
My fault, I thought I had set the repo to public but it was still private, as you guessed. Try now.
This scenario was interesting to me, and thankfully it did not require any major overhauls. If it doesn't work, I'll get my hands on a cheap mixed-mode disc (probably Orcs & Humans, to be safe) and really get to the bottom of it.
-
Unfortunately, I'm getting a 404 GitHub page error. Perhaps the repository is not yet publicly-visible?
My fault, I thought I had set the repo to public but it was still private, as you guessed. Try now.
This scenario was interesting to me, and thankfully it did not require any major overhauls. If it doesn't work, I'll get my hands on a cheap mixed-mode disc (probably Orcs & Humans, to be safe) and really get to the bottom of it.
It didn't work. But the "CDPlayProbe_v11" did make some buzzing sounds, so I clicked on both "I heard music" and "it was silent" buttons, one at a time (which you can see in the log). I wonder if it was trying to play Track 1 for that test? Track 1 is just normal computer data, and not redbook audio, so it'd check out. Either that, or something else is amiss.
For the record, Warcraft 1 does have an in-game setting in a checkbox called "CD off". But I made sure that was unchecked all along, and even tried toggling it on and off to be sure. Anyway, the CD did not even spin.
I attached to this post all 3 files I found in the root of the System Folder regarding your tool, in one single SIT package.
To get your own mixed mode CD, all you need is a program that can burn BIN+CUE images. Mac OS 9 doesn't have one (nor does it have a BIN+CUE image mounter, which also would be mighty useful to avoid burning discs), but the likes of ImgBurn on Windows can do it.
EDIT: I attached the CD logs regarding the 2nd attempt to this post, as well.