Doug Ross @ Journal

First Job
My first job -- after graduating with a degree in Computer Science -- was at the O Corporation. O is an abbreviation that protects both the guilty and the innocent. My title was "Systems Programmer", but my real role was to find and fix bugs in the company's mainstay product: an Intel 8080-based process measurement and control system.

The systems themselves varied from single-processor with maybe 8K of RAM to multi-processor (Multibus-based) with two or three processors and perhaps 24K of RAM. 4K of RAM was used as global storage, accessible to all of the processors.

The advanced models, of course, used the multi-processor configurations. The extra processors were there to support a CRT (black and white, with 320 x 240 pixel resolution, I think) display of the process. Those were the really expensive models, so often customers opted for the base units that displayed the key metrics using seven-segment displays on the front panel.

To develop, we used Intel MDS-80 development systems (arguably, the first personal computers) running the ISIS Operating System. We would modify the 8080 assembler source code (using 8" floppies), run an assembler on the code, then swap in a linker floppy and create the final image. The end result would get burned onto an EPROM (erasable, programmable read-only-memory for the hardware-challenged). Had a bug in the code? That's where the fun came in.

Debugging on some of these systems (especially those without CRT's) was - uhmmm - entertaining. One of the sharp hardware guys had come up with a device called a CAM box, which strapped into the bus and allowed you to read memory addresses onto a seven-segment display. You could even change the contents of RAM.

Bob Frantz, I believe, was the original (very smart) software designer who had come up with much of the architecture. As an aside, he bequeathed all of his original Dr. Dobb's Journals to me -- which I still have -- upon his retirement. But he had written the system's original real-time OS (pre-emptive, multitasking and fit in perhaps 1K or so of code) and designed much of the architecture. Another sharp developer, Dave H., was also a key contributor. One of the clever aspects of the system involved a call table placed into RAM. The major tasks and services all vectored through the call table.

Using the CAM box, if you placed a C9 (a "return" instruction) in the right place in the call table, you could disable a misbehaving service. Putting a C3 back (a "jump", followed by the address) turned the service back on. You could also write some debugging values to the minimal amount of spare RAM and then inspect the values through the CAM box. Let's just say that debugging through the CAM box on the plant floor was... not quite as smooth a user-experience as using Visual Studio's integrated debugger. But it worked. And, boy, did I learn a lot.

I ended up leaving the company for technology-related reasons. Shortly after I joined, they acquired a division of another company that also developed high-end process control software. Their entire architecture was based on DEC PDP-11's. The new guys convinced management to develop the next generation products using DEC hardware (e.g., MicroVAXes). I wrote memo after memo espousing a PC-based architecture. When I didn't get my way... I resigned and moved on to another company.

The original company is still in business and, to this day, cranks out process control equipment. Albeit as a division of a much larger company. I think, in retrospect, the PC decision impacted their ability to remain independent. But that's just my opinion and I could be wrong.

Amazon.com: Books: Microcomputers and Microprocessors: The 8080, 8085, and Z-80 Programming, Interfacing, and Troubleshooting (3rd Edition)