Thread

Another IIci ROM hack

Another IIci ROM hack Troubleshooting 1018 posts Jul 23, 2011 — Jan 30, 2014

#511 Wed, 23 Nov 2011 - 06:43

Progress on the ROMDisk booting thread:

Cool! This is going to be so awesome! So do you think you have to replace the .Sony driver in the System file as well?

I'm really looking forward to the SIMM programmer! Removing the SIMM, and then removing, programming, reinserting each of the 4 chips, and then putting the SIMM back in is tedious business.

LOL, tell me about it! It was even worse before I had the SIMM when I was figuring out the startup chime code...

I agree though, pulling the chips out of their sockets sucks. What's really bad is the sockets I'm using don't work with my PLCC extractor tool, so I kind of have to pull them out a corner at a time. Sometimes it bends the pins a bit

The programmer board should be able to program the chips much faster, too. It seems like it takes forever to program each chip with my burner, but the datasheet for the SST39SF040 says the typical chip rewrite time should be about 8 seconds. Since all 4 chips will be programmed simultaneously, you get the picture

Even if it takes 30 seconds or a minute, it would still be a huge improvement.

The 45° sockets you stick the SIMM in at about 70°, then push it down and clicks in at 45°.

Ah, gotcha. I personally like the 90 degree ones, but I guess it doesn't matter much as long as they fit on the board!

Edit: Are you gonna screen the Jolly Roger on the board? Doesn't need LEDs or anything.

Absolutely! It can be much bigger, and EAGLE should be better at importing the graphic, too. I can do your first version that was solid, I think...

#512 Wed, 23 Nov 2011 - 17:37

Progress on the ROMDisk booting thread:

Click to expand...

Cool! This is going to be so awesome! So do you think you have to replace the .Sony driver in the System file as well?

Nice! If you haven't already, check out the source code for Mini vMac. It patches over the .Sony driver in ROM before it boots the Mac, exactly as it sounds like bbraun is doing it. Any possible driver re-init problems should effect Mini vMac the same way. Since Mini vMac doesn't require any changes to the System file on the disk images that it boots, I assume that replacing the driver inside the System file isn't required.

#513 Wed, 23 Nov 2011 - 18:05

Yeah, I'm thinking it's not due to System issues. There are a couple things I'm investigating in order of likelihood:

1) I have funky code for the accRun control code for posting the disk mount notification. It should probably just be a straight post. The ROM doesn't mount drives when booting, it just takes drives off the drive queue and inspects them for bootability (modulo a bunch of other code that checks the PRAM value for desired boot disk, whether the mouse is down and should eject the floppy, etc). It then stores the drive number it selected to boot from in a low memory global, and boots the blessed System file. I suspect the System needs the drive mounted, and calls the boot drive's driver Control function with csCode=accRun, which is supposed to post a diskEvt notification, which will mount the drive, and everything continues happily booting. I'm not positive the System calls accRun on it's own, the .Sony driver installs VBL task that fires every 60 ticks (1 second), and polls the state of the floppy drive. If a disk is inserted, it calls accRun on its self, which in turn does the PostEvent. So, it's possible my Control function isn't getting called with accRun, the drive is never mounted, and the System is freaking out because it has no root disk.

2) I'm using the device control entry's dCtlStorage element to allocate a handle to the drive queue element. The .Sony driver allocates a pointer for its local data (including its drive queue element) and sticks it at 0x134. I may be losing something here?

3) I don't support several Control and Status codes, including drive & disk icon retrieval. It could be hung up on that, although I'm somewhat skeptical.

Minivmac's disassembly of the ROMs has been invaluable, as have the minivmac and basilisk ii source bases.

Have I mentioned I'm looking forward to the programmer?

#514 Wed, 23 Nov 2011 - 19:49

Me too! It'll be an interesting experience doing all four at once right on the SIMM Card!

You've just gotta love all the progress that's been made on so many different fronts in this, and BMOW's Thread when so many comrades are working in collaboration on so many interrelated projects! Synergy ROCKS!!! [

] ]'>

I'm going to have to do a major re-work of the intro & add links to all the related threads. :approve:

My new ROM SIMM arrived today, BTW!

#515 Wed, 23 Nov 2011 - 20:33

Ok, further progress, but pretty weird. I've gone back to using a straight IIx ROM to simplify the Minimal System install problem. Changing the machine time and rom revision seemed to sufficiently fool the System's check, but the less variables the better.

Good news: I can boot the rom disk all the way to the finder, navigate around, etc.

It turns out it was a problem with the drive getting mounted after the system booted. Setting dNeedTime (0x20) on the driver flags with a delay of 60 ticks, the System will invoke the Control function with csCode=accRun when it's ready, the driver posts a diskEvt event, and boom, booting.

Bad news:

1) After booting, the cursor doesn't move! Mouse down works fine, keyboard works fine, the cursor just doesn't move.

2) If there is another disk in the system (like the SCSI disk), the System will boot off the ROM disk, but attempt to root off the other disk instead of the ROM disk.

#516 Wed, 23 Nov 2011 - 21:12

