S-100 bus and device drivers

Question

It is said that the S-100 bus provided a standard hardware format for expansion cards across many models of computers, including ones using different system software and even different CPUs.

Having plugged in an expansion card, how does the computer know what to do with it? Today's computer industry has settled on device drivers as the answer to that question, but today's computers have only a handful of operating systems to write device drivers for, hard disks to install them on, and spare memory to load them into, all of which would seem to be necessities. How did they handle it in the S-100 days?

Answer 1

Like most busses of its time, you had to write your own software to communicate between the cards.

The term device driver wasn't widespread at the time, but that is what you were writing.

The S-100 bus (IEEE696), with its standard 100-pin socket could support a number of different cards. While it was common to have a processor card, memory card and assorted I/O controller cards, it was possible to have co-existing processor cards.

The bus protocol is still available on the web, e.g. here, giving details of the bus pins and signals. There is still a thriving community of users and builders, where some more beginner-friendly information may be found.

The bus is split into sections:

Address  
Status  
Data  
Control  
DMA Control  
Vectored interrupt  
Utility

Controlling a card over the bus essentially meant claiming the role of Bus Master and then addressing the card you required. I/O cards could raise interrupts to gain the attention of the processor.

There were - still are - a large number of different processor cards available on the S-100. Each capable of running one or more operating systems. Exactly how you implemented the software to control another card on the bus would vary from OS to OS and CPU to CPU. I couldn't attempt to list them all here.

You state in your question that there are only a handful of OS today where you can write a driver. Not true, you can write drivers for any modern OS, it is just that some of them make it harder for you, and some device manufacturers won't tell you how to control their device.

There is a lot of information and open source code for S-100 out there. Learning from it will help you be able to write device drivers for modern kit.

Answer 2

An important thing is that old-style expansion buses - that includes S100, als well as the PC ISA bus and various proprietary buses, had no enumeration capability - a computer system was not aware of what was installed in the slots unless it explicitedly tried using any of that hardware - and what I/O addresses it responded to. Neither could I/O resource allocation be configured by the firmware or OS.

You can probably compare it with how things were handled with pre-MCA/PCI PC hardware: Well-known/usually installed devices (FDC, RTC, video cards, were pretty standardized in their addressing and protocol, so the BIOS and/or knew where to look for what. Other expansion cards didn't only need a driver (or application software that included its own drivers), but usually needed you to explicitly a) install the right driver, b) configure that driver with the I/O settings - the same you used to configure on the expansion board, usually with either physical switches or special vendor software, c) configure the BIOS to leave these I/O resources well alone when configuring PnP/PCI devices in mixed ISA-PCI systems. Such was still common practice in the Windows 9x/2000/NT era. Mistakes could sometimes end up in a nasty crash!

In S100 days, likely operating systems just listed what they supported for their own purposes - which would mostly concern serial ports for character terminals and mass storage devices to handle files on. More exotic hardware (framebuffer graphics, sound, industrial control...) was certainly the application program's business. Operating systems that restricted direct access to hardware were not common for S-100 sized machines :)

Also, do not forget that there wasn't much of a concept of front side vs peripheral buses in these days, in machines of that size: The I/O bus was the same that was used for memory access, and ROM and RAM - which a CPU intrinsically knows how to handle! - was commonly on plugin boards on the main bus itself (that too was not uncommon in pre-80386 PCs, and possible with many ISA 386/486 systems but at an atrocious performance penalty!). The address space these devices mapped into was usually configurable on the hardware (physical switches again) and likely needed to be configured to the OS and application expectations. An expansion bus these days was in fact a glorified memory interface with a couple of extra lines to handle interrupts, DMA, power supply (in the S-100 case: raw unregulated DC, boards were expected to bring their own fine-grain power supply circuitry just as PCI cards did more and more in recent years ;) ), all kinds of system housekeeping signals, and whatnot. Peripherals were expected to behave like RAM with an attitude.