Another IIci ROM hack

[olePigeon]

Yeah, it really is! I should try to disable the memory test too. I bet that would make booting *really* fast! That IIci has 32 MB of RAM. I can't imagine how crazy long the startup would take if it had 128 MB.

Hah, tell me about it. My IIci has 128 MBs. I usually hit the power button, then go make a sandwich.

[Trash80toHP_Mini]

That reminds me of a friends story about hitting the play on the cassette deck and going to the fridge for a beer!

Dang, you missed it, oldbird ------------- 25 Pages ------------

Go, DQ & Company!

[dougg3]

Sounds like we definitely need to disable the RAM test then It can't be too hard to do.

I just got an e-mail saying my PCB file is under processing. I guess we'll see if it meets the design requirements. I just realized I used a 12 mil diameter drill for most of the vias (except for power/ground ones), which is pretty much the smallest they offer. Hopefully I'm not pushing it too far on the via diameter limit...

[olePigeon]

Do you need SIMM sockets?

[dougg3]

It'll probably be at least another week before I have a board to assemble and test, and it'll take a while to develop the software to test it out, but yes, I will be needing to buy some SIMM sockets from you soon...

[bigmessowires]

Woah... today is the first time in months that I've hit "View New Posts", and not seen this thread in the list. The horror!

[olePigeon]

I'll send you a few anyway. With it being so close to the holidays, it might actually take a week for them to get to you.

[trag]

I'm pretty certain that disabling the RAM test at start-up is controlled by one of the PRAM memory settings.

Either or both of the Daystar Turbo040 and the Turbo601 Control Panels have a setting to disable the start-up memory test. It should be possible to dump the PRAM contents before and after to find the controlling location.

Of course, it may be more complex than that, with the Daystar Firmware taking an active role, but I hope not.

[bbraun]

The II/IIx ROMs are different from the 32bit ROMs (and the 040 ROMs look different from the 32bit 030 ROMs), and I'm trying to understand it all, but the II/IIx ROMs toggle the ram test based on whether it's a warm boot, which checks 0xCFC for the value 0x574C5343 to see if it's a warm or cold boot. The RAM test can be called from several locations in the ROM though, so it might just be easier to throw an RTS in at the RAM test location. The accelerators probably just fake a warm start.

[tt]

Of course, it may be more complex than that, with the Daystar Firmware taking an active role, but I hope not.

According to Gamba it's a combo of PRAM and DayStar ROM: http://www.mail-archive.com/compact.mac ... 06028.html

[bbraun]

Well, the accelerator software would store it's setting in PRAM and the card's firmware would read that to determine whether it should disable the check or not. The system ROM doesn't check the PRAM.

[trag]

doug3 et al,
What about adding SCSI Manager to your ROMs, just like it's made in the newer machines?

It would be interesting to add the SCSI Manager to the ROM of the Quadra 900 and Quadra 950. Each of those machines has two physcial SCSI buses, but treats them as a single logical bus.

Presumably, SCSI Manager in ROM would or could cause them to be treated as two logical SCSI buses at boot time.

[Trash80toHP_Mini]

That would be a most excellent hack!

[trag]

Well, the accelerator software would store it's setting in PRAM and the card's firmware would read that to determine whether it should disable the check or not. The system ROM doesn't check the PRAM.

Well, pooh. That's the worst case I referred to in my last sentence. Setting in PRAM, but Daystar firmware required in order to do anything with the setting.

I wonder how useful it would be to add aspects of the Daystar firmware to ROMs even in machine in which an upgrade won't be used.

A package of useful ROM routines would be nice, including the ability to disable the memory startup in a control panel or other app. and SCSI Manager 4.3.

Although, I'd really like to rewrite/replace SCSI Manager 4.3 with a more versatile -- can't remember the name -- but the search function comes to the rescue.

http://68kmla.org/forums/viewtopic.php?p=20085#p20085

From 2007:

