Modified ROM Updates (Generic & iBook)

[ssp3]

I'd be more concerned about Tiger users than Ventura-schmentura..
(Now I understand why and how applications start to bloat and then drop support for older OSes). 

You have "txbi" is several places in your script, but correct Type is "tbxi" according to all rom files that I've seen. I've fixed this in my app, the info is just for your reference.

Also, there are several conditions where printed out message does not correspond to what's really going on. For example:

1. If checksum has more characters (bytes) than required, it says that rom file has no checksum at the end.
nanopico's ROM for unsopported machines from 2016 is one such example - it has one byte extra.
2. If checksum has less characters than required, it also says that there is no checksum. It doesn't say that the rom file is too short.
3. If I delete a bunch of zeroes somewhere in the middle of rom file, it also doesn't say that the file is too short but happily updates the checksum instead.

Question: doesn't the Mac rom files always have to be exactly in one specific size?

All this checking, double and triple checking of all possible variations is very time consuming.
Making the text messages look "nice" to fit application's window takes some time too.

I am at the stage where I would like the input from other users, especially from those who are on older systems, therefore I will upload a fully working, but sort of, kind of beta version later tonight for others to test.

Cheers!

[ssp3]

So, here it is. Simple drag and drop application.






Just drop your created/modified rom file into application window and it will do the rest.
Make sure to make a backup copy of your rom creation first, because this app will update the checksum no matter what.

PPC/Intel. Should be OK starting from 10.4. I've tested it on PowerBook G4 Leopard, MBP2011 Snow Leopard and MBP2011 Yosemite.
Feedback on how it works on other systems and suggestions are welcome.

Happy patching!

Now I expect that any grandma will be able to operate this thing 


A couple of screenshots of various app's / system messages. Text can be copied, btw.

[joevt]

I'd be more concerned about Tiger users than Ventura-schmentura..
(Now I understand why and how applications start to bloat and then drop support for older OSes). 

I'm using python from tigerbrew so I don't know for sure if it works in Leopard in Tiger. I use tigerbrew to install dependencies for pciutils and flashrom on Tiger and Leopard.

For Tiger, I have to bypass the file type check since there's no xattr command and I don't want to make the user install GetFileInfo or whatever. I've attached an update for that.

You have "txbi" is several places in your script, but correct Type is "tbxi" according to all rom files that I've seen. I've fixed this in my app, the info is just for your reference.

In two places. Inside the message string. It checks for the correct type and only mentions the wrong type if the file type is wrong. Fixed.

Also, there are several conditions where printed out message does not correspond to what's really going on. For example:

1. If checksum has more characters (bytes) than required, it says that rom file has no checksum at the end.
nanopico's ROM for unsopported machines from 2016 is one such example - it has one byte extra.

Nanopico didn't follow exactly the format that exists in a real Mac OS ROM file.
Use xxd or a hex editor to show the last 14 bytes. Don't use a text editor since not all the bytes of the Mac OS ROM are text.

2. If checksum has less characters than required, it also says that there is no checksum. It doesn't say that the rom file is too short.

The attached update now says "Error: the file doesn't have a checksum at the end or it is not in the expected format."

3. If I delete a bunch of zeroes somewhere in the middle of rom file, it also doesn't say that the file is too short but happily updates the checksum instead.

I'm not going to verify the contents of the embedded ELF image.

Question: doesn't the Mac rom files always have to be exactly in one specific size?

I guess maybe the ELF image needs to start at a 4K boundary and it should be a valid ELF image that can be loaded by the ELF loader in Open Firmware.

Actually, I see there's some hard coded values in the code:

Code: [Select]

h# 005000 constant elf-offset
h# 017008 constant elf-size
h# 01C008 constant parcels-offset
h# 261958 constant parcels-size
h# 27D960 constant info-size
I suppose one could find the elf-offset and verify that the ELF image begins there (just look for "ELF" characters at elf-offset + 1) without verifying that the ELF image is valid.

The ELF image starts at offset 0x5000 (20K). The existing Open Firmware code in the ROM file begins at ≈8K and is ≈4K in size. There's ≈2K after the existing Open Firmware code before the filler that exists before the ELF image. So you have ≈6K bytes to add more Open Firmware code. If you need more than 6K or if you change the size of anything after the first 20K then you'll need to change some values.

[ssp3]

Thanks! I'll wait for the input from others before any further changes. The thing works anyway.

