trag wrote: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.
trag wrote: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.