68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | |
| Intro & Mac OS 9 solutions | |
| Posted by: UnxpectedBomb on 2026-08-04 10:56:24 Hello! I've been posting a lot over at MacOS9Lives lately but I wanted to introduce myself here as well. I've been working on several exciting OS 9 -related solutions and I wanted to get them into the hands of this fine community, in the hopes that you good folks can help me test and refine these solutions further. You can find my repos here: 
UnexpectedBomb - OverviewUnexpectedBomb has 5 repositories available. Follow their code on GitHub.
github.com
OS 9 solutions that I've developed thus far - G4 Mini VBL fix: finally fixes the infamous cursor-freeze that has plagued OS 9 on the G4 Mini for a long time - G4 Mini audio control strip: activates the G4 Mini's internal speaker under OS 9 while also giving mute capability and headphone auto-detection - Temperature monitor control strip: gives live readout of both the CPU temp and case temp, where applicable. Verified working with G4 MDD and 667 DVI TiBook (could be compatible with other G3/G4 Macs but I need testers to try it out and report back) OS 9 solutions currently in development: - USB 2.0 driver: yes, you read that correctly. It's finally here! I've released an early beta of what I believe to be the first-ever OS 9 USB 2.0 driver. It is primarily a modified MDD Mac OS ROM with a true EHCI stack built-in, intended to work with NEC-chipset USB 2.0 PCI cards (but may work with other chipsets as well, I just don't have others to test). For New World Macs with on-board USB 2.0 (like the G4 Mini or aluminum PowerBooks), you can try using the "ROM injector" to inject the EHCI stack directly into your ROM. I haven't tested this much outside of the MDD (have had some G4 Mini success), so make sure you keep your stock ROM saved somewhere, along with some sort of CD-bootable media, in case you need to revert back! OS 9 solutions to be developed in the future - eSATA support for LaCie PCI cards: currently only supported in OS X, but the hope is that with eventual OS 9 support for these cards it would unlock eSATA SSD mounting and even booting from an eSATA-attached SSD as well. | |
| Posted by: Phipli on 2026-08-04 11:01:24 I'll have to update my Mac Mini OS9 install 🙂 What kind of real world transfer speeds to you get with USB2 on a G4? | |
Posted by: UnxpectedBomb on 2026-08-04 11:08:49I'll have to update my Mac Mini OS9 install 🙂So far I have achieved reads as fast as 20 MB/s and writes as fast as 12 MB/s, both of which are blazing compared to USB 1.1. These speeds will vary, depending on what is being moved and what kind of USB drive is being used, but you will consistently get far better speeds than anything OS 9 was ever doing before. | |
| Posted by: CptnCodon on 2026-08-04 11:49:35 This is huge! Thanks so much for your efforts! | |
| Posted by: aladds on 2026-08-05 11:21:20 I saw your post about USB 2.0 on MacOS9Lives - and I realised I’ve got exactly the right USB card _already_ in my G4...so I was excited to give this a go! I copied the existing ROM file off by stuffing/binhexing it, putting it on a USB stick and then uncompressing it on my modern mac (26.5.2 - note that most unarchiving tools can't extract a stuffit archive now but the "unar" command line tool still can and preserves the resource fork) and then tried to run the injection tool... I had to additionally set up these tools: https://github.com/elliotnunn/tbxi-patches ...and set an envinronment variable so your patch script knew where to find them: "export TBXI_PATCHES=..." After that I was able to run the injection script, which spat out a file which I re-binhexed: binhex encode "Mac OS ROM (USB2)" Upon copying that back to my G4 and un-binhexing it with stuffit...it's invalid and I get a warning if I try to reboot when it in place (and correctly named). It's also 471k smaller, so clearly something isn't working properly here. For reference, I have 9.2.2 on my G4 (Dual 450 AGP) and the ROM file is version 9.2.1 (CPU Software 4.9, 3,382,671 bytes). Opening both files in RedEdit...the patched file has no resource fork, so either the script has stripped or corrupted it somehow...or maybe APFS has caused an issue here? (Although I thought it could do resource forks!) So as a last attempt to make this work I copied all of the resources from the "old" rom file to the patched one...and that didn't work. Then I remembed the eject button on the CDROM doesn't work. The drive does, however, so one paperclip later I'm back to testing. A couple of reboots on from there and I tried your prebuilt rom. This is detected as valid when I try to reboot, and it correctly boots. And it works! With a special USB 2 icon! The EHCIActivate program seems to crash quite a lot, and it doesn't display any menubars or anything so I can't quit it...and neither can the system when I try to reboot. Using Speedometer I can absolutely tell the difference in speed. USB 1.1 gives a rating of 2.899 and USB 2.0 gives 16.462 for the same drive. Very impressive! (Compare to the IDE HD which gives a rating of 40.289) Side note: You can't format a FAT formatted USB drive as HFS under OS 9, but if you use a modern Mac to format it to HFS+ (Journaled) you can then use the "Erase Disk" command under the Special Menu in OS 9 and format it as Mac OS Standard. Edit: On your GitHub page you say that it being a ROM patch is a benefit because it doesn't need to be an extension...could it be an extension? I feel that would probably be considerably easier to set up. I can believe that it can't be an extension though. Edit 2: The drive I tested was a generic "SMI Corporation" 1GB drive, Vendor 090C, Product 1000 | |
| Posted by: UnxpectedBomb on 2026-08-06 11:47:56 @aladds, thank you so much for going to such lengths to test this. It's particularly exciting because you are the very first person to independently verify that the stack truly does work at USB 2.0 speeds. The amazing thing is that you got a modified MDD ROM to boot on an AGP G4, which I would not have expected to work! I will add the AGP to the list of machines that this has been proven to work on. You also found two bugs in the injector, which is very helpful. Both are fixed in my tree and will be in the next push. 1. It had an absolute path to my own copy of elliotnunn's tbxi-patches hardcoded in it. You should never have had to discover that dependency or work out the environment variable yourself. It now looks in several sensible places, honors TBXI_PATCHES, and if it finds nothing it stops with an error that names the repo instead of failing obscurely. 2. It never checks its own output, which is something I should have considered from the beginning. Yours came out 471 KB smaller than the base and the script handed it to you as though it had worked. It now measures the input first and refuses to write an output smaller than the input, because the script only ever ADDS about 210 KB of driver, so a shrink means content was lost along the way. That single check would have caught your build before you ever took it to the G4. A patched ROM with no resource fork is actually normal. tbxi rebuilds the image with SysEnabler inside the data fork, so a correctly patched ROM legitimately has no resource fork at all. That is why copying the resources across in ResEdit was never going to save it. The fork that matters is the one on the INPUT. If that is lost getting the file off the OS 9 machine, tbxi only prints a quiet warning about ignoring orphaned data fork PEFs and then builds a ROM without them, which is where your 471 KB went. Worth checking what you actually fed it: ls -l@ "Mac OS ROM" and looking for com.apple.ResourceFork. Your unar approach is the right one, it is one of the few modern tools that preserves the fork, and thank you for putting that in writing. I am adding it to the README along with the HFS+ then Erase Disk trick for FAT sticks, which is a useful tip that I had not documented. As I had mentioned about your setup, the prebuilt ROM is an MDD's, so on a Dual 450 AGP it carries drivers for hardware you do not have. The fact that it boots and works at all is awesome, but if you do hit odd behavior, I think the MDD ROM might be the suspect. Once the injector fix is out, you should definitely try patching your own 9.2.1 ROM again. On EHCIActivate, the missing menu bar is deliberate rather than an oversight. It hides its window and hands the front back to the Finder, because if it stays frontmost it swallows the disk inserted event and your drive never mounts. Installing a menu bar was also what corrupted the heap in early builds. To quit it today, bring it forward from the Application menu at the right hand end of the menu bar, then Cmd-Q. It will refuse to quit if a USB 2.0 volume still has open files, which is also deliberate. The restart problem is a genuine bug and you are the first to report it. The app has no Apple Event handler at all, so the Quit event the Finder sends at restart is simply never answered, and it sits there blocking the shutdown. I am adding that handler. On the crashes, I can't tell whether that is the same quit freeze or something new. Could you tell me which build you are running and send me EHCIUIM_init.log from your System Folder? Read from the LAST banner in the file, as the driver appends to it across boots rather than starting fresh. On your question about an extension: it has to be a ROM patch. The Mac OS ROM loads before the Extensions folder does, and the driver has to claim the controller before the USB stack comes up, so an extension would always be too late. The interesting exception is Old World Macs, which have no Mac OS ROM file and where the whole USB stack is extensions anyway, so that route stays open for them. That is a later phase and I don't currently have any Old World PCI Macs that I could test on. | |
| Posted by: aladds on 2026-08-06 14:12:13 I see that you've put a lot of time and effort into this project, and I understand that without tools like claude it would be difficult to make something like this work (potentially at all), and I know you have not hidden the use... but I spend enough time arguing with people at work regarding what good uses for LLMs are and I don't really want to start doing that here. Yes, LLMs are a very useful tool and the work required to get the drivers working etc. are a very good application of this tool...however I do not appreciate my comments being copy pasted into the same tool, and then the answers posted back to me in what would normally be a conversation with another person. I could be wrong here, and if so I apologise, but the above post has a certain "Gen-AI sais quoi" which feels uncomfortable to me and I would have preferred you respond to my post in your own words. (I do not think that you, the person, would have written about my use of "unar" or "a useful tip that I had not documented" in the manner that this post portrays) That said, I am willing to help testing with you, the person, and I do not have anything against you using the tools to make something that otherwise we would not have. Genuinely this is a fantastic development that I am grateful for (and I think a lot of others in the community are too)! The file I fed in did indeed contain a resource fork, confirmed by your suggested command, but also preserved by my binhexing before copying it off the G4. The output absolutely needs a resource fork too or it won't work. The binhexed MDD ROM you have as your "release" has a resource fork, for instance. I can copy off the log files tomorrow, although the version of the application I used was the one you "bundled" with the release for the MDD, rather than one I built myself, so hopefully that should help. The logs are also saved to the desktop on my machine, not put in the system folder. Fair enough regarding the ROM patch / extension. | |
Posted by: Phipli on 2026-08-06 14:18:32The output absolutely needs a resource fork too or it won't workThis bit isn't right. The ROM hacking crowd do make a type of ROM that has all the stuff in the Data fork. Caught me out too as I thought the one I had was bad, but they work just fine without a resource fork. | |
| Posted by: aladds on 2026-08-06 14:24:12 That's very interesting. Did the ROMs you tried also cause the Finder to throw an error when you select Restart from the Special menu? There seemed to be a connection between that and the lack of a resource fork (although I suppose a corrupt file would also cause that, and it's very likely all of the files I tested were corrupt!) | |
| Posted by: UnxpectedBomb on 2026-08-06 14:24:20 @aladds, that is a fair critique. In the spirit of transparency, here's exactly what's happening: I'm a flesh-and-blood human being, obviously. I am a data analyst by day, with a wife and kids, and limited time with which to spend on this stuff (as much as I love doing it). My reply to you was a mix of both comments written directly by me (see first paragraph especially) and some more technical answers from Claude (massaged by me here and there). The reason I do this is strictly for the sake of speed and velocity. I promise you that there's no way I'd be able to tackle each of the finer points from your reply in the timeframe that I did so if I had not gotten some assistance from Claude. I do appreciate that you gave me the benefit of the doubt in never hiding the fact that I've used Claude Code regularly in the development of not only this project but every other OS 9 project I've done (I've been very public and open about that over at MacOS9Lives, as you've hopefully seen), as there is zero possibility of one guy being able to develop a stack like this without the AI tools of the age. Run this post through an AI detector... I promise that it's actually me 😛 | |
Posted by: Phipli on 2026-08-06 14:27:52That's very interesting. Did the ROMs you tried also cause the Finder to throw an error when you select Restart from the Special menu? There seemed to be a connection between that and the lack of a resource fork (although I suppose a corrupt file would also cause that, and it's very likely all of the files I tested were corrupt!)No, they worked like normal. I'm not up to speed with the specifics. Might be worth some insight from @LightBulbFun ? Begging your pardon if you don't mind 🙂 | |
| Posted by: UnxpectedBomb on 2026-08-06 15:27:43 @aladds I've given this some more thought, putting myself in your shoes. I think I'd be a little creeped out if I truly didn't know what portion of a forum post was coming from AI vs an actual human being. I should be better than that. Future posts will clearly call out the parts (especially the more technical responses) that were written with AI assistance so you'll what's coming directly from me and what's not. Like everyone else, I'm trying to figure out how to properly navigate this new AI world, and I agree that this is a line that needs to be drawn. Apologies for the discomfort. I'll edit the above post as well (as soon as I can figure that out... can't seem to find an Edit button... 😕) Edit: I don't think I can retroactively edit older posts unfortunately | |
| Posted by: aladds on 2026-08-07 01:11:39 Thank you - I appreciate your thoughtfulness and that does seem to be a good way to identify things in the future. No need to edit - it's good to see the discussion and see how we have come to this conclusion. Please see the attached log files below as discussed! | |
| Posted by: UnxpectedBomb on 2026-08-07 08:50:28 Thanks for providing the logs, @aladds . After taking a look, I can tell your second run mounted correctly, which again is certainly the first time that it's ever been done on a G4 AGP, so that alone is a big win. Turns out that the logs do not implicate the MDD-ROM-on-AGP scenario as the reason for the crashing. According to the analysis, it just "appeared" to crash because that now-outdated build had no cap on log writes, so a stuck transfer floods the log and starves the activator app. On top of that, the activator app also couldn't recover a port that it bailed on, so those ports stayed dead until you rebooted. But the good news here is that both of these issues have since been fixed, so if you download the latest build today, you shouldn't experience that again. **Billy Mays voice: "But wait, there's more!" Major update: I have completed v1 of the MacOS9Lives Mini G4 ROM with USB 2.0 built into the ROM directly. Plus, two important features that have been added: multi-device mounting (up to four USB drives simultaneously, with hot-plugging) AND real hub support, tested on the built-in USB 2.0 hub on the back of a 20" aluminum Apple Cinema Display. This ROM (and every other ROM in this project) still requires launching the EHCI activator app for now, but eventually the goal is to have that go away as well in order to achieve a truly seamless OHCI/EHCI experience similar to what early OS X was doing. @Phipli you're obviously a Mini G4 owner, and I'd love it if you (or anyone else!) could test out this new ROM and report back on how it goes. | |
| Posted by: opualuan on 2026-08-07 09:16:19 Planning to test MDD today. I have a multi-level kvm setup with keyboard emulation that can be challenging for some software to traverse- is there an upper limit set for how many usb hubs your mod will be happy with? | |
| Posted by: UnxpectedBomb on 2026-08-07 09:23:27 Good question. For total USB hubs in play, as it currently stands, I think that upper limit might be one 😆 I haven't tested anything beyond the single Cinema Display hub (it's the only USB 2.0 "hub" I have these days), but you can definitely give it a try with multiple hubs and see what happens. One thing I should definitely mention regarding hub support is that you should NOT connect low-speed devices (e.g. keyboards and mice) to any USB hub that you plan to use with this stack in its current state, as that isn't supported yet. I honestly don't know what would happen, but it probably wouldn't be good, haha. Most likely a freeze or something. I'm still working on the OHCI/EHCI coexistence, which will be a pain to nail down. | |
| Posted by: opualuan on 2026-08-13 10:31:24 Got a chance to test, all on single-cpu MDD fw400 running 9.2.2: USB2 - transfer speeds both ways at ~3.8 MB/s - Went to swap out to a known fast usb drive for more speedtesting, now will not mount drive. Reboot does not help - System Profiler now crashes with Type 3 when opening Devices and Volumes tab Temp CSM: - auto temp updates working! - c/f selection does not stick through reboot - option dragging active csm out of control strip caused a hang. Need to move files in system folder instead - click behavior is opposite of other csm: menu appears when mouseup instead of mousedown - helpful to include version string in get info field | |
| Posted by: UnxpectedBomb on 2026-08-13 15:43:15 @opualuan thanks for your tests! This feedback was super helpful in guiding my latest improvements. Regarding the Temp CSM:
Today, after a LONG multi-week slog of diagnostics and bug-hunting, I wrapped up the next (and hopefully final) major USB 2.0 release: fully-integrated USB 2.0 that requires only a pre-built ROM and a system extension, NO more "helper apps"... those apps were always somewhat flaky and were intended as a temporary stepping stone. This should finally feel like "native" USB 2.0 support, which was what I considered the end-goal from the very start. I have not yet updated the repo with this release (currently testing on a B&W G3) but I will make an announcement when that happens. Additionally, I discovered that same frustrating ASP "Devices and Volumes" crash bug a few days ago, and it has been fixed in this upcoming release as well. I believe this will be the most reliable and robust USB 2.0 release by far, and I'm excited to get it out to you very soon. | |
| Posted by: opualuan on 2026-08-13 18:14:18 This is great, thanks for the super-fast updates! Temp CSM: I was using option-drag (then release option) to remove old and install the new control strip module- this works. All items test good now! | |
| Posted by: UnxpectedBomb on 2026-08-13 20:03:13 Update: Tonight I identified a sneaky bug in v1.7 of the temp monitor CSM that causes crashes when run alongside my upcoming app-less USB 2.0 stack (it involved screen redrawing and the new constantly-updating functionality of the CSM). This has been fixed in v1.8 which is now live on the repo. | |
| 1 > |