68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
Macintosh IIcx custom ROM
Posted by: Phipli on 2026-07-13 11:12:17
Scratch that, maybe this isn't an issue. Yes different memory controllers, but they both end up calling MOD3TEST and REVMOD3TEST. So after thinking about this, this hypothesis is likely flawed.
The IIsi ROM is a "universal" ROM - it has code in it for multiple model computers. It doesn't blindly execute the setup for the IIsi only, but checks the host box ID and sets up the hardware for that. It even does some testing and dynamically reacts to what hardware is physically present. It contains parameters for the IIcx.
Posted by: frontein1 on 2026-07-13 11:14:45
The IIsi ROM is a "universal" ROM
Yes 100%. As long as the IIsi ROM was patched correctly, the memory test should be skipped on the IIcx.
Posted by: Phipli on 2026-07-13 11:18:13
Yes 100%. As long as the IIsi ROM was patched correctly, the memory test should be skipped on the IIcx.
Ah sorry, I misunderstood - I thought you meant it wouldn't boot the IIcx, I realise you meant execution would take a different path that might miss the IIsi style patch.

But as you decided yourself, yes I think the common patches generally work because people use the usual patches on the SE/30 which is basically a less good IIcx with the same chipset and less expansion.
Posted by: luRaichu on 2026-07-13 11:23:52
Did you remove that jumper when you installed the ROM SIMM?
Yes. I know I'm running the IIsi ROM since the 32-bit addressing option appears in the Memory control panel.
Posted by: frontein1 on 2026-07-13 12:21:08
Through debugger, do a DM 408467E0. And also a DM 408468F8. Share the output here. The first two bytes of each should be 4ED6.

(Is the ROM base 4000 0000 or 4080 0000 on the IIsi, I can't remember?)
Posted by: Phipli on 2026-07-13 12:51:00
Through debugger, do a DM 408467E0. And also a DM 408468F8. Share the output here. The first two bytes of each should be 4ED6.

(Is the ROM base 4000 0000 or 4080 0000 on the IIsi, I can't remember?)
4000 0000

1000036884.jpg
Posted by: croissantking on 2026-07-13 14:26:52
4000 0000
Same as the PB 500 series @frontein1 ! And I guess many other models.

I don't fully understand why the ROM gets moved from 0000 0000 on first access, and in general why there are duplicate images of it.
Posted by: Phipli on 2026-07-13 14:38:31
Same as the PB 500 series @frontein1 ! And I guess many other models.

I don't fully understand why the ROM gets moved from 0000 0000 on first access, and in general why there are duplicate images of it.
Hum, the exception table needes to be at zero (on the 68000 at least), and needs to be writeable, but the 68k reset vector points to zero so ROM needs to be there too.

Plus it slightly improves maths because ram addresses are more frequently absolute instead of offset + address. Saves a bit of time frequently enough to improve performance. Probably other reasons and I'm sure I'm mangled it.
Posted by: frontein1 on 2026-07-13 19:43:13
@luRaichu, DM 400467E0 and then DM 400468F8 from the debugger (MacsBug or MicroBug). You'll want to use these addresses that start with 400 instead of 408. Let's at least confirm that the first 2 bytes of each display the patched 4ED6 bytes.
Posted by: luRaichu on 2026-07-13 20:57:11
@luRaichu, DM 400467E0 and then DM 400468F8 from the debugger (MacsBug or MicroBug). You'll want to use these addresses that start with 400 instead of 408. Let's at least confirm that the first 2 bytes of each display the patched 4ED6 bytes.
Posted by: frontein1 on 2026-07-13 21:05:39
Well that is interesting, and at least not what I expected. Do a DM 40000000. Let's see what the first 4 bytes (ie checksum) is for the ROM. (Or check TattleTech or something similar to get the checksum that way)
Posted by: luRaichu on 2026-07-13 21:10:30
Well that is interesting, and at least not what I expected. Do a DM 40000000. Let's see what the first 4 bytes (ie checksum) is for the ROM. (Or check TattleTech or something similar to get the checksum that way)
Posted by: frontein1 on 2026-07-13 21:17:38
Is it easy for you to install a program like TattleTech? Under General you can scroll down to the ROM section and get some really useful info like ROM Checksum and ROM Start.

TattleTech - Macintosh Garden

TattleTech is a System Profiler, Tech Support tool, and Bug Reporter application. It was formerly called TattleTale.
macintoshgarden.org macintoshgarden.org

Also 0x02AE is the ROM base global. So you could DM 2AE to see what that shows too.
Posted by: Phipli on 2026-07-14 01:11:16
@frontein1

Just for completeness - I realise you asked about the IIsi ROM location, but the address decoding of the ROM is a really a physical property of the host and so we should be considering the ROM location in the IIcx. They're the same, but if they were different, the Universal ROM would have to cope with both.

This is the IIcx Memory Map (running only)...

1000036888.jpg
Posted by: PappaDF on 2026-07-14 03:42:25
Are you running in 32-bit or 24-bit mode in these examples? You wrote that the 32-bit addressing option "appears", but was not clear to me if it actually was enabled or not.

The address map (figure 3-7) represents the 32-bit "physical" address map, and the "DM" command operates on logical addresses if I'm not mistaken. Consequently, in the event that you are running in 24-bit mode, "DM 400467E0" would be stripped to "0467E0" and you would end up RAM instead.
Posted by: luRaichu on 2026-07-14 06:29:33
Are you running in 32-bit or 24-bit mode in these examples? You wrote that the 32-bit addressing option "appears", but was not clear to me if it actually was enabled or not.
Sorry, I was in 24-bit mode.
ROM base is 40800000.
Posted by: frontein1 on 2026-07-14 21:17:13
Right checksum for the IIsi. Also I think those two additional DM's show the right patches to bypass the memory testing. So....... Not quite sure why the cold boot with this ROM = the cold boot with your onboard IIcx ROM. Nothing odd plugged in, accelerator cards, invalid PRAM, etc etc?
1784088948367.png
Posted by: luRaichu on 2026-07-15 14:00:02
So....... Not quite sure why the cold boot with this ROM = the cold boot with your onboard IIcx ROM. Nothing odd plugged in, accelerator cards, invalid PRAM, etc etc?
My IIcx won't save PRAM. It has a new battery. I've already reset it...
I'm not getting the RAM test at this time, shutting down the computer and starting it back up 5 minutes later.
Posted by: Phipli on 2026-07-15 14:22:05
My IIcx won't save PRAM. It has a new battery. I've already reset it...
I'm not getting the RAM test at this time, shutting down the computer and starting it back up 5 minutes later.
That explains why it is slow booting. It takes much longer to start if the right startup options aren't in PRAM.

The easy way to tell is the memory test happens while the screen is black, but the SCSI search happens while it is grey halftone, if I remember correctly.
Posted by: luRaichu on 2026-07-16 17:16:08
Found two broken traces in the RTC circuit.
IMG_20260716_193542820.jpg
PRAM saves now. However, as I said the RAM test somehow became disabled before these repairs. I'm currently clocking 9 seconds for startup.
< 2