FireWire interfaced NIC/Driver development possibilities?

[Trash80toHP_Mini]

Been wondering about this on and off for a while now. Not sure FireWire interface could support such a critter?

A faster external NIC (WiFi?) for slot limited PCI Macs seems worthwhile? Original concept was for TAM and 6x00 by extension. Dunno how much performance a GigaBit NIC(?) over FireWire might have have over 10/100 in those architectures, but might be interesting to try?

Anything else (G3 and up) could get quite a kick in the tuschie, not to mention Pismo/Ti.

What might the speed limit be for FireWire 400 under OS9? FireWire 800 G4s?

 

[demik]

That's not needed
FireWire was designed to do some networking (at least IPv4 and IPv6)

Just need to connect to another firewire-able able computer. This works on macOS, Linux, and FreeBSD

IIRC, FireWire overhead is about +20% for this, so about 300 Mbps for FW400

 

[Trash80toHP_Mini]

But wouldn't that be about 3x faster than 100BASE-T? Not Gigabit for sure, but a significant improvement over onboard Ethernet, no?

 

[cheesestraws]

Yes, IP over firewire is faster than 100mbit ethernet, although note that you're probably going to hit OS throughput limitations before you get a serious boost.

 

[uyjulian]

At least on most modern macOS (with the "Internet Sharing" feature), bridging e.g. Wi-Fi, ethernet, thunderbolt, LAN, your phone, etc. to e.g. FireWire is pretty easy. In System Preferences, "Sharing" -> choose "Internet Sharing" -> share from Wi-Fi -> to computers using FireWire (if FireWire doesn't show up, try plugging it in at least once, or manually adding/enabling it in "Network" settings)

If you are talking about a new device, I'm not too sure if SoCs HCIs etc supporting FireWire are even being manufactured anymore

 

[Trash80toHP_Mini]

Figures they'd be discontinued. Was thinking in terms of an external modem/WiFi doohickey for old world/old new world Macs with limited slots and pokey onboard networking. 2x-3x the speed of 100mbps would be (might have been) nice.

 

[LaPorta]

Figures they'd be discontinued. Was thinking in terms of an external modem/WiFi doohickey for old world/old new world Macs with limited slots and pokey onboard networking. 2x-3x the speed of 100mbps would be (might have been) nice.

FW800, too?

 

[obsolete]

As mentioned above, IP over firewire is already a thing, but only in OS X, Linux, and some versions of Windows. Apparently there is/was also some non-free software called Unibrain FireNet for OS 9.

If you wanted to play around with firewire networking on a SBC, I think a Raspberry Pi 5 or CM4 with a PCIe x1 firewire adapter and the other network interfaces of your choice would be a viable solution.

 

[Trash80toHP_Mini]

FW800, too?

Nap. OS9 forever.

 

[CC_333]

Nap. OS9 forever.

Then somebody ought to get FW800 working at native speeds on OS9!

With all manner of logic board recreations, new software, and innumerable other goodies, why can't anyone tackle the comparatively simple task of writing native OS9 drivers for USB 2.0, FW800 or newer 802.11g/n/ac/ax/whatever WiFi adapters?

I'd do it myself, but I don't know how.

c

 

[cheesestraws]

comparatively simple task of writing native OS9 drivers for USB 2.0, FW800 or newer 802.11g/n/ac/ax/whatever WiFi adapters?

If it's relatively simple, I will await your forthcoming driver pack with interest.

(It isn't relatively simple).

 

[CC_333]

If it's relatively simple, I will await your forthcoming driver pack with interest.

(It isn't relatively simple).

Perhaps I've underestimated the difficulty.....

Still, it's theoretically possible, and there's plenty of very talented people around here who could probably do at least some of it. So, how come not? Is it that hard?

How did they ever do it when this stuff was new?!

c

 

[cheesestraws]

How did they ever do it when this stuff was new?!

They were being paid to do it, and they had more people doing it. And the documentation hadn't got lost.

To do what you want would require basically rewriting the whole WiFi stack for OS 9, and that's a miserable and long job.

 

[CC_333]

They were being paid to do it, and they had more people doing it. And the documentation hadn't got lost.

To do what you want would require basically rewriting the whole WiFi stack for OS 9, and that's a miserable and long job.

I see. Oh, well.

Maybe in time something like ChatGPT could do it, for free and much faster than even a team of people could go (it would undoubtedly still need to be fed the aforementioned lost documentation, which would somehow need to be found, and the results would need to be proofread and fixed by humans as needed, but the bulk of the miserable part would be done).

Or the source code will get released, either officially or unofficially via a leak, in which case all one would need to do is tweak and rewrite as necessary to learn it and create new documentation (again, I'm probably grossly underestimating the difficulty level, but it is theoretically doable by someone willing to deal with the long misery of it).

c

 

[uyjulian]

The way to use Wifi or USB2.0/EHCI or other newer interfaces in OS9 right now is to use OSX with Classic.

For OS9 bare metal, writing something new would be a pain, so it might be easier to port something in a manner similar to e.g. Haiku's FreeBSD compatibility layer. It might also be easier to add a preemptive multitasking layer which OS9 process and network/interface/etc. drivers can run under on instead of trying to make the drivers work in a cooperative multitasking environment.

 

[cheesestraws]

For OS9 bare metal, writing something new would be a pain, so it might be easier to port something in a manner similar to e.g. Haiku's FreeBSD compatibility layer.

They recently retrofitted this kind of thing to RISC OS, I think using the OpenBSD stack rather than the FreeBSD bits because it turned out to be easier (I wasn't following the project in great detail, so take this for what little it is worth).

It might also be easier to add a preemptive multitasking layer which OS9 process and network/interface/etc. drivers can run under on instead of trying to make the drivers work in a cooperative multitasking environment.

If we can take the RISC OS work as a kind of analogy, that's probably unnecessary: RISC OS is more aggressively and restrictively cooperative than MacOS, even, and they didn't need to muck about with that...

But the key here, to follow up @CC_333's point, is that it was a lot of work and someone - as far as I know who it was hasn't been publically disclosed - paid for that work.

And while in theory the work could be do-able by one nutter on their own, the state of low-level software development in the RISC OS scene is far above the state of it in the old mac scene (which is ... bad; to take one example, when we have people selling NICs with duplicate MAC addresses in order to avoid dealing with the driver situation, that's frankly just embarrassing. I bring up this example, for reference, because it shows how far we are from having the intellectual and engineering resource to actually do this specific work.) Personally, this is a project I would run screaming from.