Another IIci ROM hack

[Dennis Nedry]

Oh bummer, it looks like the IIci has only clearly supports 1 MB of address space for ROM:

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

ROM 24-bit address space: 0x80 0000 ... 0x8F FFFFROM 32-bit address space: 0x4000 0000 ... 0x400F FFFF

Interestingly, the address space directly after that spills into NuBus slot $9 in 24-bit mode, and that NuBus slot does not exist in the IIci. So it's possible that it could still work. We had a little quirk with deciding whether or not to skip a bit in the ROM slot when dougg3 was making his awesome SIMM - it was not clear if the actual address lines included this bit or not. This could be causing the ceiling we're seeing, either that or there is some logic on the board that enables the ROM's /OE pin only if the address bus is specifically valid for the ROM range in the document above.

Another thing to consider is that in 32-bit mode, there seems to be about a gigabyte of address space after the ROM before running into the I/O space at 0x5000 0000. Although we're using a "32-bit clean" ROM for these cool adventures, it may be that the ROM starts in 24-bit mode and automatically switches over - after the creation of this super awesome ROM disk.

Can we verify that the Mac boots in 32-bit mode with the ROM disk? Maybe something is tripping this up, or maybe running System 6 puts it back into 24-bit mode, etc??

dougg3 - Do I recall that you were able to use more than 1MB ROM for one of your startup sounds? If so, this is a very important clue.

 

[dougg3]

Yes, my super long Mario startup chime comes close to filling up the entire 2 MB address space of the SIMM. So the IIci definitely has the whole ROM address space mapped at some point early on in the boot process.

Also, the reset vector (the second 32-bit word in the ROM) of the IIci is $4080002a. So it's definitely using the 32-bit address space, and because that's the reset vector that *Apple* used, I think it's safe to assume the ROM repeats inside of the $40000000 to $50000000 space when it's in 32-bit mode. Edit: It also implies the IIci supports a maximum of 8 MB of ROM space, which would match up with the number of address pins in the SIMM socket -- I left 2 unused, which would bring my current 2 MB up to 8 MB of space.

The weirdness with the address line was that I discovered one of the address lines is tied to the DIP ROMs' OE or CS (can't remember which--the jumper controls the other one). The net effect is that the DIP ROMs are only mapped every other 512 KB in the address space--the other half of the time they don't respond. So for example, $40800000 to $40880000 contains the DIP ROMs, but $40880000 to $40900000 does not. The SIMM does not have this limitation though--otherwise my startup chime wouldn't work, and I've checked the pins with my continuity tester anyway. I have no idea if the SE/30 or IIsi or anything else are also mapped in this funky way, but I doubt it matters when you have the SIMM in place anyway.