They're also going to need to write a SCSI Manager 4.3 type XPT so that the host machine can handle having more than one SCSI bus.

Discussion of XPT and SIM can be found fairly early in Chapter 4 of "Inside Macintosh, Devices" which is downloadable from Apple as a several PDFs (one per chapter, chapter 4 is titled "SCSI Manager 4.3).

The advantage to writing a replacement for SCSI Manager is that one could put in actual IDE support and add the hooks for USB support, in theory. Adding USB hardware would be relatively easy. There are USB chipsets (or were) whose interface side is for regular micros and not PCI. Adding firmware/driver support would be a pain.

Heh, rereading that old post, I see that I was log-jammed in projects back then too. Four years ago and it mentions those blank circuit boards on my desk, which are still there. Sigh. Also mention of the concept of an SE/30 ROM SIMM.

[bbraun]

A package of useful ROM routines would be nice, including the ability to disable the memory startup in a control panel or other app.

Two aspects to this:
1) I'd like to see an app that applies our known patches to existing ROMs. Add the ROMdisk driver, set bootup sound, set icons, etc. When we know how to do more, fold that in, and have a central tool that can pop out ROMs with modifications we know about. There's a bunch of details to sort out on that, but it seems reasonable.
2) Selectively disabling the memory test based on PRAM settings. The challenge here IMO, is PRAM is not mapped directly into the address space, it is accessed via the RTC chip. So, I don't know how to retrieve PRAM without using RAM. Using RAM to know whether you can trust RAM seems like a bad situation to be in. Maybe I'm just being dense and it's easier than I think... Just disabling it in the ROM image entirely (no checking) would be the easy route, and probably at least the first step.

The advantage to writing a replacement for SCSI Manager is that one could put in actual IDE support and add the hooks for USB support, in theory.

Well... There are lots of ways to go about adding USB Mass Storage Class support, if that's the goal.
My understanding of the User to SCSI target call chain is limited, but here's my understanding at the moment.
On boot, the ROM eventually loads SCSI Manager, which is really a set of calls and a driver (but not a DRVR that occupies the Unit Table, SCSI drivers are different) for the actual SCSI controller. The ROM then uses SCSI manager to look for disks, reads block 0 which is expected to contain a driver descriptor record, using the driver descriptor record it then loads the disk's driver into RAM and adds a copy of the disk's driver to the Unit Table, opens the driver, and all subsequent access is through that driver. Using the loaded driver, partitions are then parsed by the Start? SCSI? Manager, a Drive entry is added to the Drive Queue for each partition, and a diskEvt notification is posted for each drive in order to get mounted. Then when the entire SCSI chain has been traversed, all drives & partitions found, drivers loaded & opened, it returns and the booting process continues, selecting a boot disk based on the usual criteria (boot floppy if there's one inserted, eject floppy if mouse is down, consult PRAM to figure out the selected boot disk if no floppy is inserted, etc.).

If just using a USB disk as bootable storage on 68k is the goal, as opposed to full USB support, there are shortcuts! Have a microcontroller handle the USB interface to the device (USB OTG seems cheap and readily available, and probably has sample code available for this), and have a dead simple interface between the host CPU and the microcontroller. Mac block device drivers only know how to do 3 things: 1) read data in 512byte block multiples from a given location, 2) write the same, and 3) verify the data written was correctly written. Everything else is implemented as an optional Control call (format, eject, icons, etc.) All of that could be offloaded to the microcontroller, resulting in a fairly straightforward driver that would be advertised in a declrom. There's a bunch of details in there, including the fact that partitions wouldn't work since only SCSI drives can have partitions, apparently due to the fact that SCSI Manager is what parses partitions.

[bigmessowires]

The challenge here IMO, is PRAM is not mapped directly into the address space, it is accessed via the RTC chip. So, I don't know how to retrieve PRAM without using RAM.

Actually that's no problem at all-- the Mac Plus ROM does exactly that at start-up, and other Macs probably do the same. Check out the fdplus commented ROM disassembly from fdisasm.

