Another IIci ROM hack

[dougg3]

What happens when you put the jumper in the other position? Does it boot fine from the motherboard ROM no matter whether the jumper is on or off?

The Quadra 700's ROM SIMM socket automatically disables the onboard ROMs when a SIMM is inserted:

A ROM SIMM socket is available for future expansion;however, when a ROM SIMM is installed in this socket, the on-board

ROM will be automatically disabled.

http://developer.apple.com/legacy/mac/library/documentation/Hardware/Developer_Notes/Macintosh_CPUs-68K_Desktop/Mac_Quadra_700.pdf

Maybe the IIsi behaves the same way?

 

[ojfd]

Guys,

I'm not a programmer, so I apologize upfront if I post something silly on this topic, but, in MPW Golden Master package is one folder called ROM maps with whole bunch of files

I opened file MacIIsiROM.lst in BBEdit, and for me it looks like a description of a boot sequence. Can that be of any help? How far off am I? (flame suit on and ducking)

Small excerpt:

seg RAM FD

loc 0

RAMStart RAM FD,0

RAMEnd RAM FD,1FFFFE

size RAM 1FFFFF

seg Main 75

MYFIRSTPROC Main $75,$0 #

BASEOFROM Main $75,$0 E

MYROM Main $75,$0 #

DISPOFF Main $75,$22 E

CRITICAL Main $75,$26 E

ROMLOC Main $75,$2E E

STARTINIT1 Main $75,$B8 E

BOOTRETRY Main $75,$1A6 E

EGRETPATCHCONT Main $75,$1DC E

EGRETPATCH1CONT Main $75,$200 E

SOUNDINITPATCHRTN Main $75,$322 E

PATCHSPACE1 Main $75,$380 #

JMPTBLINIT Main $75,$470

JMPTBL2 Main $75,$472 E

NEWTRANSLATE24TO32 Main $75,$47E E

FILLWITHONES Main $75,$480 #

COMPBOOTSTACK Main $75,$490 #

SETUPSYSAPPZONE Main $75,$4B0 #

DRAWBEEPSCREEN Main $75,$530 #

INITSHUTDOWNMGR Main $75,$580 #

INITHIMEMGLOBALS Main $75,$590 #

INITGLOBALVARS Main $75,$600 #

SWITCHGOODIES Main $75,$6F0 #

WDCBSWOS Main $75,$75C E

PMSPSWOS Main $75,$75E E

INITSWITCHERTABLE Main $75,$760 E

GETPRAM Main $75,$780 #

WHICHCPU Main $75,$7C0 #

WHICHBOARD Main $75,$7F0 #

SETUPTIMEK Main $75,$800 #

RUNDIAGS Main $75,$8E0 #

STARTTESTFLAGS Main $75,$908 E

SETUPHWBASES Main $75,$910 #

INITSCSI Main $75,$9A0

INITIWM Main $75,$9C0

INITSCC Main $75,$A30 E

CONFIGURERAM Main $75,$A70 #

INITVIDGLOBALS Main $75,$BE0 #

RDVIDPARAM Main $75,$BF0 #

OPENSDRVR Main $75,$CA0

----------

etc

 

[dougg3]

Yep, I have those -- they were very helpful while I was customizing the startup chime in the IIci Thanks for pointing it out again though, these ROM maps are extremely useful!

 

[olePigeon]

My IIci boots with both the Daystar 040 and the SIMM installed when flashed with the default IIci ROM. So we can rule out a hardware conflict. It did not boot with the modified ROM with the Daystar patched in. However, since the dump I provided and the one trag provided were different, I wonder if there was a small error in there someplace.

 

[olePigeon]

Oh! Oh! I just had a wicked thought. OK, I know I said no LEDs on the Jolly Roger... but I couldn't help thinking: what if the LEDs light up when you write to the SIMM? } Hehe.

 

[bbraun]

I put my disk image onto a floppy and booted with a stock ROM just to check things out. The problem with the System wanting to root off the SCSI drive instead of the floppy it booted from happens even with the normal floppy driver. So, I'm claiming this isn't my bug.

But the mouse does work, so that's probably my bug.

This is what you'd see if SCC interrupts weren't getting through.

Thanks! I shouldn't be doing anything with interrupts or VBL tasks, but if there's some double-duty the floppy driver was doing, I'm definitely not doing it.

Here's my understanding of how the mouse works, so correct me if I'm wrong: SCC interrupt fires, the interrupt handler puts the mouse location in MTemp. Then the cursor VBL task reads the MTemp values, smooths them out, updates RawMouse, and updates the actual cursor on the screen. The CrsrVBLTask should be invoked (eventually) by the DoVBLTask() function, which pulls the address of the CrsrVBLTask from 0x8EE low memory global.

