There are a good few examples of how to write simple mass storage drivers out there: the Mac side is fairly simple. I'm away from home, so can't look this up, so I'm not going to go into huge details, but essentially you write a DRVR that provides operations to do block reads and writes, which would presumably talk to your USB chipset somehow (depending on how much of the processing was on the card and how much was on the Mac), you'd add some drives to the drive queue, associate them with your driver, then when a USB mass storage device turns up on the bus you'd mark that drive as essentially having media in it. The OS would then call your driver to control, read and write from the device. Depending on how the card was implemented you could probably almost implement it like a RAM disc with memory-mapped I/O instead of RAM. Dunno. But delving into the SCSI manager would be a recipe for pain that's totally avoidable.
-
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.
Mac OS 7.1 drivers for USB 2.0 & FireWire 800
- Thread starter ArmorAlley
- Start date
If I said that the Macintosh LC630 Developer's Note says I was mistaken(*); the IDE support software is documented starting from page 67 and it shows the new 68k "ATA Manager" implemented *alongside* the SCSI manager underneath the device manager, not nested underneath it. It does essentially replicate (a subset of) the same API calls so IDE disks mostly "look like" SCSI devices to a greater extent than might be strictly necessary for a bare-bones block storage device, but that makes sense from the standpoint of thus requiring minimal changes for client software that might hit the lower-level APIs like disk partitioning software, formatters, etc.
(* Not going to own making that mistake until I see it, but, eh, maybe I made it? I do remember at one point when we were talking about PCI IDE controllers discussing how the Open Firmware BIOSes of some of *those*, particularly the RAID devices, do apparently look a little more like "SCSI Devices", or at least "Generic Disk-like thing" than native IDE to the Classic MacOS, but that's a different kettle of fish.)
For a really brain-dead example of how to write a Macintosh storage driver, see how the "Sony" driver for floppy drives is reused in abused in various contexts. Most "classic" Mac emulators don't emulate actual storage hardware, they gut the Sony driver (which has the most basic necessary set of read/write APIs feeding into it) and turn it into a passthrough to a "generic" interface to read and write blocks from disk images. It's my vague recollection that essentially this same mechanism is used for those "Rominator" Flash ROM disk hacks for various Macs, but don't quote me on that. If you don't care like your storage device "looking like" a normal disk drive then, yes, you can make the driver pretty darn simple.
(I've seen source code for Macintosh RAM disk drivers that are only a couple K long; if you hung some kind of interface to a USB flash drive into the memory map somewhere and were satisfied with bit-banging control and data bytes in and out of it the whole mess could be pretty darn simple. But of course something like this would *just* be a dedicated storage device; a full hot-swappable USB stack able to enumerate multiple devices and attach arbitrary devices is a much taller order.)
Quite. "How do I expose my block device to the OS" would honestly be the least of your problems when trying to write a full USB stack...
Apologies for the delay, drafted this a bit yesterday then got distracted and forgot to finish and hit post.
Agree that targeting existing PCI USB/FW cards on ~7.6.1-8.1 is probably the easiest starting point, because the hardware already exists and the drivers already exist on newer OSes, although I don't know if there's much to learn from them, I'm presuming the source isn't available.
That said, @LuigiThirty did some work to get USB running on system 7 on PCI PowerMacs so that may be a good starting/collaboration space. (my apologies if "some" mis-characterizes it - it looks really impressive!)
From the boring practical perspective: 7.6.1 on PCI PowerMacs is probably the best place to target, especially if you're looking for storage compatibility, because 7.6.1 has most (not all, but most) of the same volume compatibility as 8.1-9.2.2, which is to say 2TB volumes work on it, just, only plain HFS if you don't do other things.
USB would be interesting but pre-7.6.1 you start to run into other logistical problems for the storage -- 7.5.5 on a PCI PowerMac can't reliably handle >4GB volumes, for example, even though the hardware and many of the interfaces involved can.
I think that USB on older macs would be neat but I don't know that I think it's practical or even a better solution than what we've got now in the ADB<>USB adapters for keyboards/mice, the SCSI disk replacers, and networking.
Agree that targeting existing PCI USB/FW cards on ~7.6.1-8.1 is probably the easiest starting point, because the hardware already exists and the drivers already exist on newer OSes, although I don't know if there's much to learn from them, I'm presuming the source isn't available.
That said, @LuigiThirty did some work to get USB running on system 7 on PCI PowerMacs so that may be a good starting/collaboration space. (my apologies if "some" mis-characterizes it - it looks really impressive!)
From the boring practical perspective: 7.6.1 on PCI PowerMacs is probably the best place to target, especially if you're looking for storage compatibility, because 7.6.1 has most (not all, but most) of the same volume compatibility as 8.1-9.2.2, which is to say 2TB volumes work on it, just, only plain HFS if you don't do other things.
USB would be interesting but pre-7.6.1 you start to run into other logistical problems for the storage -- 7.5.5 on a PCI PowerMac can't reliably handle >4GB volumes, for example, even though the hardware and many of the interfaces involved can.
I think that USB on older macs would be neat but I don't know that I think it's practical or even a better solution than what we've got now in the ADB<>USB adapters for keyboards/mice, the SCSI disk replacers, and networking.
Third party ATA cards used SCSI hooks for their drivers. Hence IDE/ATA busses show up as SCSI busses when one uses SCSI utilities on the Mac.
I don't know how Apple handled support for built-in IDE/ATA busses.
Heh, just quoted you on that. But only to mention that that is also my recollection from the explanation in the original thread when the software was originally developed.
Quoting "Mac OS USB DDK API Reference" p46:
OK; so how do we write an UIM? Same paragraph:
Grrr. Unless someone somehow digs up that information, it's quite unlikely to support any new USB controller in OS 8/9. Information which may never have left Apple, as I don't remember non-OHCI or non-PCI USB ever working in OS 8/9 - so it's likely no-one ever wrote a UIM outside of Apple...
If we were trimming the scope to *just* being a storage solution and we don't care about USB support per se for 68K versions of MacOS then clearly the best solution would be to punt the whole USB stack mess by using a microcontroller that already has drivers for the devices you want to support as your "USB Controller". Then all you need to implement the MacOS side is "stubs" that pipe the data through an as-simple-as-possible message bus. If plodding 12mb performance for your storage device is good enough you don't even need to develop any software on the USB stack side, the "gut the Sony driver" technique would probably work swimmingly to drive a dedicated USB storage chip like the CH375, which has built-in smarts to turn a USB drive into a simple 8-bit parallel interface peripheral. You could hang a chip like this off of a "Rominator"-type hack with a little clever hacking.
(Search "John Bass SCSI" for articles about a pre-Mac Plus SCSI add-on for the Mac 128/512; it interfaced a 5380 SCSI chip into the ROM sockets using a technique in which "writes" were performed by reads against an address range. Can't offhandedly think of a reason that wouldn't work with the CH375.)
Of course this rabbit hole rapidly devolves down to just slapping a Raspberry Pi on a card so you can theoretically talk to any USB device Linux supports and, again, writing MacOS drivers that redirect whatever you want, be that keyboard/mouse I/O, storage, network, whatever. But strictly speaking this wouldn't really be a "USB support for 68K".
I don't really think that would be the case. Think of RPi as a DSP for 68K from the modern world maybe? If it's doing Classic Mac I/O duty and not replacing 68K or NuBus PPC processors as THE computer I'm fine with it.
Not much for stuffing Pi in the face of every problem, but you gotta admit it's a tasty morsel for consideration.
As was expressed earlier, I'm not entirely sure it would even really be practical to implement a full OHCI stack on something as slow as a 68030. I mean, that's probably pessimistic, but it's not exactly the lightest weight thing in the world. And frankly there really isn't much of a point if all existing drivers for USB peripherals under Classic MacOS are only available in PPC binaries and don't have source available.
I think I had posted about this before, but what about using A/ROSE for the heavy lifting? If someone's going to do an FPGA or something already, could do an A/ROSE compatible FPGA. It could then be used for other CPU intensive hardware products on 68k machines. Or new A/ROSE cards for older machines that never had NuBUS.
@olePigeon Is there enough publicly available resources to do a new MCP device using A/ROSE ? You would need the kernel, the associated SDK to be able to implement the device-side of things, the MacOS extension, the associated SDK to be able to implement the host-side of things, all the associated documentation, etc. I haven't seen any of that online, except the A/ROSE extension itself as it's used by the Ethernet NB card. Software-wise, it's going to be *really* difficult I think.
Also the MCP is quite feature-rich in terms of silicon; one would need to replicate the SN74ACT2441 & SN74BCT2425 and maybe more support chips (the 68k has been done as soft-core often enough that it won't be a problem). Documentation for them is still available, but they are somewhat sophisticated chips to replicate even if they only mostly do only NuBus.
Edit: not sure what's in it but there's some A/ROSE stuff here: https://staticky.com/mirrors/ftp.apple.com/developer/Tool_Chest/Devices_-_Hardware/
Also the MCP is quite feature-rich in terms of silicon; one would need to replicate the SN74ACT2441 & SN74BCT2425 and maybe more support chips (the 68k has been done as soft-core often enough that it won't be a problem). Documentation for them is still available, but they are somewhat sophisticated chips to replicate even if they only mostly do only NuBus.
Edit: not sure what's in it but there's some A/ROSE stuff here: https://staticky.com/mirrors/ftp.apple.com/developer/Tool_Chest/Devices_-_Hardware/
@olePigeon No problem. I suspect that for A/ROSE and the Macintosh Coprocessor Platform, not many people know anything nowadays; it wasn't successful back then as it made for very expensive peripherals compared to more custom hardware. Third parties preferred to spend a bit more designing cheaper hardware and more focused software, so they could sell cheaper devices... To the extent it seems the chips required for the MCP are still available NOS from Rochester Electronics, should someone want to clone the Apple Ethernet NB.
In a FPGA, one could indeed emulate the MCP and run A/ROSE, but it might be easier to just get a modern core and RTOS in there or even Linux; Litex/VexRiscv can run Zephyr or Linux in a not-so-big FPGA like the Artix-7 35T I use for SBusFPGA. It would make developing on the device-side a lot easier, but would require re-implementing some form of 'message passing/control' on the host-side, MacOS... This solution effectively would be the 'heavyweight' implementation (full Linux-capable CPU instead of microcontroller) of what @Gorgonops was suggesting for USB!
In a FPGA, one could indeed emulate the MCP and run A/ROSE, but it might be easier to just get a modern core and RTOS in there or even Linux; Litex/VexRiscv can run Zephyr or Linux in a not-so-big FPGA like the Artix-7 35T I use for SBusFPGA. It would make developing on the device-side a lot easier, but would require re-implementing some form of 'message passing/control' on the host-side, MacOS... This solution effectively would be the 'heavyweight' implementation (full Linux-capable CPU instead of microcontroller) of what @Gorgonops was suggesting for USB!
But it would have the benefit of allowing whatever Mac it's plugged into to run at full speed without getting bogged down by any USB stack implementation!
It would also allow for a general purpose coprocessor that could do pretty much anything, including encrypting/decrypting modern internet security and rendering, to some extent, modern CSS and javascript.
Of course, such is more easily and cheaply accomplished simply by setting up a Raspberry Pi as some sort of proxy running some sort of special server which does all this. The best part is that all the necessary software tools already exist in Pi-compatible forms (netatalk, A2SERVER, etc.), so.....
c
Always wished I could use USB 2.0 under any version of classic Mac OS even 9. I've often wondered how difficult it would be to write the drivers for that.
Alternatively instead of exposing a block device, it should also be possible to write an interface to the File System Manager, and then the code dealing with filesystems like exFAT, NTFS, ext4, FAT32, etc could be run on the card. This way the Mac side does not need to worry about filesystems.
Similar threads
