The extra patching to allow newer machines to use OS 9 is definitely interesting, but is not really something up my alley. I hope that someone else can step in to figure that kind of stuff out once I learn more about the firmware update code though! Just patching the startup sound is a lot easier than making code changes and shuffling drivers around...
Maybe just flashing the old firmware over the new firmware would work, though (especially after what Dennis Nedry said above...).
Thanks for the sound bite. While I'm at work, I'm stuck on a winbox. I think I'll change the startup sound to this. Maybe it'll cheer me up in the morning to hear that soothing tone.
Nice! Glad to be of assistance
OpenFirmware seems pretty neat-o, though quirky. EFI is blech. It takes BIOS, which while crufty mostly works but needs updates, and then turns it into a monster; becoming a new OS layer entirely, providing drivers and other things which a HW init and bootstrapper should not do.
I know that Open Firmware has drivers as well, but they are pretty minimal. I haven't looked much into EFI but I'll take your word for it!
I messed around this evening with forcing the updater to update the firmware despite the firmware already being up to date. It appears the firmware updater has a "whitelist" of known firmware versions it is allowed to update. I found it in the data fork--looks like just a bunch of NULL-terminated strings in the form of "Apple PowerMac1,1 1.0b4 BootROM built on 11/06/98 at 09:04:50" -- that's a sample from the list. I modified the last entry in that list to match the string from the latest firmware: "Apple PowerMac1,1 1.1f4 BootROM built on 04/09/99 at 13:57:32". That seemed to make the updater get past the "your firmware is up to date" message, and it gave me instructions on how to install the update (clicking a shut down button, holding down the programmer's button while powering it back up, and waiting for a long tone). I vaguely remember doing this process a long, long time ago. A progress bar came up and the chip was flashed. I *believe* it flashed from the standard G3 Firmware file that was in the same folder--that is the file I have to modify.
When the G3 finally booted back up, I got an error saying the firmware update failed, do you want to try again, blah blah blah, which now came up on every reboot. After playing around some more, I believe the problem is that because I've patched the updater to believe the most current version of the firmware is updatable, it doesn't think the update succeeded. What happens is the updater program copies itself into the Startup Items folder. When it runs from the startup items folder, it has a slightly different behavior than if it's just launched normally--it knows someone tried to update the firmware, so it checks the status of it. To get around that problem, I put the original unpatched updater program in its place and rebooted one more time -- it finally told me the firmware is up to date and removed itself from the Startup Items folder. I'm guessing I can just get away with removing it from the Startup Items folder, but there's always a chance it does something funky after detecting a successful firmware update -- so maybe it's a good idea to put the original updater back in to let it do any necessary cleanup. Not sure.
So bottom line is the next thing to try is: encode an IMA 4:1 sound of the same length as the original chime, put it in place of the original chime, re-encode the firmware with the Ascii85 encoding, recalculate the Adler-32 checksums, stick everything in the appropriate place in the G3 Firmware file, and try it out. I don't have everything ready to go quite yet, but it doesn't seem like it's going to be that bad. I just hope I'm not missing out on another checksum inside the ROM code. We'll find out depending on whether or not I brick the G3 motherboard!