Use xxd or a hex editor to show the last 14 bytes. Don't use a text editor since not all the bytes of the Mac OS ROM are text.

Do you really think that I am THAT DUMB? 
See below.

[joevt]

If I write something that makes you think that I think that you are dumb, then pretend that I wrote it for someone else who might be reading this thread.

This is the the last 14 bytes of the original rom:

Code: [Select]

2796808: 0d5c 2068 2320 3139 3842 4632 3346       ".\ h# 198BF23F"
Remember that the code executes the last 12 bytes, which means it executes this:

Code: [Select]

279680A: 2068 2320 3139 3842 4632 3346       " h# 198BF23F"

nanopico's ROM mod adds an extra carriage return (0x0d) at the end:

Code: [Select]

2796808: 0d5c 2068 2320 3139 3842 4632 3346 0d       ".\ h# 198BF23F."

which means the last 12 bytes are these:

Code: [Select]

279680B: 68 2320 3139 3842 4632 3346 0d       "h# 198BF23F."
It will execute without error because Open Firmware treats all white space the same, including carriage returns. However, remember that the checksum is calculated from all the bytes except the last 14. Since an extra character was added at the end, the checksum now includes the initial carriage return at the beginning (at 2796808) so the checksum cannot be 198BF23F even if nothing else was changed.

[ssp3]

joevt, relax, it was a joke 

[joevt]

@ssp3 , I did see the smiley winky face. Perhaps I should have added one of those to my reply. 

[ssp3]

Question: where does 10.2.1 MAC OS ROM file originate from? MDD installer? I got mine from I can't remember where.

I am going to make a patcher to create a PowerBook 5,1 ROM from it for the others to try, but I'd like to have original for the patcher to work correctly.

On related note. Besides 9.6.1 and 10.2.1 what other versions are available and where to find them.

[joevt]

Question: where does 10.2.1 MAC OS ROM file originate from? MDD installer? I got mine from I can't remember where.

I am going to make a patcher to create a PowerBook 5,1 ROM from it for the others to try, but I'd like to have original for the patcher to work correctly.

On related note. Besides 9.6.1 and 10.2.1 what other versions are available and where to find them.

macintoshrepository.org has a list of roms under "All Macintosh ROMs (68K + PPC)".

There's rom files at https://github.com/sentient06/MacROMan/tree/master/TestImages/New%20World%20ROM
which includes origins for most off them except 10.2.1.

10.2.1 is the last in those lists. Googling "rom" "10.2.1" says it's from Mac OS 9.2.2 retail.

[ssp3]

Thanks, but both links have ROM files that have their Resource forks chopped off! WTF, as they say.. 

[ssp3]

So far I was able to dig up 9.2.1; 9.3.1 and 9.7.1.
9.5.1; 9.8.1 and 10.1.1 would be most interesting for me.

Downloading ~4GB images from various places is very time consuming. And very frustrating after you find out that it contains the same 10.2.1 version.

MacTron, do you still have these somewhere available for download? Quote is from 2014.. 

This is what I have:

Mac OS ROM 8.8.1
Mac OS ROM 10.2.1
Mac OS ROM  10.1.1
Mac OS ROM  10.2.1
Mac OS ROM  9.1.1 *
Mac OS ROM 1.8.1
Mac OS ROM 2.0.2
Mac OS ROM 2.3.1
Mac OS ROM 2.5.1
Mac OS ROM 3.0
Mac OS ROM 3.7
Mac OS ROM 6.1
Mac OS ROM 7.5.1
Mac OS ROM 8.4
Mac OS ROM 8.6.1
Mac OS ROM 9.7.1
Mac OS ROM 9.8.1 Custer
Mac OS ROM 9.5.1

I'm uploading it to my FTP folder...

[vaccinemedia]

OS9 ROM Fixer does not appear to work on Tiger - I'm installing Sorbet Leopard to see if it works on that. The app shows an error regarding a missing module which I'm sure is due to the default python 2.x on Tiger not having the necessary modules installed by default.

[vaccinemedia]

I can confirm that OS9 ROM Fixer does indeed work on Leopard I used it to try and fix a ROM patched using ataboot.py but it said it was already OK. My issue now is that the ROM file does not contain the resource fork or info data. There's two extra files it generated with .idump and .rdump extensions but I don't know what to do with them / how to import them into the ROM file