Another IIci ROM hack

[Trash80toHP_Mini]

Great, welcome back! It was beginning to get boring around here without you and your mega-thread even showing up in the "Active" category for so long.

edit: speaking of mega-threads PAGE 29!

[olePigeon]

Gah! That anticipation is killing me!

[dougg3]

More progress, and I'm pretty much ready to take orders! I built two SIMM programmer boards today and they both work fine...woohoo!

I've got the control program working on OS X 10.7, 10.6, Windows 7, and Ubuntu Linux 12.04. Ideally I'd also like to make it work on OS X 10.5 and 10.4. I'll see how well Qt can handle it, but no guarantees. The software should work fine on older versions of Windows and Ubuntu. The bootloader firmware seems to be rock solid, so I am pretty comfortable sending boards out to people now (although it helps if you have an AVR ISP programmer just in case we need to change something in the bootloader later on). The board is unbrickable. If you flash bad firmware on it, it's OK because it always starts up in bootloader mode and then jumps to the actual SIMM programmer firmware after the control program tells it to. This is kind of strange because it will actually disconnect the USB connection, jump to the programmer board firmware, and then reconnect the USB the first time you talk to it after plugging it in, but that process seems to work just fine in every OS I've tried.

I anticipate we will run into minor glitches as the software gets tested on various people's setups, so if you're interested in one, be prepared to take some time to work with me to make it work.

I'm not mounting any of the RS-232 hardware right now -- just sticking with USB. This lowers the cost of the parts for one, and you need a USB port to power it anyway, so you might as well use USB to communicate with it. USB is faster than 115200 bps serial, which is probably what your serial port supports at max. Plus, I don't have any software written for the RS-232 port anyway

The cost of the programmer board is going to be $40. It's not so much the cost of the parts (about $15 per board and over half of that is just the microcontroller + PCB), but the labor it takes to assemble this beast. There are various small parts and some of them are crammed pretty close together, so it takes some serious time to assemble it all compared to the SIMM, which is easy because it's basically doing the same thing 4 times with very few parts.

I'll have binaries of the programmer software ready for download really soon, so you can at least open it and make sure it runs on your computer. The board will work out of the box without any drivers in OS X and Linux. Linux will need a small udev rule installed to set the serial port permissions though. Windows needs a very simple INF to tell it to load its built-in USB CDC modem driver.

Anyway, for everyone who's interested in a programmer board ($40 plus $5 shipping to USA), SIMM ($20 plus $5 shipping to USA), or both (combine the shipping together so you pay $5 total for shipping), let me know via PM so I can get an idea of how many programmer boards I need to build for the first batch. (I have several SIMMs already built up and ready to ship whenever, if anybody cares.) The programmer boards are easier to build in batches because of how many different parts there are to get out from my stash...

Remember, the programmer board will be compatible with any SIMM I built that has the red LEDs with olePigeon's graphic. The first board revision which did not have those is not compatible with the programmer board.

Last but not least, THANK YOU olePigeon for finding a source for the 64-pin SIMM sockets. All of the sockets I've tried so far have worked fine. Without you, this project would have been much more difficult to realize!

[olePigeon]

Yay! I participated!

[dougg3]

In case anybody's bored and wants to try the software, I have uploaded Windows binaries for the control program. You won't be able to do anything with it yet except look at the about box, but the software is functional underneath once an actual programmer board is plugged in. It also includes a firmware binary and a driver INF file. If you're interested in using the programmer board with a Windows machine, you should download this program and make sure it runs OK on your computer...

http://code.google.com/p/mac-rom-simm-p ... loads/list

Tested on Windows XP 32-bit and Windows 7 32- and 64-bit.

Linux and Mac OS X binaries coming soon...

For those of you who PM'ed me, I built programmer boards yesterday and today, so I'll be getting ahold of you very soon!

[olePigeon]

Would it be possible to load device drivers into the ROM so you can boot from them? Devices like Jaz drives, MO drives, etc. I can boot from them if I use my Jackhammer card, but not from the internet SCSI bus. Doesn't like them.

[Dennis Nedry]

Would it be possible to load device drivers into the ROM so you can boot from them? Devices like Jaz drives, MO drives, etc. I can boot from them if I use my Jackhammer card, but not from the internet SCSI bus. Doesn't like them.

Have you tried booting from one of these drives manually by holding Apple+option+shift+delete at startup? The drives you mentioned may take too long at power-on and the Mac gives up looking for them, finding instead your internal hard drive. That key combo prevents booting from SCSI ID 0 for as long as you hold it down.

[olePigeon]

Yeah, I just get blinking floppy (or in my case, skull and crossbones.)

[Dennis Nedry]

Okay, good info. Just a couple of ideas that popped to mind from that:

Try the IIfx ROM
Format the Jaz drive with different programs, i.e. HD SC setup, FWB hard disk toolkit, possibly a special program just for that type of drive

I'm thinking that the hard disk drivers are not boot-compatible with these drives on your built-in SCSI bus for some reason. The ROM is set up to use a driver form the device itself except for floppies. For example, burned CDs with blessed system folders won't boot unless the CD is also burned with a disk driver. (Pre-OS X versions of Toast can do this.)

I think that the key to this problem is in that driver, maybe trying a few different formatters might make something work. I suppose there's a SLIGHT chance of a termination problem, I don't know - I've seen stranger things from terminators. It's bizarre that it works on your SCSI card and not built-in SCSI, I'm stuck on that detail.

I wonder if it could be a SCSI-1 vs SCSI-2 sort of thing?

[dougg3]

Just a quick update to this project -- I have all source code, schematics, and PCB layouts for this whole project available for download now. You can find it all at the Google Code project:

