In the days when DOS was the only operating system around for the PC, my
client, a value-added-reseller of industrial automation equipment and systems,
wanted to develop a system that would allow factories to schedule devices, such
as buzzers, lights, and locks, in advance, for up to one year. The devices were
connected to a peripheral board, which we called the Device Controller, in an
IBM-AT computer. The board was controlled by driver software running on
the PC, and the schedules were created using an application program. The Device
Controller board included an accurate real-time clock and a set of input and
output ports.
In those days, the real-time clocks (RTC) in computers did not even try to
approximate an accurate clock, the times drifted many seconds per day or more.
The problem was exacerbated by a shift in the RTC's oscillator frequency when
the power was turned off and the clock was powered by the backup battery. I
found one manufacturer that took great care of the accuracy problem in their RTC
chip. I tried the chip and found it to be at least 10 times more accurate, with
line power and battery backup, than the RTCs on commercially available
motherboards and peripheral boards. That solved the clock problem.
The input and output hardware was simple enough. I designed a board with a
bank of relays, plus a bank of digital input/output lines, and a set of analog
comparators for analog inputs.
The driver software was the difficult part. My client needed to run their
normal application software while at the same time allowing for interruptions at
specified times for relay activations and other input/output operations.
Operation in the background, although now commonplace in Windows and other
multi-tasking operating systems, was not an easy task in DOS. A normal interrupt
routine that executed one simple function and then went back to sleep was not
adequate for the task. I needed a memory resident program that could not be
corrupted by other background DOS functions such as the display refresh
interrupt. When I could not find any reference material explaining how to write
such a program for DOS, I asked around and was told "It can't be done." Well, I
knew it could be done because DOS included a PRINT driver that performed in the
way I needed. After researching the software rags and looking at some PRINT
assembly code, I figured out how to get around the problem, and my client had a
unique and reliable product.
I manufactured the boards for my client for several years, and many years
later, during the Y2K panic and ensuing fiasco, my client called me back to look
at the old code to ensure it was Y2K complaint. More than ten years later, a few
of their customers were still using the system. I found one line of code in the
scheduling software that needed a simple change.
This project was a good example of careful product definition, project
management, digital hardware development, and innovative software development.