In my situation, MTemp is being updated, so it looks like the SCC interrupt is firing, but RawMouse is never updated so it looks like CrsrVBLTask is never being invoked. In fact, if I open up microbug and start executing at the address stored at 0x8EE, the mouse updates to where ever I moved it, so it looks like MTemp is correct. But for whatever reason, the cursor vbl task isn't being called.

My code shouldn't be doing anything with VBL or interrupts, so I've definitely got a bug somewhere!

 

[olePigeon]

Out of curiosity, how fast is the ROM compared to the SCSI BUS?

Edit: Hat trick! Page 22.

 

[bbraun]

It should be identical to a RAM disk, since they're basically doing the same thing, except no writing. It is a bummer that it copies the blocks from ROM to RAM (or in the case of RAM disk it exists in RAM twice, then if you have a block cache, it can exist in RAM 3 times!), but such is the nature of abstraction layers, I guess.

Booting isn't a good comparison right now, but the INIT method works OK. For non-booting disk images, it's convenient to have stuffit expander & resedit "always" available in ROM.

 

[Trash80toHP_Mini]

What happens when you put the jumper in the other position? Does it boot fine from the motherboard ROM no matter whether the jumper is on or off?

:I OOPSIE!!!!!!!!!!!!! The base config for the IIsi is NO JUMPER at all!

I forgot that I had to snatch one of the addressing jumpers off a ColorPivotII/IIsi Card for my first round of testing with the hacked ROM SIMM. :

Besides my usual allotment of ID10t errors, efficiency is severely hampered . . .

. . . I'm coming down with a nasty head cold . . .

With the jumper shorting the pins, the IIsi doesn't boot at all.

____When I use the IIsi ROM Image on the stock Rev 0 and the Rev 1 Jolly Roger ROM SIMMs it boots fine

____The Quadra 650 ROM Image boots my IIsi when installed in both ROM SIMMs, IIRC.

________For now, I can confirm that it boots my IIsi in the Jolly Roger, I'm not munging up my ROMs any more tonight.

So I've got a pair of bootable ROM SIMMs for my IIsi, one with a MUUUCH more generous memory mapping structure . . .

. . . but, ostensibly, similar PseudoSlot address (3 Slots) limitations. :-/

Now if I were to try a Quadra 950 ROM Image . . . }

< . . . scratches head, still wondering how a IIx with a IIsi ROM SIMM on board can handle ALL SIX Nubus slots . . . >

 

[dougg3]

My IIci boots with both the Daystar 040 and the SIMM installed when flashed with the default IIci ROM.

OK, since it boots with a default IIci ROM image stored in the big chips, that means the Daystar ROM is not causing any problems at all. We can forget about having to mess with the Daystar ROM [Edit: What I mean is that means that the Daystar ROM is not conflicting with the space taken up by the larger chips. So we don't have to bother with appending the Daystar ROM contents to the end of the normal ROM.]

As far as trag's and your dump differing, I still believe that trag's dump shows that the chip contains encrypted code, and that the Daystar card itself decrypts the contents of the chip on the fly before putting it onto the Mac's data bus. You're dumping the unencrypted version of the chip's contents by looking at it directly through the Mac after the card has decrypted it. That's my theory anyway. I don't have any other explanation...

As we already talked about in PM, I'm thinking that the Daystar ROM looks specifically for certain Mac ROM checksums to match against the Mac models it supports. I'll have to look through the Daystar code to see if I can find *anything* supporting this theory (or wild guess, as it may be). It may be as simple as leaving the IIci's stock checksum alone, because the Daystar card will add its own checksum disabling patch anyway. We could also put the same checksum disabling patch into the ROM, so that way it would work with or without the Daystar card.

If it's not that, it's probably the startup chime code. I see no reason why the custom icons would cause the Daystar card to go haywire, unless it specifically looks to make sure the original happy Mac icon is in place already.

Oh! Oh! I just had a wicked thought. OK, I know I said no LEDs on the Jolly Roger... but I couldn't help thinking: what if the LEDs light up when you write to the SIMM? } Hehe.

I have a single LED on the board. I'd like to keep it as only one, so you might have to consider an eye patch on the Jolly Roger's other eye or something ;-) Anyway, I see no reason why we can't do that!

 

[dougg3]

:I OOPSIE!!!!!!!!!!!!! The base config for the IIsi is NO JUMPER at all!...

With the jumper shorting the pins, the IIsi doesn't boot at all.

All right So it's backwards from the IIci.

Excellent! That means the jumper is indeed disabling the IIsi's onboard ROMs. So let me get this straight -- now that you've shorted the jumper pins, the Quadra 650 image works now too? If so, good! We're getting somewhere

 

[olePigeon]

IIsi backwards from the IIci? News to me. )

 

[Trash80toHP_Mini]

All right So it's backwards from the IIci.

Apparently.

