Could this potentially open up the possibility of enabling native OS 9 booting on newer machines? Just curious.

Click to expand...

Sadly, I doubt it -- the newer machines would need new hardware drivers to work in OS 9 (I think). I'm trying to avoid playing with code at all. It's likely beyond my capabilities...there's always a chance that the work could help someone with more intimate knowledge get closer to that goal, though. I dunno.

I did play around a little bit more with the ROM today. I was able to decode the data I mentioned earlier using this program. It's definitely Ascii85 encoding.

I don't know if it's perfect decoding or if there's something I'm doing wrong. Near the beginning of the decoded binary file I'm definitely finding some complete ASCII strings. Later on, I'm also finding some other ASCII strings that have characters like 0xFF in strange unexpected places in the middle of them. I can't figure out if this is a decoding error or intentional. The decoded length doesn't seem to match the length that the script specifies, so it's possible I'm missing something. There's also an Adler-32 checksum involved, so I should be able to make sure I have the right data by calculating the checksum. I haven't played extensively with this yet.

The startup chime is at the end of the decoded binary file. I can tell it's sound data because it sounds like the startup chime, but I can't get the pitch to match up and it's pretty scratchy. I really hope it's not compressed...

Edit: Got the decoded binary length to match the length listed in the G3 Firmware file after running the decoder on Linux instead of Windows. I'm thinking redirecting stdout to a file in Windows does LF to CRLF conversions, so that probably broke it. Even with the match, there are still weird characters and the sound data is still strange. Next step is to get the Adler checksum to match...