Macintosh IIci ROM Modifications

[jmacz]

Similar to the modifications I recently made on the IIfx ROM, I've done the same on the for the IIci.

Again, most people will opt for the Rominator or similar custom ROM. But I kind of wanted the stock IIci ROM but with the memory test disabled in order to boot faster. Again, posting this as a reference for anyone interested.

; 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:

000435b2 : 4efa 10dc
000435b6 : 4a86
000435b8 : 6600 0360

; to be:

000435b2 : 4e71
000435b4 : 4e71
000435b6 : 4e71
000435b8 : 4e71
000435ba : 4e71

; Disable the memory tests. Change:

000446bc : 4cfa
000447d8 : 4cfa

; to be:

000446bc : 4ed6
000447d8 : 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)

 

[ViperLord]

For the life of me, I haven't been able to get this to work. Did the hex edits, offsets and values matched. Got it flashed over, just black screen. Flash stock rom, and it boots. Tried with just the disable checksum check part and it worked, so edited the memory test section, and no go..So whatever my issue is, narrowed it down to the memory test disable part.

 

[ViperLord]

Not sure if it maybe part of it, but this is a parity model of IIci. Not to say this battery bombed, leaking cap as/is unit is fully good, but so far the only thing that doesn't seem to work is sound, since I haven't replaced those caps yet, not surprising.

 

[jmacz]

That’s weird. I have a flashed ROM working fine in my IIci. I will reconfirm with my ROM and make sure I didn’t make a typo but if the stock instructions at those offsets match, I doubt it’s a typo. Can’t look til tomorrow but will check.

 

[frontein1]

this is a parity model of IIci

I was today years old when I discovered that the IIci has an optional Parity-Generator Chip (PGC). I have similar patches that @jmacz posted for my IIci and it works fine. BUT I do NOT have the PGC chip.

I see some extra code in the IIci that is not in the IIsi related to parity checking. So I am wondering if there is an edge case here that needs to be accounted for with the IIci. Very interesting!

 

[jmacz]

@frontein1 is probably right. I've confirmed the patches are working fine on my IIci but I also do not have a parity model. Skipping the memory test procedures must be skipping some step required by the parity check later.

 

[jmacz]

The two patched routines just perform a memory check (one in ascending direction and one in descending direction). The patch just returns from them immediately without running the test. If any errors are encountered, one of the registers holds this state. I'm not sure why skipping it would cause your parity model IIci to freeze. Probably needs a deeper look.

One thing you can try experimenting with is forcing the parity test routine to also return early. I believe it's at offset 0x45e32 and the existing instruction is 4e7a... you can try changing that to a 4ed6 and see if it changes anything? Otherwise, it probably needs a deeper look.

 

[ViperLord]

The two patched routines just perform a memory check (one in ascending direction and one in descending direction). The patch just returns from them immediately without running the test. If any errors are encountered, one of the registers holds this state. I'm not sure why skipping it would cause your parity model IIci to freeze. Probably needs a deeper look.

One thing you can try experimenting with is forcing the parity test routine to also return early. I believe it's at offset 0x45e32 and the existing instruction is 4e7a... you can try changing that to a 4ed6 and see if it changes anything? Otherwise, it probably needs a deeper look.

Gave that a shot, but similar results (I tried it in BaskilliskII and was hopeful it booted, but guessing none of the emulators cover this extra bit).

I swapped over to one of the IIsi modded roms, and it boots, disk image, etc. But throws a warning that the parity circuitry isn't functioning, shutdown or continue, which I've never seen w/IIci roms, guessing they don't have the extra ROM side (understandable). Also boots into 24-bit mode first, restart 32-bit, but guessing that's more due to the missing battery

 

[frontein1]

I was just thinking about this. Wish I had a PGC-equipped IIci to test with It is pretty late and I could probably find a better way to explain what I am thinking, but here is a try:

That parity bit must have something to do with this. The Mod3 and RevMod3 tests essentially write to all memory. For a parity-enabled machine this might also have the salient benefit of 'initializing' all the parity bits to be accurate. So without doing this, and if some parity bits have garbage from the power-on, there is only a 50% chance that the garbage is accurate.

 

[ViperLord]

Interesting, so in that case skipping the checks fully wouldn't work, would need an abbreviated check that only did the parity bit (if that's possible), Would still take a little extra time, but probably a lot less that a full ram test.

Do failed RAM (and assuming parity probably as well) result in Sad Mac? Curious since all I've seen has been black nothing.
I get some of the basics of this, but certainly more complicated tham the sysv skips I did to run Apple Menu Options and Stickies from 7.5 on 7.1 w/o the version warnings.

 

[jmacz]

I was just thinking about this. Wish I had a PGC-equipped IIci to test with It is pretty late and I could probably find a better way to explain what I am thinking, but here is a try:

That parity bit must have something to do with this. The Mod3 and RevMod3 tests essentially write to all memory. For a parity-enabled machine this might also have the salient benefit of 'initializing' all the parity bits to be accurate. So without doing this, and if some parity bits have garbage from the power-on, there is only a 50% chance that the garbage is accurate.

I think you're right. Without writing to all the memory locations once, the parity bits would be wrong.

Interesting, so in that case skipping the checks fully wouldn't work, would need an abbreviated check that only did the parity bit (if that's possible), Would still take a little extra time, but probably a lot less that a full ram test.

The parity bit is read/written by hardware. The two memory tests are oblivious to the parity bits if memory serves me correct. They just repeatedly write a pattern to all of the memory and verify the result.

I think you could make things faster with a simplified write to all of the memory (ie. skip the pattern, skip the verification), but I think @frontein1 is correct that you would have to write to every location once so you can't skip it.

 

[jmacz]

@ViperLord try one more thing. I'm not 100% positive I got these offsets right... but try patching these two locations instead (ie. only do the checksum disabling patch and the following two below)

Offset 0x44714 ... change 2448 to 4ed6
Offset 0x44822 ... change 2449 to 4ed6

These two patches break out of the memory test routines after they have written all of memory once. See if that allows your system to boot. If so, it should validate the theory that the parity bits need to be initialized. Also see if the above patch is any faster than stock for the memory tests (it essentially skips the validation portion). If that doesn't work, then I either got the offsets wrong or someone needs to investigate further.

If it does work however, you could also theoretically just do the first of the two patches above... and instead of the second one at offset 0x44822, replace that one with the second of the two original memory patches (0x447d8 to 4ed6). That leaves only a single write to all of memory (in the first routine) and skips the entire second routine. That should make it even faster. If that also works (and is a bit faster), the next step would be to just replace the first routine with a fast write to the entire memory space.

 

[jmacz]

(deleted) -- had a note here that the patch might not work because I missed a register restore but realized I was looking at the wrong section so ignore this post. Hope that patch results in a proper boot. Let me know.