From Tom Jennings in FidoNews 9-05 (February 3, 1992):
FOSSIL drivers' ancient history
Tom Jennings
1:125/111
The FOSSIL interface was originally the Fido internal serial library
interface; the calls are fairly generic in design. I had been using it
for a few years before Fido, in programs like Phoenix Technologies'
TELINK (later Ptel) program. (The original TELINK program was written in
BDS "C" for CP/M, and yes, it contained it's own internal driver of
amazingly similar design (but no interrupts (but I digress)).) At the
time, the "IBM PC" was brand new and expensive, and every hardware
platform (Compupro, Tandy 2000, TI Professional, Computer Devices' DOT,
Otrona Attache 8:16, etc) had completely different hardware. I had a
"driver layer", and wrote simple drivers that were hardware-specific,
and linked them into the program.
(During those years I was writing MSDOS BIOSes, not ROMs but the hidden
\IO.SYS that actually contains the MSDOS.SYS interface. MSDOS.SYS opens
files etc, and passes requests to the driver, IO.SYS, which in turn gets
the job done using whatever the hardware is. What I did was write IO.SYS
in two layers; a very smart one that handled error checking, blocking,
segment boundary handling (can't DMA across a 64K boundary) and all that
really hard stuff, and was quite stable and completely hardware
independent. The hardware drivers were stupid, did no error checking and
talked directly to the hardware, and talked to the smart guy through a
table. With this scheme we were able to do complete MSDOS ports to
virgin hardware, boot ROM, IO.SYS, disk formatter, utilities, etc, in
under a week...)
Anyways, the original Fido used the same scheme for serial I/O. The
driver was linked into the FIDO program using an object linker. Even
post-IBM, there were enough non-IBM machines (DEC Rainbow, Sanyo 555,
etc) to warrant me writing drivers and linking up Fido programs for
them.
Some machines weren't worth the trouble -- and I usually didn't have
access to hardware. (The DEC Rainbow driver took 3 months, and was
written OVER THE VOICE PHONE, as John Madill's Rainbow 100A was in
Balto. The most painful code I have ever written.)
For a typical Fido release in 1985, I created five versions: IBM, DEC,
VICTOR 9000, SANYO 555, and OTRONA ATTACHE 8:16 (I had the hand-wired
prototype (no schematics, not ROM listings!, which caught on fire two
years later). This was getting ridiculous!
So I decided to pass the buck: I documented the serial device functions
(read, write, ready test, etc) and using the existing IBM ROM INT 14h as
a model, made another Fido version, the poorly-named GENERIC Fido. Then,
when someone called me with some wacko computer, I could finally say
"You do it!"
The history from this point on is contained in document FSC-0015,
written by Rick Moore. I'll merely summarize from it.
While I considered myself off the hook at this point, the "Generic"
driver was barely enough to do the job. Thom Henderson (who also had his
own SEAdog drivers) and Bob Hartman built a driver around the GENERIC
interface to solve some particular SEAdog problem; Vince Perriello took
this further and under the extensive prodding of Ken Kaplan (global
FidoNet facilitator supreme deluxe) generated a DEC Rainbow driver and
then SEAdog ran on that now-historic hardware.
Some guy no one ever heard of named Wynn Wagner was trying to get a
commercial serial driver package to work for his Opus, without much
success. Bob Hartman suggested that with a few changes, it could use the
drivers already coded for SEAdog (and by implication, Fido). And, quote,
"...Vince called Wynn to discuss porting Opus to the DEC Rainbow, Wynn
called Bob, Bob called Vince, and the FOSSIL driver came into
existence". ("FOSSIL" stands for: Fido Opus Seadog Standard Interface
Layer.) Rick Moore, Solar Wind Computing, authored FSC-0015, the FidoNet
FOSSIL standard.
In 1987 I finally renamed my FIDO_GEN to FIDO_FSL, dumped my GENERIC
drivers in favor of the FOSSIL system. (It took me that long simply
because I'm lazy.)
In 1992, I upgraded my own drivers. No longer will I have to link up
separate FOSSIL and IBM versions; each program will automatically use a
FOSSIL driver if present, or fall back to the integral driver. It's
amazing how long it takes to get around to these things!