Excellent! That means the jumper is indeed disabling the IIsi's onboard ROMs. So let me get this straight -- now that you've shorted the jumper pins, the Quadra 650 image works now too? If so, good! We're getting somewhere

Yes, we do seem to be, Quadra 650 ROM SIMM boots the IIsi just fine and dandy from what I can tell.

edit:

Edit: Hat trick! Page 22.

Yup and everybody on this page is online as I type this! 11:23 EST Nov. 23

edit: just lost olePigeon . . .

 

[dougg3]

I'm thinking that the Daystar ROM looks specifically for certain Mac ROM checksums to match against the Mac models it supports.

This is looking more and more likely to be the case. I just searched olePigeon's Daystar ROM dump, and it contains at least TWO instances of every supported Mac's ROM checksum. A few of the checksums are in there more than twice, too. I'll bet that's what is going on...I'll disassemble the code to confirm, but I'm guessing that if it doesn't match one of those in the list, it errors out with the chimes of death...

 

[dougg3]

And yeah, I'm too tired to go into too much depth, but there is code at the beginning of the Daystar ROM that loops through a table containing info about each Mac model that the Turbo 040 works with. It matches the machine it's currently running in against the table using the first four bytes of the Mac's ROM, a.k.a. the stored checksum. Once it finds a match, it does extra things based on other stuff stored in that entry in the table. If it doesn't find a matching entry in the table (which it wouldn't in olePigeon's case), it skips all the extra stuff that it does and immediately returns from that function. It looks like the IIci doesn't instruct to do anything special there, but the IIci's table entry also contains other addresses and stuff that are undoubtedly used by other sections of the Daystar ROM.

Bottom line is that the checksum bytes in the file *do* matter, and that's what is causing the custom ROMs to fail when the Daystar card is inserted.

 

[techknight]

Well if thats the case, spoof it. you can either modify the daystar ROM and put in the checksum your ROM uses, OR, somehow make some combinational logic circuits between the daystar and the system bus, when the daystar fetches the checksum, "spoof" it by pointing to an unused portion of your SIMM that contains the checksum. For example if the card is fetching beginning of ROM, (I dont know the address, but lets hypothetically say its at 4000000). Have the decoder lock it, and then "switch" the assertion to a different address line so it fetches A000000 instead of 4000000 which contains your cloak table. Hypothetically. You know what i mean. i hope.

Or you could make a new SIMM with an MCU that is dedicated as a MACM (Memory Access Control Module.) that pays attention on how the ROM is accessed, and is able to differentiate and determine the checksum fetch access from the PDS slot aside from the main system, and it redirects to your cloak table. This option would be the hardest, but less parts count. Just some ideas.

easiest would probably adding your checksum in the daystar ROM. Hardest would be the memory MCU method.

 

[bbraun]

Taking the conservative side here, unless we know what Daystar is patching, and that it is compatible with the modifications made to the ROM, it's probably not the safest best to hack it to use a ROM that it doesn't know about. It is likely the failures you'd run into will be subtle and encountered down the road. Heck, the IIsi ROM in the IIx is even documented to work in the IIsi dev notes and I've encountered two specific problems!

Now that I've got the engineer out of my system, the hacker in me says: patch the checksum calculation routine in the system ROM (located at 0x36ec in the IIx ROM), and put whatever checksum you want in the header.

 

[dougg3]

Thanks for the info techknight, I see what you're saying but I'm thinking it's easier to just stick the stock IIci checksum in and change the hacked ROM so that it doesn't care about the checksum...

That's exactly what I'm planning to do, bbraun Actually, as long as olePigeon is only planning to use it with the Daystar accelerator, it doesn't even need that -- the Daystar card patches the checksum calculation routine itself. I can probably just borrow the patch that the Daystar card does, though, and then the ROM should work with or without it.

True, there's always the possibility that something will break, but at least as far as direct overlapping, the only thing the Daystar card patches that I also patch is the Happy Mac icon. So I think it will be OK...

 

[Bunsen]

I put my disk image onto a floppy and booted with a stock ROM just to check things out. The problem with the System wanting to root off the SCSI drive instead of the floppy it booted from happens even with the normal floppy driver. So, I'm claiming this isn't my bug.

Random suggestion- try using the actual boot disk image from the ROM of a Mac Classic? Maybe it does something differently when it gets to that step.

 

[bigmessowires]

But for whatever reason, the cursor vbl task isn't being called.
My code shouldn't be doing anything with VBL or interrupts, so I've definitely got a bug somewhere!

The normal floppy driver definitely uses the VBL queue a lot. So maybe your ROM disk driver is breaking the VBL queue somehow, by dropping the mouse VBL task out of the linked list of tasks? Or maybe the normal floppy driver performs some kind of VBL initialization that your ROM driver doesn't do, but should? That seems less likely...