tom jennings on Nostr: Another note on Willetts' questions: Hardware. When the FidoNet protocols got ...
Another note on Willetts' questions:
Hardware. When the FidoNet protocols got documented properly, compatible software exploded. The Texas crew (Opus, Binkleyterm) quickly dominated american users because it emphasized speed, color, etc.
I stayed on a different path, and continued to support the lowest end machines possible. The crappiest that could run FidoNet, or at least Fido, was the Sanyo 555. It was awful. 5.25" floppy only, no DMA or fast IO, and the clock didn't use interrupts. Floppy speed was so slow you'd think the machine died; while the floppy driver was active, the real-time clock stopped. So it could lose an hour a day. But they were cheap!
The 80s was the "IBM compatible" era, and many were not, but they were very cheap. Money was saved by cheaping out on serial ports and low-level drivers, and given that there was no real OS (just a file system) BBS software had it's hardware drivers built-in.
FidoNet didn't require that the system even support hardware interrupts. Everything was single threaded too.
So to ease this the serial driver (particularly) was split off, and became another de facto standard: FOSSIL. Fido Opus Seadog Serial Interface L-something. It defined an abstracted API for Fido/FidoNet (and opus, binkleyterm, seadog, etc) and you could download FOSSIL driver code, hack it up, load FOSSIL, and a FOSSIL version of each program and go.
(Trivia: the Fido/FidoNet program ran via *overlays* like old-fashioned mainframey type chunks of binary that were loaded when a portion of a program was invoked. Overlay programming required very careful program structure at the object level), complicated maps of where modules could land in the logical memory space. I used the Lattice C compiler and Phoenix Software's PLINK linker that did overlays. It was all 8086 Small Model for speed and size. FidoNet would actually run OK in 640K of memory and two 360K floppy drives.)
Hardware. When the FidoNet protocols got documented properly, compatible software exploded. The Texas crew (Opus, Binkleyterm) quickly dominated american users because it emphasized speed, color, etc.
I stayed on a different path, and continued to support the lowest end machines possible. The crappiest that could run FidoNet, or at least Fido, was the Sanyo 555. It was awful. 5.25" floppy only, no DMA or fast IO, and the clock didn't use interrupts. Floppy speed was so slow you'd think the machine died; while the floppy driver was active, the real-time clock stopped. So it could lose an hour a day. But they were cheap!
The 80s was the "IBM compatible" era, and many were not, but they were very cheap. Money was saved by cheaping out on serial ports and low-level drivers, and given that there was no real OS (just a file system) BBS software had it's hardware drivers built-in.
FidoNet didn't require that the system even support hardware interrupts. Everything was single threaded too.
So to ease this the serial driver (particularly) was split off, and became another de facto standard: FOSSIL. Fido Opus Seadog Serial Interface L-something. It defined an abstracted API for Fido/FidoNet (and opus, binkleyterm, seadog, etc) and you could download FOSSIL driver code, hack it up, load FOSSIL, and a FOSSIL version of each program and go.
(Trivia: the Fido/FidoNet program ran via *overlays* like old-fashioned mainframey type chunks of binary that were loaded when a portion of a program was invoked. Overlay programming required very careful program structure at the object level), complicated maps of where modules could land in the logical memory space. I used the Lattice C compiler and Phoenix Software's PLINK linker that did overlays. It was all 8086 Small Model for speed and size. FidoNet would actually run OK in 640K of memory and two 360K floppy drives.)