When I boot my IIci into System 7.0.1, dumping memory addresses above 40900000 (or maybe it was 40880000, I can't remember) in MicroBug causes MicroBug to crash. I think the same thing happens in other sections of the $40000000 to $50000000 space where it's supposed to repeat other than $40800000 to $40880000. When I'm in 7.6, those addresses don't cause a crash. Both are using 32-bit addressing. So I think there's a difference in how 7.6 and 7.0.1 set up the MMU or something. Is it possible that we just need to figure out how to set up the MMU correctly? My fear is that older OSes set up the MMU without the extra available address space and that might be part of the problem. I didn't think about 24-bit addressing though, good call--the OS could definitely be doing something funny when it first boots up like putting it back into 24-bit addressing temporarily.

 

[Dennis Nedry]

Thanks for clearing up the info about the address pin dougg3. We know for a fact that it works properly again. (I forgot some details where you already proved it!)

So I guess the OS version seems pretty much involved in this ROM Disk issue:

- MicroBug crashes when accessing past the 1MB mark in certain OS versions

- ROM Disks fail past the 1MB mark

For the ROM Disk problem, our theory here is that the ROM's OE / CS is controlled by the MMU and that the MMU is being goofed at some point by the OS. That would certainly screw up the ROM Disk, but this theory does not particularly jive with MicroBug crashing. If the MMU screwed up our extra address space and prevented the ROM chips from talking on the data bus at those addresses, would those addresses not return zeros or garbage or something in MicroBug? It's very odd that it would crash.

What intervention, version-dependent, could the OS possibly have with those addresses when running MicroBug? I am very much confused by this.

If there is an interrupt caused by trying to read from beyond the 1MB mark, then the interrupt handler, or lack thereof, could be crashing. I am not aware of any interrupts that are caused by reading from memory though.

Another possibility is that the act of reading from those addresses, itself, goofs the MMU, which would then bork MicroBug.

 

[dougg3]

Well, I'm a liar.

System 7.0.1 dumps the entire ROM address space fine too -- WHEN I'm in 32-bit addressing mode. I wasn't paying attention the first time and failed to realize I was in 24-bit addressing. I also noticed System 7.6 reboots once (almost immediately after the Happy Mac) before finally completing the boot (because my PRAM battery is not installed). I'm thinking that's because the default value in PRAM is 24-bit addressing. Perhaps the purpose of that first reboot is to force the system into 32-bit mode. 7.6 won't let you go back to 24-bit mode, so that would make sense...

In 24-bit mode, dumping $40800000 works, and so does $40880000. But $40900000 causes MicroBug to exit. Let's see--in 24-bit addressing mode, the upper byte of addresses would be ignored, so I would really be dumping $800000, which as Dennis Nedry pointed out, is the ROM location in the 24-bit map. $40900000 would not be the extra ROM space, but rather NuBus slot $9 mapped at $900000. So THAT mystery is solved, I think.

This might also explain why Apple picked $40800000 rather than $40000000--it's valid in both 24- and 32-bit modes.

Still doesn't help with bbraun's boot disk project, but I'm feeling better with regard to my sanity...the system version probably doesn't matter after all.

 

[tt]

Here is a photo of my test rig for ROM testing. I have to say that the programmer hardware/software is very easy to use. It allows quick flashing and testing of the ROM, dougg3 did a great job!!

The 1MB restriction seems to be real. The 1.5MB image works because all the bootable bits were in the first 512KB (first 1MB of ROM overall).

I guess I'm the troublemaker here... I tried to fit System 7.1.1 onto the 1.5MB disk image, but it wouldn't boot. A few times at boot, the screen would show a floppy with a flashing 'X' and other attempts I would get a "sad mac". My SE/30 can boot off a IIsi ROM (no disks attached as shown above) with the modifications bbraun outlined and System 6 or whatever you can fit within 512KB.

 

[dougg3]

Nice test setup! I love seeing pictures of the programmer/SIMMs out in the line of duty...

 

[bbraun]

Out of curiosity, is the Sad Mac error code 0000000F 0000000A?

 

[dougg3]

Just checked--It's 0000000F 00000001.

 

[Trash80toHP_Mini]

woot! p.30 :approve:

IDRemember, has anyone figured out how to change a Machine ID in ROM or on the MoBo? :?:

ISTR somebody posting that RocketWare checks for presence of the IIsi ID and then refuses to run, giving a notification that it is incompatible with the IIsi. Sounds about right, Radius likely implemented this to avoid emanation of magic smoke with unprecedented regularity from the sadly underpowered PSUs afflicting the Flat/30.

Anybody got any ideas for a firmware hack along the lines of I Wish I Were?

 

[bbraun]

Thanks to tt and dougg3 for testing, I think I've finally gotten the full 1.5MB issues worked out.

 

[dougg3]

And man is it awesome! Nice work bbraun!

I've successfully booted from 7.5.3 and 7.6 Disk Tool disks appended to the end of the ROM. It's nowhere near as fast of a boot as the System 6 one in my video, but I would imagine it's still much faster than a floppy boot would be.

I'm thinking the IIsi ROM is probably the best one to be hacking. It's still only 512 KB so plenty of space for hacking, plus it can boot all Macs compatible with the ROM SIMM except for the Quadra 700. (I think--the IIsi ROM can boot a IIfx, right?) The next step for me is to figure out how to customize the startup chime in the IIsi ROM. It's probably just a matter of being the same code at a different offset.

 

[tt]

Glad to help out- great work!

In case someone else tries it with a diskless setup... I was a little confused when I found it booted from ROM automatically. Bbraun explained if the boot process could not find a disk in the first pass, it would try again, and then would enable the ROM disk even with no 'r' key pressed. I was able to boot System 7.0.1 (with an SE/30)...seemed pretty fast to me.

I'm trying to figure out what the minimum requirements for Bbraun's HTTP boot disk are http://synack.net/~bbraun/68khttpdisk.html. If it can work under 6.0.8, then I think there's enough space to add supporting extensions/control panels, otherwise I think there may not be enough room in 1.5MB of space. Even if currently read only mode works reliably, it would still be pretty awesome! 8-o

 

[dougg3]

So I'm thinking that the hardware part of this hack still isn't complete. There is room in the SIMM pinout for up to 8 MB of ROM space. The programmer board has the extra pins wired up too--it's only the SIMM that has to be changed. (And possibly a firmware update for the programmer if the chip uses a different programming standard). This is all assuming that I can find larger parallel flash chips that don't need any special programming voltages and just operate with data lines, address lines, and /CS, /OE, and /WE control lines.

It makes me sad because I have close to 100 bare 2 MB SIMM PCBs here, but I know the bigger 8 MB size makes a huge difference in capabilities for stuff like ROM disk booting.

Should we start thinking about an 8 MB SIMM? The main problem I'm having with early research is it's hard to find 5V chips in bigger sizes. Everything's moving toward 3.3V now.

 

[tt]

Can all compatible machines map 8MB of space? If finding chips for 8MB is difficult, what about 4MB? The question of more room I suppose will always come up as being desired... 1.5MB of free space seems a little on the tight side to enable networking and System 7. It probably could be done though, but the disk image would be fairly bare bones.

 

[Trash80toHP_Mini]

What are the tradeoffs regarding SIMM form factors, EEPROM parts and physical limitations in terms of using more ICs on a larger SS eight IC SIMM or going to a DS Eight IC layout for increasing capacity?

 

[dougg3]

Can all compatible machines map 8MB of space?

There is room for 8 MB of ROM space in all supported models. The ROM is mapped from $40000000 to $50000000 in the SE/30, II, IIx, IIcx, IIci, and IIfx. The IIsi developer note says it's mapped from $40000000 to $42000000 with $42000000 to $50000000 being "reserved ROM space". The Mac generally considers $40800000 to be the ROM base address, which would suggest a maximum usable size of 8 MB--also corresponds to the number of SIMM address lines available.

Anyway, bottom line is we should be able to use the 8 MB of space from $40800000 to $41000000 on all of those models.

If finding chips for 8MB is difficult, what about 4MB?

That may also be doable -- I'll have to check. If at all possible, I'd like to maximize the amount of available space, and 8 MB seems to be the true upper limit of the SIMM socket.

What are the tradeoffs regarding SIMM form factors, EEPROM parts and physical limitations in terms of using more ICs on a larger SS eight IC SIMM or going to a DS Eight IC layout for increasing capacity?

I thought about this and it's also a definite possibility -- it would require some programmer firmware changes (and possibly some simple logic gates on the SIMM too) because I would end up having to use address lines as chip selects. For example, if I found some 8 megabit (1 megabyte) chips, I could connect A0 through A19 to all eight chips, but then I would have to use A20 as a chip select -- if A20 was low, half of the chips would be activated, and if it was high, the other half of the chips would be activated. I could probably get this working properly with some gates--haven't thought the logic through in my head, but I would probably combine A20 with the SIMM chip select line, NOTing and ANDing and ORing as appropriate to generate a high and low chip select to actually hook up to the chips' CS pins (half high, half low). I know pin 63 is labeled as being some kind of an alternate chip select, but I have no clue if it actually does anything in any of the Macs. If it already works, that would be fantastic (and would sadly require a programmer board hardware change).

The M29F160FT5AN6F2 is a possible chip -- it's a 16 megabit chip, so I would need four of them, and it can be addressed on an 8-bit bus. So basically it would behave like a larger version of the chips I'm using now. I *believe* from a quick look at this chip that it would be completely compatible with the current programmer with no software changes at all if I wired it up correctly. Digi-Key lets you order it, although it's not in stock, so I have no idea what the lead time would be or how long the chip will be around in the future. It's also pretty expensive--$4 per chip and it would need to be soldered directly to the SIMM.

 

[dougg3]

Micron is sounding more and more like the manufacturer to go with. They still make 5V chips for the automotive industry. Plus, I went on a tour to Micron's headquarters in Boise, Idaho when I was in high school and it was cool, so that has to mean something, right?

Octopart.com is a very interesting site that lets you search for components to find places that have them in stock. Using it combined with Micron's list of active parts, I found that Avnet has a bunch of M29F160FB5AN6E2 chips in stock still and they only cost $2.66 in quantities of 1.

These are 16 megabit chips, so four of them would add up to the required 8 MB of space. I'm fairly sure this part would require no software changes if I wired it up correctly. I'm very tempted to start exploring this possibility now...

 

[Trash80toHP_Mini]

That sounds v-e-r-y interesting . . . but not schtupid!

< /Laugh In >

 

[Dennis Nedry]

You could make a ROM card for the IIci's cache slot with a multitude of ROM SIMM slots, each multiplexed out to a separate address space. Then populate it with a handful of your ROM SIMMs. I bet you could fit 8 of your 2MB SIMMs on there for 16MB ROM -- which is possible because the cache slot has access to way more address lines.

A less aggressive approach could be to make a ROM SIMM adapter board that plugs into the ROM SIMM slot and provides 4 multiplexed slots, not unlike a RAM SIMM Saver. It seems that this might not fit physically into many Macs, but you never know.

It may be possible, albeit HAZARDOUS, to run a ribbon cable from the SIMM slot to this adapter board to relocate it. But it's certainly something to consider as a prototype especially if it can gobble up a few of these ROM SIMM boards.

 

[dougg3]

That's an interesting idea to just reuse multiple old SIMMs! The physical space issue could be a problem though as you pointed out. For maximum compatibility with everything I'm definitely going to create an 8 MB SIMM and stay with that.

Hmmm, that cache slot does have interesting possibilities for IIci-specific hacking though. You could make a HUGE ROM...there's $10000000 of available space which comes out to 256 MB. That would be a ton of NOR flash...I think the 8 MB SIMM is probably more practical

I'd love to figure out a way to use serial storage devices like SPI flashes or SD cards instead, but I think they're too slow to parallelize the data fast enough for the Mac. I would be delighted to be proven wrong on that point though!