Mac OS 7.1 drivers for USB 2.0 & FireWire 800

[ArmorAlley]

I haven't written compilable software since my first year in university (back when SE/30s were new in the shops).

So my questions are very much at a newbie level:
1. How many hours would it take to develop & test drivers for Mac OS 7.1 onwards for USB 2.0 and FW800? Hundreds? Thousands?
2. Based on this answer, how much would a programmer realistically have to charge (say, by means of crowdsourcing) to write the code?
3. Would there be enough of a demand amongst the community of old Mac collectors for such drivers?

 

[LaPorta]

Good questions. I suppose part of the question also would be would the devices attached themselves also need rewrites (meaning, are they dependent on other parts of the system software other than USB/FW drivers themselves)? Also, what sort of Macs would be able to use 7.1 and also PCI-based cards as such?

 

[ArmorAlley]

A correction, for I think that you are correct and I am wrong.
The earliest PCI Macs ran SSW 7.5, while the earliest PowerMacs ran SSW 7.1.2.
The USB 2.0 & FW800 cards that would work on Macs running SSW 9.2.2 or below would have to be either PCI, PCI-X, CardBus, PCMCIA.
The drivers that exist for USB 1.x & FW400 from SSW 8.1 onwards are generally hardware independent.
Now, a FW800 might very well flood the PCI-bus of a poor PM8200. This is a risk to be considered.

 

[LaPorta]

I know my PT Pro, PCI-based, runs at least 7.5.3, so that at a minimum could be possible.

 

[Trash80toHP_Mini]

Don't know about programming drivers to deal with USB and FWx00 at the system level, but I suspect the answer would be not practical even if possible.

First take: SCSI is a well defined, general use Small Computer (read MiniComputer) Systems Interface. IIRC, IDE implementation in that time frame was shoehorned into the SCSI drive hooks already existing in the baseline system architecture of the Mac. Interfacing just about any I/O device via SCSI is possible, given speed limitations of any given Mac or SCSI card.

We've seen all kinds of RetroDev projects for the SCSI bus. I'd say tag along with that open source flow if practical.

More capable fork: I've got a National Instruments General Purpose I/O Nubus card. Such might be a route to a faster/more capable implementation via NuBus or PDS.

Jumping off from nascent VidCard projects could be a viable approach for further development. Interfacing to the buffered National Instrument GPIO connector could be a useful wedge into the system for prototyping without the need to implement NuBus. Think of its connector as the equivalent to RPi GPIO?

/two cents

 

[chelseayr]

been thinking a bit about this thread and heres my random takes on it to take with your own salt...

firewire 400 did somewhat exist in 7.x but simply for video-capture purposes (as far as I know noone had sorted out the storage extension/hack needed last that topic was ever discussed of about on system7today)

firewire 800 is to be honest likely way too much for even a heavily accelerated system to handle (or to put it another way, how do you think the shared expansion/system buses could like trying to choke on 600+mbit/s?) ... by the time we get to better pci&sdram buses we're likely then already at G4 cpus which pretty much generally requires at least 8.5 bare minimum

usb is mm well lets say I would prefer to ignore it or if you have to ask then at least just provide usb1.0 for the purpose of input devices etc (hopefully the least overhead&extensionwriting invasive thing or maybe not..I'll let someone have final say)

trash80 I'm inclined to agree with you as the official scsi spec provides for a lot of non-storage uses too so it would likely be a much easier aim than either 1394 or even usb. you even can do scsi video too (can't cite this now as its been many years I last remember reading about that sorry)

 

[slomacuser]

I would say not worth it. There is Bluescsi DB-25 out, that is Mac external scsi to sd card connection which I think is wonderfull solution.

 

[Melkhior]

Well, funny you should mention software for USB and old Macs

As mentioned in another thread, I'm considering building a NuBus carrier board for a FPGA, and one of the feature is a USB host connector (using a micro-B to save space) even though the primary goal is to create a framebuffer device. The USB works for a somewhat more modern bus in my SBusFPGA design, where the FPGA includes an open-source USB OHCI controller (so USB 1.1 only) that NetBSD/sparc can make use of (I only needed to write a SBus -> OHCI shim driver, the USB stuff is standard NetBSD; I didn't even think about good old SunOS or even Solaris). I only ever expected to try USB with NetBSD/mac68k and not System 7/MacOS 8.

