-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Another IIci ROM hack
- Thread starter dougg3
- Start date
:lol: 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! :approve:
Dang, you missed it, oldbird ------------- 25 Pages ------------ [
] ]'>Go, DQ & Company! :approve:
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...
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...
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!
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.
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.
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.
According to Gamba it's a combo of PRAM and DayStar ROM: http://www.mail-archive.com/compact.macs@mail.maclaunch.com/msg06028.html
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.
That would be a most excellent hack! :approve:
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:
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.
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.
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.
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.
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.
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.
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.
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.
