G3 Blue and White custom startup sound ROM hack -success!!

[iMac600]

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.

 

[dougg3]

swap the motherboard/CPU and see if the problem remains?

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.

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.

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.

 

[olePigeon]

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.

 

[Dennis Nedry]

olePigeon beat me to it!

ResCompare is awesome for making classic patches. It creates an actual executable file so you don't even need ResCompare to apply the patch.

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.

 

[olePigeon]

I'd love a PeX patch for my QuickSilver G4 if that's possible. Man would that be awesome.

 

[dougg3]

Fantastic...looks like that will do the trick! Thanks!

 

[dougg3]

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?

 

[dougg3]

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.

 

[olePigeon]

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?

 

[Gorgonops]

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.)

 

[dougg3]

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?

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.

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.

Thank you for that info -- I was not aware of that behavior and it's definitely something I want to protect against.

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.)

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)