I've yet to convince myself the board could work and order a couple. Seeed is likely over €500 euros for two populated boards, once custom duties are factored in... buying a lot more is a lot cheaper per-unit, but the design isn't proved yet so it's a risky bet :-( And I don't really need more than a couple anyway).

Another risk is that OHCI, even with just USB 1.1, is a bandwidth-intensive bus master. It doesn't quite overwhelm a 25 MHz SBus with reads handled by buffered 16-bytes burst, but I'm not sure that non-burst access will be fast enough over the 10 MHz NuBus...

For 68k Macs, I suspect the entire USB stack would have to be written, which would be quite a job (even if it were possible to reuse some *BSD code and stick to just HID and Storage at first). However the NuBus-based PowerMacs might have some support available in MacOS 9.1; *if* there's some OHCI support in there, then it *might* be possible to be in the same situation as NetBSD and just need a driver to register the NuBus-based OHCI controller to the OHCI driver... Unfortunately I don't have a NuBus PowerMac (and my PCI one is quite dead) or any knowledge of 9.1 internals.

In all cases - this would be the kind of software written as a proof-of-feasibility; there won't by any money in it (especially if you need hundreds of euros worth of custom hardware just so you can plug an USB mouse on your PowerMac 7100 ...).

 

[Franklinstein]

Another risk is that OHCI, even with just USB 1.1, is a bandwidth-intensive bus master. It doesn't quite overwhelm a 25 MHz SBus with reads handled by buffered 16-bytes burst, but I'm not sure that non-burst access will be fast enough over the 10 MHz NuBus...

Power Macs may be ok since they support NuBus '90 (20MB instead of 10MB/s) in most cases. Alternatively you could interface to the PDS instead, which would get you a minimum 30MHz, 64-bit bus to play with. If you're already doing a combo framebuffer there would be minimal loss from having to displace the A/V or HPV cards in the x100 Power Macs. Of course there's no helping the 52/62xx series; they're basically just providing an emulated '030 bus and even if you built the card for the full 32 bits available in the LCIII PDS you'd still be stuck at 16MHz running through a couple bridge chips ('030<->'040<->PPC)
Mac OS 8.1 should provide at least minimal support for USB and it's definitely present in 8.5 so it's not just 9 or later.

If you could get source code for later Mac OS USB support it may not be terribly difficult to backport them to OS 8 (lots of later stuff won't run on 8.1 because it's missing some libraries but if you sorted out the various dependencies it should run without too much problem) and possibly recompile for 68k though you'd likely be limited to running on high-end machines like the Quadra series (the 840av also has NuBus '90) or maybe the IIfx (since it has so many coprocessors the main processor could devote more attention to USB). I'd wager that System 7.5 would be the earliest you could get USB to work though.

 

[Melkhior]

Unfortunately in my current design neither /tm2 nor /syclk2x (for NuBus90 support) are connected, it would require too many pins; /tm2 needs bidirectional level shifting which currently means two pins on the CPLD, plus a direction control signal - it's handled differently to /tm0 and /tm1 so cannot share the control signal. Plus a couple more for the 2x clock, though that could use a dedicated chip as it's unidirectional - but it also needs to be routed to a clock input pin on the FPGA (I admit the design is burning a lot of FPGA pins on implementing both VGA and HDMI to ensure some video output will work, but the CPLD is also an issue; the CPLD would need a much larger package).

As for the source code - it would be lovely if Apple were to make the code source for 6/7/8 publicly available, but I wouldn't hold my breath; they may not even still have it, let alone have the will to release it. You wouldn't believe how fast companies can loose institutional knowledge of their own obsolete products. In the mid '00s there were some initiative to recover data from Sun Microsystem on older hardware to help FOSS, and Sun was willing to help (this is before the Oracle buyout, obviously), but some stuff was already "unable to locate". In some cases for common hardware still sold only 15 years before, like the TurboGX+ framebuffer.

 

[Franklinstein]

