• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Macintosh IIfx ROM Modifications

jmacz

68020
Most people will opt for the Rominator or similar custom ROM (derived from the IIsi) which works great on the IIfx. But I kind of wanted the stock IIfx ROM but with the memory test disabled in order to boot faster. So I decided to modify the IIfx ROM as a learning exercise. I'm posting this as a reference for anyone interested.

Code:
; Disable the checksum check. Could have changed the checksum
; but decided to leave it in case anything reads the checksum
; and is expecting the stock value. Change:

0004123a : 4efa 053c
0004123e : 4a86
00041240 : 6600 1f18

; to be:

0004123a : 4e71
0004123c : 4e71
0004123e : 4e71
00041240 : 4e71
00041242 : 4e71

; Disable the memory tests. Change:

000414f0 : 4cfa
00041608 : 4cfa

; to be:

000414f0 : 4ed6
00041608 : 4ed6

; If you want to change the happy mac icon on boot, the icon is at:

000017F2 : 128 bytes (32 x 32 bits)

; and the mask is at:

00001872 : 128 bytes (32 x 32 bits)

I'm using a Caymac Vintage Universal 4MB ROM and burned it using the Caymac programmer.
 
Not sure if that’s already documented somewhere but it would be neat to have the same done to the stock SE/30 ROM. Removing the memory check but keeping the checksum stock to keep it working with accelerators that base their machine identification on the ROM checksum.
 
How difficult is it to substitute bytes in unused areas to make the checksum match? May need a math major for this.

I was thinking about using the same bit in PRAM as later machines to disable memory check at startup. Maybe hack the Memory control panel to always show that option?
 
Not sure if that’s already documented somewhere but it would be neat to have the same done to the stock SE/30 ROM. Removing the memory check but keeping the checksum stock to keep it working with accelerators that base their machine identification on the ROM checksum.

Hmm, I thought I saw this somewhere... but wouldn't you want it done on a IIsi-based ROM to be 32bit clean?

How difficult is it to substitute bytes in unused areas to make the checksum match? May need a math major for this.

Interesting thought.

BTW, just did the same for my IIci. Posted it separately for search reasons.
 
but wouldn't you want it done on a IIsi-based ROM to be 32bit clean?
That messes with the way the Turbo040 behaves under certain circumstances because it thinks it’s running in a IIsi.

I for my part am fine with using MODE32 and never really got why everyone is after having 32bit clean ROMs.
 
How difficult is it to substitute bytes in unused areas to make the checksum match? May need a math major for this.

I was thinking about using the same bit in PRAM as later machines to disable memory check at startup. Maybe hack the Memory control panel to always show that option?

Not easy - the DeclROM checksum is the same algo iirc and I've found it pretty resistant to tampering. It's nothing complex, but it's definitely enough to be annoying if you wanted to deliberately bypass it. Due to how the algo works it has a bias towards more "recent" data first, so changes in early ROM would be quite a complex problem to deliberately fix.

That messes with the way the Turbo040 behaves under certain circumstances because it thinks it’s running in a IIsi.

I for my part am fine with using MODE32 and never really got why everyone is after having 32bit clean ROMs.

Same here, to be honest. I have an OEM IIsi ROM in one of my "done" machines just so it can run 8.1 for giggles, but that's about it.

If we want to get nauseatingly specific: if you have one of my boosters that has been updated with the ROM-boost function, and an IIsi ROM on a 3rd party SIMM, it can speed up quickdraw nicely as 32 bit QD is in ROM rather than running out of RAM with the SE/30 ROM.
 
Just mode 32 won’t remove the men check though right? that’s the primary reason why I swapped the ROM.

I am playing with the stock ROM. Will see if I can patch it shortly.
 
I was recapping an SE/30 for a forum member and had my SE/30 opened up to test. So spent a few minutes patching the stock ROM, writing it to a Caymac ROM, and tried it. Seems to work? Posted the changes + a ZIP of the modified stock ROM here:

 
Not easy - the DeclROM checksum is the same algo iirc and I've found it pretty resistant to tampering. It's nothing complex, but it's definitely enough to be annoying if you wanted to deliberately bypass it. Due to how the algo works it has a bias towards more "recent" data first, so changes in early ROM would be quite a complex problem to deliberately fix.
My understanding is that the ROM checksum is really just addition of the whole ROM 16 bits at a time, with the result truncated to 32 bits. If your changes are small, you need to just flip an equivalent value of bits anywhere else in the ROM to preserve the checksum. So I think the tricky part is only finding some space to write garbage.
 
My understanding is that the ROM checksum is really just addition of the whole ROM 16 bits at a time, with the result truncated to 32 bits. If your changes are small, you need to just flip an equivalent value of bits anywhere else in the ROM to preserve the checksum. So I think the tricky part is only finding some space to write garbage.
It's a 32 bit rotate left then 32 bit add. The add alone would be trivial, but the rotate would need to be compensated for and that gave me fits when I was looking into it previously. It's a solvable problem, I'm sure, but was too complex for me to immediately see a path forward without *a lot* of work.
 
It's a 32 bit rotate left then 32 bit add. The add alone would be trivial, but the rotate would need to be compensated for and that gave me fits when I was looking into it previously. It's a solvable problem, I'm sure, but was too complex for me to immediately see a path forward without *a lot* of work.
That's not how I have been computing them, and I think the code in the ROM does what I described. The only other transformation I can think of that would possibly be involved is an endianness conversion if you're computing on a modern system.
 
That's not how I have been computing them, and I think the code in the ROM does what I described. The only other transformation I can think of that would possibly be involved is an endianness conversion if you're computing on a modern system.
Oh, yeah, that's different from the DeclROM checksum. My bad. Yes, that would be far easier to spoof.
 
Yes, same. People getting so keen on ROM swaps baffles me slightly.

Yeah, my only desire is to disable the memory check. Too slow :) Hence the change to only disable the memory check.

Might be cool to do the bit twiddling to result in the same checksum as it preserves the checksum check which is a good thing to have. Since the change to disable the memory check is an early return from two checksum functions, there's certainly some space in the rest of the functions to do it.
 
Back
Top