Another IIci ROM hack

[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?

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]

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

[Trash80toHP_Mini]

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!

[bbraun]

The IIsi dev notes page 74 says:

The Macintosh IIsi computer uses a universal ROM that will run on any of the Macintosh II–family computers. At startup, the ROM code determines which hardware features are available on the Macintosh IIsi computer and configures itself to use those features.

And indeed it does run! But the issues I ran into are: RocketWare apparently thinks the IIx is a IIsi and won't run, and the Minimal System installs for a IIx also don't run with the IIsi ROM. I haven't dug into it, but the Minimal System installs are apparently checking the machine time and (possibly) the revision byte, since changing both of those fool the min system.

[Trash80toHP_Mini]

bbraun, take a set of Quadra 950 ROMs and call me in the morning!



edit: I just waded through the last 20 pages/1,000 topics in the "all results" view of the "View active topics" list!

This introductory "IIci ROM hack" thread, the contributions of info and suggestions by many comrades . . . < gotta make a listing >
. . . and even the start of new, interrelated hack projects, such a bbraun's amazing ROM-Disk hack . . .
. . . have blown this thread right off the charts in just four months.

The only remaining topics with more posts/pages are the four years longer running:
Post your desktop on p.32 ATM . . .
. . . and What are you listening to? on p.31 as I type this!

What an amazingly Synergistic Hackin' Consortium

Thanks ever so much for joining us, dougg3, and for instigating all this fun!

[bbraun]

Q950 ROMs won't help the two problems I've mentioned, since the problems appear based on things checking the machine type & rom revision and making assumptions based on that. The "solution" is to modify those values in the ROM and hope for the best.

However, the newer the ROM, the larger it is generally speaking. The Q700 (all 040's?) and up ROMs are all 1MB. That's the entirety of mapped ROM space under older OS releases, so you don't have any space to play with. So, my general rule is: unless there's a specific reason to use a newer/larger ROM (such as 32bit cleanliness, faster ROM FPU routines, newer Something Manager releases, etc.), stick with the smallest ROM (typically the original shipping ROM for that system) to maximize the available space to play with.

For the moment, I'm using the stock IIx ROM just to minimize variables in my ROM disk hacking.

[Trash80toHP_Mini]

Good points, which brings up the question:
What benefit does the IIsi ROM give you over the Stock IIx ROM other than removing the requirement of running MODE 32?

I'm beginning to wonder if I really need a newer ROM on my IIsi, given the statement in the DevNote and your experience with it in the IIx.
If I just add the extra Cards and the IIsi polls them at startup, I wonder if it will address more than the three PseudoSlot addresses specified?
If I hack the NuBus adapter's Slot ID, That ought to let me run the three spec'd addresses from cards in the subterranean expansion bay.

[dougg3]

Here's the latest design. I found and fixed a few more stupid traces, cleaned up a lot of the traces so they look nicer when they go into IC contacts, added the jolly roger and used an LED for an eye, and that's about it.

I couldn't figure out how to import an EPS file into EAGLE, so I turned the Jolly Roger into a BMP and used its included BMP import script.

[Trash80toHP_Mini]

With those SIP Headers, will it be possible to build a breadboard to program just about any ROM package?

Specifically, I'm thinking about hacked DuoDock & MiniDoc DeclROMs. On the other hand, updating the DeclROMs on Video Cards etc. that are long out of producyion from companies that no longer exist might be kinda nice too!

[dougg3]

The only remaining topics with more posts/pages are the four years longer running:

Holy cow! I didn't see what you had written earlier until now. That's awesome! Thanks jt It's been a blast and it continues to get even better as bbraun makes the SIMM contain a ROM disk. Who knows what other possibilities are in store for this thread...

With those SIP Headers, will it be possible to build a breadboard to program just about any ROM package?

Yep! I do believe so. Except for the VCC/GND pins, each one of those pins is pretty much its own IO pin connected to either the microcontroller or the IO expander. So as long as the ROMs do not need a higher Vpp voltage for programming, and they have fewer than however many pins I have going into it, we could definitely add a connection to it. (And it would take firmware support for that chip, of course...)

I've started writing some of the basic drivers for the programmer board already, even though I don't have a board or CPU on hand. Just getting familiar with the IO expander IC and how read/write cycles work on the Flash chips...

Also found a little bug on the board already. Glad I haven't had any manufactured yet. The pullup resistor on the IO expander chip's /RESET pin should be a pulldown resistor, keeping it in reset until I tell it to go out of reset. It's there because the AVR ISP programming also uses the SPI bus, and I'd like the IO expander chip to butt out while I'm programming the AVR

[trag]

JT, the interrupt for each slot has support in hardware. So even though all the ROMs for both three and six slot models may have code to poll six slots when an interrupt occurs, the interrupt signal line(s) from the slot need to be connected properly.

I don't know how the 68030 models handle the hardware end -- I think it involves the VIA registers -- but in the PowerMac x500 models, the Grand Central chip has a pin for each interrupt and the interrupt wire from each PCI slot must be connected to a unique interrupt pin on Grand Central. Since the PCI slot IDs are coded into the ROM/Open Firmware Device Tree in those models, I suspect that the interrupt used needs to match the PCI slot address.

Anyway, the point is, that expanding the number of slots supported goes beyond providing support in the ROM and hooking up the expansion bus. The interrupt line connection can be pretty complicated.

[ojfd]

dougg3,
It looks to me that some work still needs to be done around IC2 (SOIC package?).
What is your setting for copper pour back-off or something? I would increase it a bit.
It all depends, of course, how good your PCB manufacturer is. If the traces are too close to each other or too close to large copper areas, shorts might develop. (been there)
What colors represent which layer, btw?

[dougg3]

I'll see what I can do with some of the traces on IC2...thanks!

You're right, I had the copper pour isolation set too low. I upped it to 12 mils or so, but now I'm running into problems with my ground planes disconnecting from each other. So I have some issues to solve there...

Red is the top layer. It's VCC except for the section surrounding the crystal, which is ground. Blue is the bottom layer and it has a ground fill.