I'm not sure if there were 3rd party USB drivers for classic Mac OS or not. I think LaCie may have had something but it was probably just enablers or accelerators or whatever for their specific products and they interacted with Apple's core drivers for basic functionality. Apple would probably not be a good source to go looking unless you found a very friendly former employee who happened to be a data packrat and was willing to share the hoard. Especially interesting would be source for System 6.0.5 or whatever it was that was hand-tuned for maximum performance on the IIfx. I figure there are some good comments in there. But I do understand the frustration: too much of this stuff is lost to time after only a few years. Sony are really bad about it, not even admitting to making half of the stuff I have that clearly bears their logo, let alone making software or documentation available for them.
I figure if I were a programmer I'd have enough pride in my work to keep copies of my projects, but then if it was a major collaborative effort like the Mac OS and I just contributed a few bits and pieces I may not be privy to the full product and thus what I had may not be worth much. Fortunately we do occasionally find someone who was not only a data packrat but is also willing to share: there's a thread here where a former employee at BUG in Japan was able to provide not only driver files for various products but also source and lots of documentation (albeit mostly in Japanese). If only more people were like that.

 

[Trash80toHP_Mini]

Are you excluding USB1/FW400 drivers for cards in 6x00, TAM etc. from your definition of classic Mac OS? If so, why?

 

[Franklinstein]

Are you excluding USB1/FW400 drivers for cards in 6x00, TAM etc. from your definition of classic Mac OS? If so, why?

If that's aimed at me, I'm excluding them because I'm unaware of anything that works properly in pre-OS 8 environments. I've heard of and even performed a few hacks to get stuff to work in some otherwise unsupported machines but all of my experience has been that there's nothing that works in System 7 or earlier, and there's no support for USB in any Mac OS on 68k (mostly because there never existed a USB adapter for 68k Macs). There weren't huge core differences between 7.6.1 and OS 8.1 (there was a larger gulf between 8.1 and 8.5) so it wouldn't be a huge surprise if someone did have working USB support for that but I'd be skeptical of the claim unless there was info/files to download where I could get it to work myself.

But that's why in the posts upthread there was discussion about the availability of source code for USB drivers for OS 8.1 for ease of porting/recompiling for 68k support, possibly also adapting them to work under late System 7, so as to reduce the amount of work needed to get Melkhior's USB adapter project to function.

 

[Trash80toHP_Mini]

Yep, was referring to your previous post so no need for quote. To me Classic OS extends to 9.2.2

For anything older than 8.x USB (and maybe FW400) would need to use the hooks for SCSI devices in ROM/OS that were extended to support the first IDE implementations. SCSI spec is well documented and intentionally designed to support any imaginable system interface.


that'd be the logical wedge for hacking USB devices into the system I'd think?

 

[cheesestraws]

For anything older than 8.x USB (and maybe FW400) would need to use the hooks for SCSI devices in ROM/OS that were extended to support the first IDE implementations

Not true. You can have a driver to back block storage onto anything you like without having to hook into the SCSI manager. This has been the case since the year dot: how do you think serial port hard discs or the HD20 worked?

 

[Trash80toHP_Mini]

Granted, but HD20 was slow as all get out because it used ports on the backplane running through bottlenecked bits on the board.

Later implementations of MFM internal drives would be more what I'd use as a reference point for anything predating the Plus. Those boards were of the Killy Klip/68000 leg PDS variety IIRC, no?

Back in the day I wondered about doing a board that plugged into the 68040 socket with passthru that might work for USB on legacy equipment. Same deal with pulling the 68030 out of my IIfx to re-socket it on the USB board. Any USB implementation for communications should avoid any bottleneck such as NuBus. Peripherals could be done differently, but they work outside the box just fine.

 

[cheesestraws]

Granted, but HD20 was slow as all get out because it used ports on the backplane running through bottlenecked bits on the board.

The speed isn't the point. The point is that the software didn't run through the SCSI manager, which is what you asserted above.

 

[Trash80toHP_Mini]

Is my understanding incorrect in that IDE was woven into the the architecture via SCSI hooks? ISTR @trag or @Gorgonops making that point many moons ago.

I'd think that would have been at a lower level than SCSI manager?

 

[cheesestraws]

Is my understanding incorrect in that IDE was woven into the the architecture via SCSI hooks

I can't remember how IDE works, but this wouldn't, as you asserted, be the way that USB mass storage would have to be implemented, and in fact I'd argue would be a very bad idea.

 

[Trash80toHP_Mini]

Just edited in that last line above. How would you suggest approaching the problem?