http://code.google.com/p/mac-rom-simm-programmer/

In case anyone doesn't know, I'm now selling the programmable ROM SIMMs and the SIMM programmer. Again, just to be clear, I can't flash custom ROM images for you, but now you can do everything yourself with the SIMM programmer, or if you have an EEPROM burner you can use that.

The SIMM programmer requires a USB connection and is compatible with: Windows XP and later, Mac OS X 10.5 (Intel) and later, and Linux (you'll have to compile it yourself for Linux though). The SIMM should work in any of the following Mac models: SE/30, IIx, IIcx, IIci, IIfx, IIsi, and Quadra 700.

SIMMs cost $24 (including 4 chips) and the programmer costs $40. I have a ton of raw SIMM PCBs available, so if you want to try the challenge of building it yourself, I'll sell the unpopulated SIMM PCB for $5 (soldering the PLCC sockets is NOT fun though, just a warning). Shipping is $5 within the USA for your total order. Shipping outside the USA costs more--ask me and I'll check. I'll make a post in the Trading Post about this too.

[bbraun]

These are awesome by the way. The programmer makes things much easier than popping and programming the 4 chips individually.

I've been using it extensively on 10.6 to refine the romdisk concept. Using the IIsi ROM in a IIx, it can boot from a 1.5MB image when holding down the 'r' key. Details here: http://synack.net/~bbraun/macromboot.html

[trag]

Very nice work -- both to Dougg3 and to Bbraun.

Doug, it's been said, but it bears repeating. That's a nicely developed product.

Rob, I just read your linked page. I saw your initial posts here, but didn't realize you had done all that development. Wow. Also, in case I forgot to say it before, thank you, thank you, thank you for your coding help with the PEx ROM project. I have a weekend coming up with the family will be out of town and I might actually get to put the code into chips and solder it down.

[tt]

Using the IIsi ROM in a IIx, it can boot from a 1.5MB image when holding down the 'r' key. Details here: http://synack.net/~bbraun/macromboot.html

Very nice work bbraun! I'd like to try your hack once I get a programmer. I was wondering, does code in the ROM give the disk image a disk icon, hard disk, RAM disk, or something that can be defined with a formatting utility? How's the boot-up speed?

Also, you noted you used a 512KB disk image, but that you can go up to 1.5MB (provided there's room on the ROM), does there need to be additional tweaks to the patcher to go up to 1.5MB?

[bbraun]

This code doesn't provide any icon, and the system just uses the default floppy disk icon. I did this because I was trying to fit the driver within 580 bytes, which is the size of the .netBOOT driver I was replacing. However, by adjusting the resource layout and replacing both the .netBOOT and .ATBOOT drivers, I'm up to about 1152 bytes (plus or minus some resource header space). This could be used to provide custom icons, although I've also got some additional functionality I'd like to squeeze in as well, so we'll see how it goes.
You might be able to provide a custom volume icon just by replacing the icon in the Get Info dialog, when you're creating the image. I haven't tried that, it might be a good compromise solution.

Boot up speed is fast with 6.0.8 on the IIx. I haven't quantified anything, but I guess I should make a video or something.

Originally, I was using a 512KB disk image because in my early experiments with replacing the floppy driver, I had problems and believed I couldn't access beyond 1MB of ROM (512KB IIsi ROM + 512KB disk image). Maybe I was wrong or maybe it doesn't apply the the IIsi ROM (I was initially using the IIx ROM). But either way, there's nothing special necessary to use the full 2MB of the ROM SIMM (512KB for IIsi ROM, 1.5MB for disk image). The driver has a hard coded constant of how big the disk image is, and that needs to match reality. The ROM Patcher I provided expects a 1.5MB disk image, while the other stuff there used a 512KB disk image.

I had some visions of checking for additional keys held down and optionally instead of a ROM disk, copy the disk image into RAM and boot from that. That'd allow a writeable boot disk, which opens up some additional possibilities. But there are some challenges there, so I'm not sure.

[tt]

Thanks for explaining, just wondering how the hack works from a user perspective since I haven't seen it yet. A video would probably clarify, but if it takes time away from coding...

Applying an icon within System 6/7 probably makes the most sense. I was curious how the system treats the disk image, and it sounds like the answer is a floppy. In the code's current state, is the disk image kept in the ROM or is it loaded into RAM as read-only? I'm guessing if it stays in ROM, then it's probably a bit slower when read than being stored in RAM, but would save RAM space.

[dougg3]

I made a video a while back of an early version of bbraun's ROM disk hack on a IIci:

http://www.youtube.com/watch?v=SEFcQRmYtBI

The main delay is the RAM test, I think. If we can get that disabled, I'm pretty sure it'll boot REALLY fast. Once the Happy Mac comes up, you're almost instantly to the Desktop at least with System 6...

[tt]

Nice, yes it is very fast after the happy Mac appears. I haven't booted a IIci before... what is the initial delay (from switch flip to blank screen getting populated) before the RAM test? It seems to be as long as the RAM test (gray screen). How much RAM is installed?

[dougg3]

I don't know for sure what causes each delay, but this IIci has 32 MB of RAM I think.

bbraun: I tried your patch onto a IIsi ROM (ran the patcher utility), appended a 1.5 MB disk image to the end of the resulting file, and burned it to my SIMM, but for some reason, it causes a Sad Mac and chimes of death in my IIci.

[bbraun]

Well, a bit of disappointing news it looks like.

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'll go back to playing with it and see if there's much I can do.
Thanks for the testing!

[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/l ... c_IIci.pdf

ROM 24-bit address space: 0x80 0000 ... 0x8F FFFF
ROM 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...