1) After booting, the cursor doesn't move! Mouse down works fine, keyboard works fine, the cursor just doesn't move.

This is what you'd see if SCC interrupts weren't getting through. Mouse movement generates an SCC interrupt, but the mouse button is a poll rather than an interrupt, and keyboard interrupts come from the VIA. So maybe your init code is leaving the SCC in a weird state, or stomping on the SCC interrupt handlers or something?

#517 Wed, 23 Nov 2011 - 22:41

I've had some time to play with all three ROM SIMMs today, but my results may not mean much, I just discovered that my IIsi

has been booting happily for quite some time with the ROM SIMM jumper REMOVED! [:O] ]'>

IIsi ROM Image does NOT work on modified Rev 0 ROM SIMM . . .

. . . it boots fine on both the stock Rev 0 ROM SIMM and the Jolly Roger Rev 1 ROM SIMM, though!

The IIvx ROM Image does NADA! No Boot Chimes, No Video off MoBo.

The Quadra 650 ROM Image at least gives MoBo Video, but no boot chime.

Methinks I'll need to be removing some ROMs from the IIsi MoBo before further testing.

Comments, gang? :?:

#518 Wed, 23 Nov 2011 - 22:59

Good news: I can boot the rom disk all the way to the finder, navigate around, etc.

Woohoo!

I just discovered that my IIsi has been booting happily for quite some time with the ROM SIMM jumper REMOVED! [:O] ]'>

I have no idea what the ROM SIMM jumper does on the IIsi -- does it behave exactly like the IIci's one, where it's supposed to be in there if there is motherboard ROM, and removed if using the SIMM? I vaguely remember that we talked about this before, but I can't remember...

IIsi ROM Image does NOT work on modified Rev 0 ROM SIMM . . .. . . it boots fine on both the stock Rev0 ROM SIMM and the Jolly Roger Rev 1 ROM SIMM, though!

I'd say this finally confirms it...my IIsi mod was not necessary. The original SIMM works fine in the IIsi without any changes. Thanks, Apple, for having your IIsi dev notes wrong...

The Quadra 650 ROM Image at least gives MoBo Video, but no boot chime.

Interesting! I guess the Quadra 650 ROM is based on the IIci and not the IIsi...

Methinks I'll need to be removing some ROMs from the IIsi MoBo before further testing.

Comments, gang? :?:

I don't think removing ROM from the motherboard will do anything, really. As long as the jumper is disabling them, it's having the same effect that you would see from removing the ROM.

#519 Wed, 23 Nov 2011 - 23:11

If the IIsi is booting just fine from the MoBo ROMs when the jumper is supposedly disabling them, they can ONLY be getting in the way of booting off some other ROM Image on the ROM SIMM!

Or is my logic flawed somehow?

#520 Wed, 23 Nov 2011 - 23:24

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?

#521 Wed, 23 Nov 2011 - 23:43

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

#522 Wed, 23 Nov 2011 - 23:45

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!

#523 Wed, 23 Nov 2011 - 23:56

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.

#524 Wed, 23 Nov 2011 - 23:57

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.

#525 Thu, 24 Nov 2011 - 00:05

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!

#526 Thu, 24 Nov 2011 - 00:09

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

Edit: Hat trick! Page 22.

#527 Thu, 24 Nov 2011 - 00:26

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.

#528 Thu, 24 Nov 2011 - 00:47

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 . . . >

#529 Thu, 24 Nov 2011 - 00:50

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!

#530 Thu, 24 Nov 2011 - 00:57

: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

#531 Thu, 24 Nov 2011 - 01:02

IIsi backwards from the IIci? News to me.

)

#532 Thu, 24 Nov 2011 - 01:22

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 . . .

#533 Thu, 24 Nov 2011 - 02:51

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...

#534 Thu, 24 Nov 2011 - 04:48

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.

#535 Thu, 24 Nov 2011 - 04:52

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.

#536 Thu, 24 Nov 2011 - 05:12

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.

#537 Thu, 24 Nov 2011 - 05:40

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...

#538 Thu, 24 Nov 2011 - 15:36

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.

#539 Thu, 24 Nov 2011 - 16:29

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...

#540 Thu, 24 Nov 2011 - 18:28

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 . . . >

bbraun, I've been looking for the reference you made to the IIsi ROM in your IIx not working as well as the IIsi DevNote might have stated/implied.

1) Are you sure it wasn't the IIcx that was mentioned in the DevNote? (that'd make a whole lot more sense!)

2) What page is it in the DevNote? After I find my .pdf I'd like to look at that part!

The whole memory mapping scheme that's laid out in the Mac ROM Docs has my head spinning. I'm trying to get a IIsi to address more than the ROM's specified THREE PseudoSlot Addresses. But you're using the same stock IIsi ROM successsfuly, for the most part, to address the IIx's SIX NuBus (also PseudoSlot) addresses.

4) What gives?

5) Maybe try out the Quadra 950 ROM Image in your IIx and see if the IIsi ROM's incompatibilities automagicly disappear?

Happy TurkeyDay to my comrades in the US and a wonderful Harvest Festival to the rest of you around the globe!