Thread
G3 Blue and White custom startup sound ROM hack -success!!
OK...here's the video with the proof that it really happened! 
I've never put a video of myself actually talking on YouTube until now, so that was kind of weird for me!
I've never put a video of myself actually talking on YouTube until now, so that was kind of weird for me!
That is just too awesome to put into words!!
Thank you for posting a video about it.
Thank you for posting a video about it.
put the Q700 hidden chime in there. that would be awesome.
Thanks!!! Someone should remove "pipe dream" from the thread title now, haha
That's a great idea! I need to write some scripts to automate the whole process of creating the new firmware update file, and then I'll try that. Right now it's a mix between a Windows hex editor, some Linux utilities, a USB flash drive, BBEdit Lite, and Super ResEdit
Done
Awesome, thanks Bunsen!
:lol: Kinda like Windows 95: Hack Sauce, with Patch and Kluge on Spaghetti Code!
Congrats once more, DQ! :approve:
Thanks jt! Haha, no kidding, it's a mess!
I've streamlined the whole process now though -- I made a utility in C++ that automatically does all the encoding/decoding/checksumming. You give it the G3 Firmware file from Apple's update, a raw 16-bit big-endian 44.1 kHz sound, and it does the rest. I ended up writing code for Adler-32, Ascii85, and Apple's IMA 4:1 audio compression. Whew! So now I just run that utility on a computer, copy the generated firmware file over to the G3, use BBEdit Lite to put the file's contents into the data fork of the old G3 Firmware file (it has a resource fork too and I think it probably needs to keep it), and run the firmware updater. Works fine. I just tested it with the Quadra 700 hidden secret chime and it works great!
I think my phone's microphone doesn't do a great job of recording the sound. There's a small chance my IMA 4:1 encoding isn't 100% correct, but I'm pretty sure it's fine...
I'm running into a problem where sometimes the G3 just shuts itself off randomly and sometimes it doesn't want to boot at all--no chime at all and the thing just sits there. I think it's heat-related because yesterday it didn't act up at all, and today the weather got a lot hotter and suddenly it was acting up. I added some thermal paste between the heatsink and CPU (there was already a pad on it though) and hopefully that'll help out, but it's making me nervous because I really don't want it to shut itself off in the middle of a firmware update. I'm opening the case and blowing a fan on the CPU during my firmware updates now as a precaution. Don't worry though -- it's not related to the firmware hacking. It's some kind of hardware issue.
I've streamlined the whole process now though -- I made a utility in C++ that automatically does all the encoding/decoding/checksumming. You give it the G3 Firmware file from Apple's update, a raw 16-bit big-endian 44.1 kHz sound, and it does the rest. I ended up writing code for Adler-32, Ascii85, and Apple's IMA 4:1 audio compression. Whew! So now I just run that utility on a computer, copy the generated firmware file over to the G3, use BBEdit Lite to put the file's contents into the data fork of the old G3 Firmware file (it has a resource fork too and I think it probably needs to keep it), and run the firmware updater. Works fine. I just tested it with the Quadra 700 hidden secret chime and it works great!
I think my phone's microphone doesn't do a great job of recording the sound. There's a small chance my IMA 4:1 encoding isn't 100% correct, but I'm pretty sure it's fine...
I'm running into a problem where sometimes the G3 just shuts itself off randomly and sometimes it doesn't want to boot at all--no chime at all and the thing just sits there. I think it's heat-related because yesterday it didn't act up at all, and today the weather got a lot hotter and suddenly it was acting up. I added some thermal paste between the heatsink and CPU (there was already a pad on it though) and hopefully that'll help out, but it's making me nervous because I really don't want it to shut itself off in the middle of a firmware update. I'm opening the case and blowing a fan on the CPU during my firmware updates now as a precaution. Don't worry though -- it's not related to the firmware hacking. It's some kind of hardware issue.
swap the motherboard/CPU and see if the problem remains?
Excellent effort. If someone could hack a Macintosh PowerExpress Prototype chime onto one of these, I would go out and buy a B&W G3 just to be able to do it.
You know, these ones...
Macintosh PowerExpress Prototype Boot Chime - 60KB
Macintosh PowerExpress Prototype "Saved Company" Chime - 125KB
Macintosh PowerExpress Prototype "Kill Me!" Death Chime - 115KB
I may have to start digging through the PEx ROM dump and hope for the best in sourcing up clean, digital copies of these.
You know, these ones...
Macintosh PowerExpress Prototype Boot Chime - 60KB
Macintosh PowerExpress Prototype "Saved Company" Chime - 125KB
Macintosh PowerExpress Prototype "Kill Me!" Death Chime - 115KB
I may have to start digging through the PEx ROM dump and hope for the best in sourcing up clean, digital copies of these.
This sounds like the way to go to figure out what's going on.
I'll try to get around to it when I can...too much stuff going on lately.Thank you! If you can find a good quality dump of the sound you want, and it's 2.5 seconds or less in length, it's definitely possible to do. I really do want to publish my code somewhere so anybody can try this at home!
On a side note, does anyone know what the best way is to distribute patches on classic Macs? It's a patch to the data fork that I have to do to both the firmware updater program and the firmware update file itself. Is there a classic program out there that does patches already? I know pretty much zero about Classic Mac programming so I'd like to avoid writing my own classic code if at all possible. I really got into programming (not counting HyperCard) around the time Cocoa was first taking off with OS X, so that's the stuff I know how to do...unfortunately that knowledge is useless on the classic OS. I do know how to do AppleScript if that helps at all.
Sure is. The defacto program to use for patching is ResCompare, written by Michael Hecht. It'll compare resources of two Mac apps, then create a patch application.
olePigeon beat me to it!
I also have a raw extracted "I know that I rescued this company - KILL ME" PEX startup sound. This one is 2.970 seconds long, 44.1 kHz stereo. PM me if you want these.
I have a raw extracted normal PEX startup chime, it is 1.487 seconds long, 44.1 kHz stereo. It is however cut shorter than the MP3 version floating around, likely from a different ROM rev.
I also have a raw extracted "I know that I rescued this company - KILL ME" PEX startup sound. This one is 2.970 seconds long, 44.1 kHz stereo. PM me if you want these.
I'd love a PeX patch for my QuickSilver G4 if that's possible. Man would that be awesome.
Fantastic...looks like that will do the trick! Thanks!
I'm trying to turn this into a usable project that others can try.
I took my code and tried to compile it using MPW, but MPW doesn't have support for the C++ STL classes. I was able to grab an old version of stlport that provides implementations for the missing classes, but I'm still running into problems because MPW's implementation of C++ is too old and doesn't support stuff like ios::binary. Plus, I don't really want to learn the Mac toolbox to make a classic GUI for it anyway.
Is it reasonable, do you guys think, to require a Windows/OS X/Linux computer to patch the firmware file? My main problem with this approach is the "G3 Firmware" file that has to be patched also has a resource fork. So if I patch the data fork in a different OS and transfer it back over, the resource fork will get destroyed. That's why I was hoping to get the patcher to work completely in OS 9. If the file is transferred onto a USB FAT32 drive from OS 9, the resource fork gets saved in a separate file next to it. I'm thinking as a workaround, the OS X/Windows/Linux patcher program could check for presence of that file to verify that the resource fork will be intact when the file is copied back to the OS 9 computer...
Aside from this, it'll require using Audacity (or a similar program) to export the sound as a raw 16-bit, 44.1 kHz sound for input to the patcher.
Also, I haven't tested this on a rev. B blue and white G3 logic board --I don't have any to test with. Does anyone know if the rev. B logic board uses the exact same firmware?
I took my code and tried to compile it using MPW, but MPW doesn't have support for the C++ STL classes. I was able to grab an old version of stlport that provides implementations for the missing classes, but I'm still running into problems because MPW's implementation of C++ is too old and doesn't support stuff like ios::binary. Plus, I don't really want to learn the Mac toolbox to make a classic GUI for it anyway.
Is it reasonable, do you guys think, to require a Windows/OS X/Linux computer to patch the firmware file? My main problem with this approach is the "G3 Firmware" file that has to be patched also has a resource fork. So if I patch the data fork in a different OS and transfer it back over, the resource fork will get destroyed. That's why I was hoping to get the patcher to work completely in OS 9. If the file is transferred onto a USB FAT32 drive from OS 9, the resource fork gets saved in a separate file next to it. I'm thinking as a workaround, the OS X/Windows/Linux patcher program could check for presence of that file to verify that the resource fork will be intact when the file is copied back to the OS 9 computer...
Aside from this, it'll require using Audacity (or a similar program) to export the sound as a raw 16-bit, 44.1 kHz sound for input to the patcher.
Also, I haven't tested this on a rev. B blue and white G3 logic board --I don't have any to test with. Does anyone know if the rev. B logic board uses the exact same firmware?
I think I'm just going to make the G3 chime patcher a native Mac OS X application and forget about Windows and Linux for a GUI for this project. I haven't used Cocoa and Objective-C in a while and I want to get myself back up to speed I'll still make a command line version that can be run on Windows/Linux.
I'll try to make it a universal binary for 10.4 and above. That way you can run it directly on the G3. It'll still require a classic Mac OS version installed to run the firmware update though.
I'll still make a command line version that can be run on Windows/Linux.I'll try to make it a universal binary for 10.4 and above. That way you can run it directly on the G3. It'll still require a classic Mac OS version installed to run the firmware update though.
Would it be too difficult/time consuming to make it OS 9 native? Then it could run in OS X with Classic. Or did I miss understand something?
I haven't been reading this overly closely so I may have missed something, but figured I'd just toss this out there: If this process depends on hacking the original Apple firmware upgrade file this may do bad things if you try running this on a B&W upgraded to a G4 ZIF. One of the things the firmware update did (to substantial outcry) was add a test to see if the user had upgraded to a G4, and if so to halt the machine before booting.
If you actually want to make this something you distribute I might humbly suggest looking at the "Blue & White G4 Enabler" from Newertech:
http://eshop.macsales.com/tech_center/software.cfm
I'm fairly certain the way *it* works is by copying the existing firmware from flash, hacking around the G4 test, and flashing it back. You might want to do the same (IE, copy whatever firmware is already on the G3, hacking the startup sound, and writing it back) to avoid the edge case of bricking someone's G4-upgraded B&W. (Which might be a real problem if they didn't save the G3 ZIF when they upgraded.)
If you actually want to make this something you distribute I might humbly suggest looking at the "Blue & White G4 Enabler" from Newertech:
http://eshop.macsales.com/tech_center/software.cfm
I'm fairly certain the way *it* works is by copying the existing firmware from flash, hacking around the G4 test, and flashing it back. You might want to do the same (IE, copy whatever firmware is already on the G3, hacking the startup sound, and writing it back) to avoid the edge case of bricking someone's G4-upgraded B&W. (Which might be a real problem if they didn't save the G3 ZIF when they upgraded.)
The problem is that I am not familiar with the classic Mac toolbox, and I'm not sure if it's that worth it for me to learn. It's a lot easier to make a Cocoa app where all of the UI setup is given to you "for free". Maybe there are ways around that in classic programs -- I'm not sure. Plus, I only have Apple's MPW for a compiler -- I'm not a big fan of it.
Thank you for that info -- I was not aware of that behavior and it's definitely something I want to protect against.
Sounds like a good idea to me. I think it's pretty easy to read back the firmware because I *believe* running CopyROMs on a New World Mac actually dumps it if I'm not mistaken (rather than the Mac OS ROM file). If not, I know there's a way to do it. The problem with that approach, again, is I have to learn about classic Mac programming :-( It would actually be really interesting if someone could dump the Blue and White G4 enabler ROM -- maybe I could just add the necessary patch to my program and always add the G4 compatibility even if you're not on a G4 (assuming all the Newertech program does is change the firmware)