If I recall, there's a self-contained routine in ROM that takes the PRAM address to read in a register, and returns the value in another register, with no use of RAM.

If you disable the RAM test entirely, will there be some other way for the Mac to know how much RAM is installed? You could probably write a different routine that only checks every 1MB or something, instead of testing every single byte.

[bbraun]

Ah, right, it looks like the ClkNoMem stuff would work well, thanks!

At least for the Mac II, finding the size of memory seems to be independent of the RAM test, but I'll take a closer look next time I reprogram my SIMM. Basilisk II disables the RAM test for the Classic ROM, but doesn't bother for the 32bit ROM path.

[olePigeon]

Sorry if I already asked this, but is the RAM limitation on the LC a ROM or hardware limitation?

[bbraun]

Earlier, a ROM patching program was mentioned. We're not there yet, but I've setup the beginnings of one at:
http://code.google.com/p/macrompatcher/

The idea behind this is to have a C library that has functions to apply known ROM modifications, and that library can then be used "wherever" for front ends to use for nice user friendly ROM modifications.
Ultimately, it'd be nice to have a cross platform GUI. That's not done yet.

At the moment, it just contains a library that applies the ROMdisk driver, and a posixy command line tool that uses it.

If anyone wants to contribute, let dougg3 or myself know and either of us can provide access. Feedback welcome.

[dougg3]

In other news, all the parts I need for the SIMM programmer (apart from the PCBs themselves) are here other than SIMM sockets--olePigeon and I are working together on that soon. Woohoo! So now I play the waiting game to see if the PCBs pass the manufacturing test with Seeed Studio.

In the process of building a couple more ROM SIMMs tonight, I accidentally lifted a pad on one of the PCBs I had accidentally messed up one of the PLCC sockets so I had to remove it. I tried Chip-Quik and it worked great, but I think I pulled up with too much force (and perhaps had my iron set too hot) and the pad came right off...ughh. I'm now an official member of the pad lifter club.

[Trash80toHP_Mini]

LOL! I joined it over twenty years ago, welcome aboard. Just try to avoid the brotherhood of the magic smoke on your quest, DQ! [;)

bbraun, that sounds like you're still making tremendous progress, nice work.

[dougg3]

LOL...I'm definitely taking all precautions necessary to avoid joining the magic smoke club

Here's an interesting tale. One of the SIMMs I assembled last night didn't work. I found a short, but it wasn't between two nearby pads or a pad and a via or anything like that. I searched over and over and over and couldn't find anything that looked bad. However, I could tell it had to be between a PLCC pad and a trace nearby it, because it was between two lines that are next to each other (when one line is at a PLCC pad, the other line's trace is running next to that pad, and vice versa at multiple spots on the SIMM). So I got frustrated last night and gave up.

I came back to it today. I ran a really low current through the short and measured the voltage at various places to see where the short was. You can see the voltage keep increasing at various points (or dropping, depending on which side you start from) as the current flows through the circuit, it's kind of cool. I pinpointed where the short should be, but couldn't find anything, I'm guessing because it was a board defect under the solder mask, near the PLCC pad and impossible to see under the socket.

Anyway, since I had nothing to lose, I ran about 3 amps at a low voltage through the short and suddenly it wasn't drawing any more current. The short is gone and the SIMM works fine now I zapped it!

[ojfd]

Anyway, since I had nothing to lose, I ran about 3 amps at a low voltage through the short and suddenly it wasn't drawing any more current. The short is gone and the SIMM works fine now

You blew it like a fuse, I guess.

[Trash80toHP_Mini]

LOL! and the PCB contained the extra magical benevolent white smoke!

[dougg3]

Haha, yep! I did blow it like a fuse. I saw online that some people have had mixed success with the approach so I gave it a shot and it worked I hope it blew the short enough that it won't creep back in. I guess if it's under the solder mask that probably won't happen.

That's the kind of magic smoke that I like!