Thread
Another IIci ROM hack
I've been in White Elephant Thread and Scan Dump mode for a while, which entails rummaging through the magic boxen for goodies and content. This, of course, entails a LOT of cleaning up and organizing all kinds of strange MacCrap & MiscCrap, not to mention a brief sojourn through the SPARCstack project after finding, researching and going back to test my 21" 13w3 cabled SUN CRT. Therefore, I'm not exactly up to speed on where things stand here.
How about making up a precise listing of the set of tests to be done in your reply?
I'll bet another IIsi slinger will rush to make a content contribution to your amazing project before I can get to it . . .
. . . the more Sancho Panza's you can recruit . . . the more windmills we can demolish in search of your impossible dream!
WhereTF IS Dulcinea?
YO! Maniac! Chime in here if you're still around! We miss you!
edit: p. 19!!!!!!!!!!!!!!!!! I wonder if any other non-Post Your . . . thread has achieved this level of interest? Nice intro post, buddy!
Haha I know! I keep looking at this thing with all the views and pages it has...wow!
OK -- here's a detailed set of steps to perform:
I am looking at a picture of a IIsi motherboard. It has two 44-pin ROMs, presumably each 128K x 16 bits in size. JEDEC has a specification for 44-pin, 128K x 16 EPROMs, but the pins are numbered differently from how they are numbered on the motherboard. The motherboard has pin 1 at a corner, and the specification has pin 1 in the middle of one of the sides. So for now I'm not going to bother asking for any continuity tests on the motherboard. The software test I detailed above should work fine...
OK -- here's a detailed set of steps to perform:
- Boot up a IIsi (preferably, one with soldered ROMs--I'm pretty sure the ROM SIMM will behave normally). Get into the MicroBug debugger (I don't know if the IIsi has a programmer's switch, but if it doesn't, just press command+powerkey to get into it
- Type:
(and press return) -- this should print the beginning of the ROM contents. Take note of the first few bytes so you can compare against the other dumps I'm about to instruct you to do.Code:
DM 40800000
- Now, type
Does it show another copy of what you saw earlier, or what? It shows another copy on my IIci when it runs System 7.6, but it crashes back to the desktop on System 7.0.1.Code:
DM 40900000
- Now, type
This is the important one -- does it show another copy of the ROM, or a bunch of FFs? If it shows a bunch of FFs, then the IIsi soldered ROMs are wired the same way as the IIci.Code:
DM 40880000
- To get out of the debugger, type
Code:
G
I am looking at a picture of a IIsi motherboard. It has two 44-pin ROMs, presumably each 128K x 16 bits in size. JEDEC has a specification for 44-pin, 128K x 16 EPROMs, but the pins are numbered differently from how they are numbered on the motherboard. The motherboard has pin 1 at a corner, and the specification has pin 1 in the middle of one of the sides. So for now I'm not going to bother asking for any continuity tests on the motherboard. The software test I detailed above should work fine...
Is the ScreenShot option available while in MicroBug Debugger Mode? That'd be handy! :?:
BTW, you've been awarded an official 68kMLA 'nick: DQ . . . Doug Quixote! :approve:
BTW, you've been awarded an official 68kMLA 'nick: DQ . . . Doug Quixote! :approve:
I don't think it will let you take a screenshot...but if you just look at the first 4 bytes or so (which will be the ROM checksum) you will easily be able to tell. I guess the most important part of the test is just to do the 40880000 one and see if it's filled with a bunch of FFs or not.
To answer some questions:
1. My IIci will not boot with the jumper pulled and no ROM installed, even if accelerator is installed.
2. It will boot regardless of the jumper so long as a ROM is installed.
3. Chime of death when both accelerator and ROM installed; jumper doesn't make a difference.
4. ROM checksum appears to be identical with or without the accelerator installed (see attachment.)
I don't have an extra ROM or burner to just put the normal ROM on to see if it's a hardware conflict. So I can't test that.
1. My IIci will not boot with the jumper pulled and no ROM installed, even if accelerator is installed.
2. It will boot regardless of the jumper so long as a ROM is installed.
3. Chime of death when both accelerator and ROM installed; jumper doesn't make a difference.
4. ROM checksum appears to be identical with or without the accelerator installed (see attachment.)
I don't have an extra ROM or burner to just put the normal ROM on to see if it's a hardware conflict. So I can't test that.
Thanks for all the info olePigeon!
That basically tells me that the SIMM overpowers the onboard ROMs when both are activated (e.g. when you leave the jumper in). Although it doesn't seem to matter, it's probably better to leave the jumper off when the SIMM is installed
The checksum is identical, but the contents have indeed changed. It appears that the Daystar card does some patching--in fact, when the checksum is calculated on the Daystar ROM, it comes out incorrect (it doesn't match the stored one). So this probably means the Daystar card disables the ROM checksum check...
My initial guess is that the Daystar ROM adds some kind of patch that is conflicting with the patches that are present in the ROM SIMM. We're getting into really strange territory now...I'll see if I can find anything that would be an obvious incompatibility.
That basically tells me that the SIMM overpowers the onboard ROMs when both are activated (e.g. when you leave the jumper in). Although it doesn't seem to matter, it's probably better to leave the jumper off when the SIMM is installed
The checksum is identical, but the contents have indeed changed. It appears that the Daystar card does some patching--in fact, when the checksum is calculated on the Daystar ROM, it comes out incorrect (it doesn't match the stored one). So this probably means the Daystar card disables the ROM checksum check...
My initial guess is that the Daystar ROM adds some kind of patch that is conflicting with the patches that are present in the ROM SIMM. We're getting into really strange territory now...I'll see if I can find anything that would be an obvious incompatibility.
How about using http://minivmac.sourceforge.net/extras/copyroms.html to copy the complete contents of the ROM while the accelerator is installed, but the ROM SIMM isn't? Then run it a second time with both the accelerator and the ROM SIMM uninstalled to get the original "Apple Factory" ROM image, and compare the two resulting files using a binary diff program? That would show you which portions of the original ROM the accelerator is patching, and you can look for any overlap with the areas patched by the custom ROM SIMM.
That's exactly what olePigeon did last night I just took a look at the dumps:
The Daystar image changes the Happy Mac icon and the Happy Mac icon mask, so does the ROM SIMM. I really doubt this will cause any problems, but depending on how the upgrade card implements the patched sections of ROM (does it store a complete copy of the new icon, or just a diff against the stock IIci Happy Mac icon?) it might make the Happy Mac look totally crazy. Either way, it's probably not going to be possible to change the Happy Mac while the Daystar upgrade is installed. I suppose it could be done by tracing through and patching the code so it jumps around the normal "Happy Mac display" routine, but I'd rather not get into that at the moment...
The other thing is that the Daystar upgrade keeps the stock checksum in place, even though it's wrong after Daystar's patches are in place. Maybe the Daystar patch, instead of actually calculating the ROM checksum, looks to ensure the stock IIci checksum (368cadfe) is in the first four bytes, and if it doesn't, it plays the Sad Mac? It's a possibility. I may have to disassemble the changes that the Daystar ROM makes to see if that's what is going on. This is what I'm guessing is happening.
Other than that, none of the Daystar ROM patches overlap with the SIMM patches.
I'm also curious, as you said olePigeon, as to whether a ROM SIMM with a stock IIci dump will still work with the upgrade card. My initial guess is "yes", but I'm still kind of curious as to what the upgrade card does to override the built-in ROM in certain places.
Edit: It looks like the cache connector has access to the ROM output enable signal. It's probably overriding it at that point and putting something else onto the data bus whenever a matching address appears on the address bus.
Edit2: This whole "repeats every other 512KB" discussion from earlier was useful. The patched Daystar ROM sometimes jumps into the $40880000 space, which is not a repetition of the stock ROM. Looks like Daystar provides its own ROM that maps into that area as well...
Edit3: The Daystar ROM only disables the checksum test. It still calculates the checksum but forces the checksum routine to always return "OK". So I still don't know if there's somewhere else that's testing to make sure the original ROM signature is in place, but I'm still suspecting there's a test like that somewhere...
I just took a look at the dumps:The Daystar image changes the Happy Mac icon and the Happy Mac icon mask, so does the ROM SIMM. I really doubt this will cause any problems, but depending on how the upgrade card implements the patched sections of ROM (does it store a complete copy of the new icon, or just a diff against the stock IIci Happy Mac icon?) it might make the Happy Mac look totally crazy. Either way, it's probably not going to be possible to change the Happy Mac while the Daystar upgrade is installed. I suppose it could be done by tracing through and patching the code so it jumps around the normal "Happy Mac display" routine, but I'd rather not get into that at the moment...
The other thing is that the Daystar upgrade keeps the stock checksum in place, even though it's wrong after Daystar's patches are in place. Maybe the Daystar patch, instead of actually calculating the ROM checksum, looks to ensure the stock IIci checksum (368cadfe) is in the first four bytes, and if it doesn't, it plays the Sad Mac? It's a possibility. I may have to disassemble the changes that the Daystar ROM makes to see if that's what is going on. This is what I'm guessing is happening.
Other than that, none of the Daystar ROM patches overlap with the SIMM patches.
I'm also curious, as you said olePigeon, as to whether a ROM SIMM with a stock IIci dump will still work with the upgrade card. My initial guess is "yes", but I'm still kind of curious as to what the upgrade card does to override the built-in ROM in certain places.
Edit: It looks like the cache connector has access to the ROM output enable signal. It's probably overriding it at that point and putting something else onto the data bus whenever a matching address appears on the address bus.
Edit2: This whole "repeats every other 512KB" discussion from earlier was useful. The patched Daystar ROM sometimes jumps into the $40880000 space, which is not a repetition of the stock ROM. Looks like Daystar provides its own ROM that maps into that area as well...
Edit3: The Daystar ROM only disables the checksum test. It still calculates the checksum but forces the checksum routine to always return "OK". So I still don't know if there's somewhere else that's testing to make sure the original ROM signature is in place, but I'm still suspecting there's a test like that somewhere...
That's exactly what I did.
This discovery is worthy of another post. I think I know what's going on now, and it's all related to the research I've been doing about how the soldered IIci ROM only repeats every other 512 KB block. I have no idea how I happened to be looking at this other stuff at the same time...
I said a few posts earlier that the soldered ROM only repeats every OTHER 512 KB block, because of the chip select line being hooked to A19. So the soldered ROM responds from $40800000 to $4087FFFF, $40900000 to $4097FFFF, etc.
I just said in my last post that the Daystar upgrade puts in its own ROM mapped starting at $40880000 (it has to, because a bunch of the Daystar ROM patches jump to locations in that area). This is one of the locations where the soldered ROM does NOT respond.
The ROM SIMM *does* respond to that location with data, although in olePigeon's SIMM it is data that is left unprogrammed (0xFF). The Daystar card might be forcing the ROM output enable to be disabled at that location (in which case this conflict is not causing a problem and something else is the culprit), but odds are they didn't bother since the soldered ROM doesn't respond to that address anyway. If they are both responding with different data, all kinds of crazy crap could be happening that could cause the chimes of death.
We need to try one of two things:
1) Modify the ROM SIMM hardware so it behaves like the soldered ROMs (cut traces, connect the chip select line of the chips to A19, and replace the chips with smaller chips that don't respond at higher addresses) -- I'd rather not have to do this.
or...
2) Dump the Daystar ROM and put it into the SIMM directly after the IIci ROM. In this case the Daystar ROM and the SIMM would BOTH respond to $40880000, but since they would both contain the exact same data, it shouldn't cause any problems.
The problem is I don't think there is a Daystar ROM dumper utility. It should be relatively simple to make, though...open a file, read the bytes, write the bytes to the file, close the file, done. If any of the existing ROM dumper utilities are open-source, it would be a piece of cake to modify them. In fact, it might be a piece of cake to just take one of them and modify its binary...
I think this is the approach we should be taking to solve this problem...
I said a few posts earlier that the soldered ROM only repeats every OTHER 512 KB block, because of the chip select line being hooked to A19. So the soldered ROM responds from $40800000 to $4087FFFF, $40900000 to $4097FFFF, etc.
I just said in my last post that the Daystar upgrade puts in its own ROM mapped starting at $40880000 (it has to, because a bunch of the Daystar ROM patches jump to locations in that area). This is one of the locations where the soldered ROM does NOT respond.
The ROM SIMM *does* respond to that location with data, although in olePigeon's SIMM it is data that is left unprogrammed (0xFF). The Daystar card might be forcing the ROM output enable to be disabled at that location (in which case this conflict is not causing a problem and something else is the culprit), but odds are they didn't bother since the soldered ROM doesn't respond to that address anyway. If they are both responding with different data, all kinds of crazy crap could be happening that could cause the chimes of death.
We need to try one of two things:
1) Modify the ROM SIMM hardware so it behaves like the soldered ROMs (cut traces, connect the chip select line of the chips to A19, and replace the chips with smaller chips that don't respond at higher addresses) -- I'd rather not have to do this.
or...
2) Dump the Daystar ROM and put it into the SIMM directly after the IIci ROM. In this case the Daystar ROM and the SIMM would BOTH respond to $40880000, but since they would both contain the exact same data, it shouldn't cause any problems.
The problem is I don't think there is a Daystar ROM dumper utility. It should be relatively simple to make, though...open a file, read the bytes, write the bytes to the file, close the file, done. If any of the existing ROM dumper utilities are open-source, it would be a piece of cake to modify them. In fact, it might be a piece of cake to just take one of them and modify its binary...
I think this is the approach we should be taking to solve this problem...
I'd be willing to let you borrow my Daystar Card if you think you can dump the ROM. $5 shipping is worth it to me to get both working.
Edit: I just did a quick Google, and it looks like Daystar released ROM updates for the accelerator. I'm gonna do some more searches and see if I can't find it. You may not have to dump the ROM after all if they have one for download.
Edit 2: According to Apple's compatibility notes, the ROM is the only one that's socketed. I checked my card, and indeed, there's a socketed chip. In fact, it looks to be the same kind of chip you used on your SIMM.
Edit: I just did a quick Google, and it looks like Daystar released ROM updates for the accelerator. I'm gonna do some more searches and see if I can't find it. You may not have to dump the ROM after all if they have one for download.
Edit 2: According to Apple's compatibility notes, the ROM is the only one that's socketed. I checked my card, and indeed, there's a socketed chip. In fact, it looks to be the same kind of chip you used on your SIMM.
Aha -- it's sad because my SIMM could probably act as a reader for the Daystar ROM, but since you have to boot from it, I guess not
Actually I'm still not sure if it makes any sense because a chip that is the style of that would only be 8-bit, not 32-bit. Dunno how the data would get out to the CPU correctly. Maybe it has some logic that reads out four bytes at a time.
I think rather than shipping it to me to get a dump, I can modify CopyRoms to dump it and give you a new binary to run. It's open-source :-D
Can you verify for me that the Daystar upgrade is where I think it is? Booted in the IIci WITH the Daystar upgrade (and obviously WITHOUT the SIMM), go into MicroBug:
Is it something other than a bunch of FFs, and also different from the beginning of the regular ROM dump at 40800000? That would verify my suspicion that the Daystar ROM is there.
Actually I'm still not sure if it makes any sense because a chip that is the style of that would only be 8-bit, not 32-bit. Dunno how the data would get out to the CPU correctly. Maybe it has some logic that reads out four bytes at a time.
I think rather than shipping it to me to get a dump, I can modify CopyRoms to dump it and give you a new binary to run. It's open-source :-D
Can you verify for me that the Daystar upgrade is where I think it is? Booted in the IIci WITH the Daystar upgrade (and obviously WITHOUT the SIMM), go into MicroBug:
Code:
DM 40880000
Curiouser and curiouser! :O
Is the DayStar implementing the use of ROM in Expansion Mode as mentioned in GttMFH2E?
Is the DayStar implementing the use of ROM in Expansion Mode as mentioned in GttMFH2E?
I'll give it a try. Give me a minute, takes a while for my IIci to boot with 128MBs of RAM. 
)
)
800000 368C ADFE 4080 002A 067C 4EFA 0092 4EFA
880000 0006 0000 5200 0008 91C8 46FC 2700 4E70
880000 0006 0000 5200 0008 91C8 46FC 2700 4E70
If you wouldn't mind, a modified CopyROM would be great. I wonder how many people have a Daystar without the 4.1.1 ROM upgrade. In fact, I don't even know if my ROM is up-to-date.
Edit: Nope. v4.0.1. Anyone else have a Daystar Turbo 040? I'd love to upgrade mine to the latest ROM.
Edit: Nope. v4.0.1. Anyone else have a Daystar Turbo 040? I'd love to upgrade mine to the latest ROM.
Excellent! That is definitely where the Daystar ROM is located. I think I have a Daystar ROM dumper ready to go, so let me package it up for you...since it's a GPL open source app, I'm not breaking any rules by posting it as long as I keep the source with it!
This is a zip of a MacBinary file containing a Disk Copy image. Mount it, and you will probably have to copy the DaystarDump application to your hard drive first. Run it, and it should create a file called DaystarUpgrade.ROM. This will give you the dump of the Daystar upgrade ROM.
It only works on a IIci right now -- it specifically looks for the IIci's ROM checksum.
DaystarDump.img.zip
This is a zip of a MacBinary file containing a Disk Copy image. Mount it, and you will probably have to copy the DaystarDump application to your hard drive first. Run it, and it should create a file called DaystarUpgrade.ROM. This will give you the dump of the Daystar upgrade ROM.
It only works on a IIci right now -- it specifically looks for the IIci's ROM checksum.
DaystarDump.img.zip
I'm starting to think along those lines. In GttMFH2E, it keeps saying "for upgrading or expanding ROM" when describing each model. At least on the IIci, I'm thinking:
To upgrade ROM, you remove the jumper and make your SIMM respond to all addresses.
To expand ROM, you leave the jumper in place and make your SIMM only respond to the "unused" 512 KB chunks of ROM (in other words, only respond when A19=1)
Now, the Daystar upgrade also does some patching of the regular ROM, so to say it's only using expansion mode is not 100% correct, but it's definitely also adding its own stuff as expansion past the end of the stock IIci ROM.
It freezes my IIci. I'll try booting with extensions off.
Shucks. Just freezes after I launch it, even with extensions off.
I didn't actually test it, so maybe I messed something up. I did ask it to read longer than the actual Daystar ROM is, but I'm pretty sure that should just respond with 0xFFs in the empty spaces. Hmm...let me keep looking at the code.
I'm running System 7.1.1 if that makes any difference.
Hmm, I don't think the system version should matter, but who knows.
Try this app (actually it's 2 apps). First try the 512k one, and if that doesn't work, try the 128k one. It will be EXTREMELY slow because it's copying everything one byte at a time (inefficient). It may look like it's frozen but should occasionally print a "." to the screen to update you on its progress. It will make a file called rom.out. When you close the app it will ask if you want to save -- that's just asking to save the console output and you don't have to save it.
It's worth a try...
Dumper.zip
Try this app (actually it's 2 apps). First try the 512k one, and if that doesn't work, try the 128k one. It will be EXTREMELY slow because it's copying everything one byte at a time (inefficient). It may look like it's frozen but should occasionally print a "." to the screen to update you on its progress. It will make a file called rom.out. When you close the app it will ask if you want to save -- that's just asking to save the console output and you don't have to save it.
It's worth a try...
Dumper.zip
It wasn't slow at all. Took about 2 seconds. I hope it worked.
The 512k produced a ROM.out file, but crashed with an Error Type 1.
The 128k version seemed to work OK.
128rom.zip
512romErr.zip
The 512k produced a ROM.out file, but crashed with an Error Type 1.
The 128k version seemed to work OK.
128rom.zip
512romErr.zip
Thanks! I didn't realize it would be fast, but cool!
I'm guessing that the Type 1 error was me reading past the actual length of the Daystar ROM. After you told me the ROM chip part number in the private message I was able to limit it to only download the size of the onboard ROM. Looks like the 512 KB dump failed right around the time it reached the first 128 KB, so that's the explanation. That's probably why the first program failed too. I should have just kept it at 128 KB.
The beginning of the file matches what you posted when you did the command for me, so I think we got a good dump! I'll see if it appears to be valid code and if anything matches up (like if an address that the patched IIci ROM jumps to appears to be the beginning of a routine in this dump)
I'm guessing that the Type 1 error was me reading past the actual length of the Daystar ROM. After you told me the ROM chip part number in the private message I was able to limit it to only download the size of the onboard ROM. Looks like the 512 KB dump failed right around the time it reached the first 128 KB, so that's the explanation. That's probably why the first program failed too. I should have just kept it at 128 KB.
The beginning of the file matches what you posted when you did the command for me, so I think we got a good dump! I'll see if it appears to be valid code and if anything matches up (like if an address that the patched IIci ROM jumps to appears to be the beginning of a routine in this dump)
Awesome. Looking forward to what you find.
Edit: Woo! Page 20.
Edit: Woo! Page 20.
It's definitely a good dump. Here are some strings from it:
I wonder how it knows which parts of the stock ROM to patch? Maybe the locations are identical in all of those systems?
Anyway, I think if you append this dump to the end of your SIMM's ROM image, it'll boot correctly. I'm pretty sure even if you burn a stock IIci ROM into the SIMM, it will still fail to boot without this dump in it too.
Code:
4.01
Turbo 040
Turbo 040 ASIC
Macintosh II, IIx, IIcx, IIci, IIsi, IIvi,
IIvx, SE/30, and Performa 600.
(ASIC support included)
Macintosh LC and LC II
Performa 400, 405, 410 and 430
(ASIC support included)Anyway, I think if you append this dump to the end of your SIMM's ROM image, it'll boot correctly. I'm pretty sure even if you burn a stock IIci ROM into the SIMM, it will still fail to boot without this dump in it too.
Guys,
I don't want to disrupt your workflow, but are you aware that there was another ROM dump utility called ROMmie? Maybe that one would speed up the developement?
I don't want to disrupt your workflow, but are you aware that there was another ROM dump utility called ROMmie? Maybe that one would speed up the developement?
By default there is only 25 posts per page.. if you guys keep going on about page numbers eventually you will have enough that they artificially inflate the count. 
Thanks ojfd -- that looks interesting, especially the part where it extracts ROM resources. It could come in very handy for locating things.
Unfortunately, it only automatically extracts the normal system ROM. I had to throw together a custom utility to tell it to extract an additional ROM that I don't believe would be detected by ROMmie.
Unfortunately, it only automatically extracts the normal system ROM. I had to throw together a custom utility to tell it to extract an additional ROM that I don't believe would be detected by ROMmie.