• Hello Guest! We're hosting a challenge to welcome vintage Intel macs to the MLA during the month of July! See this thread for more information.
  • We've made some quality of life improvements to the Trading Post. More info here.

Macintosh IIcx custom ROM

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.
 
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.
 
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?)
 
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.
 
@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.
 
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)
 
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)
 

Attachments

  • IMG_20260714_000955428.jpg
    IMG_20260714_000955428.jpg
    3.8 MB · Views: 5
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.


Also 0x02AE is the ROM base global. So you could DM 2AE to see what that shows too.
 
Last edited:
@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
 
Back
Top