d
i
g
i
t
a
l
digital equipment corporation · maynard, massachusetts
MEMORY ADDRESS
EMA
RUN

Laurie Forbes PDP-8 Memories

I worked as a engineer/programmer for Mobil Oil Canada beginning in 1969. At the time, the company's US owner (Mobil Oil Corp) had a number of US oil & gas field automation projects underway that were based on SCADA (Supervisory Control and Data Acquisition) this being driven by centralized IBM 1620 computers (one central computer would control several oil/gas fields with communication being handled by dedicated phone lines). Our situation in Alberta was a bit different in that distances from the central office to the oil/gas fields were large and communication line rental was expensive and not reliable in the far flung reaches.

Our solution was to place dedicated SCADA computers at each field location and, at the time, the then available PDP-8i seemed to be a good solution. So, off we jumped into the relative unknown (at least to us) and purchased a PDP-8i with 8K of core memory, a 32K DF32 fixed-head disk drive and an ASR-33 teletype.

At the time there was no RTOS (Real Time Operating System) available for the PDP-8s so we decided to write our own. We could not even use the Fortran compiler that was available as it had IIRC no provisions for a real time clock or recovering automatically from a power failure. Assembler it was then and we wrote pretty much everything ourselves except the FPP (Floating Point Package) software and ODT (Octal Debugging Technique).

After a while as our program repertoire grew we expanded our systems to 12K memory, a second DF32, then RF08 fixed hard drives (with 256K), a high speed paper tape reader, replaced the fixed head drives with the RK05 cartridge drives (1.2 MB) and a DecWriter (keyboard and dot matrix printer).

Core memory was allocated roughly as field 0 for the OS including interrupt handler and the FPP. Field 1 was for apps and Field 2 contained core resident data plus ODT. The hard drives contained both one and two-D data arrays for bit, integer and floating point numbers plus the application programs and the programming support system OS8 (one could configure OS8 to use only a portion of the disk space).

All-in-all everything went pretty well - the PDPs had more than ample computing power for the application and were very cost effective for the time. The only big issue however was with hardware reliability.

The 8i was made up of a very large number of small circuit boards which were connected by a large wiring back plane containing a myriad of mechanical wiring connections (wire wrapped on pins only, no solder). Our first 8i was plagued by intermittent, random program halts which took a long time to resolve and was particularly troublesome as the 8s were located in remote field locations. We and DEC tried valiantly to find the problem and it became an issue of hardware vs software. It eventually occurred to me that a program halt with other than a HLT or equivalent instruction in the memory buffer, which is what we were seeing, must be a hardware issue (I was a little surprised at the time that it took a bit of persuasion to convince the DEC techs that that was the case). I had also noted that one of these halts occurred when the program was executing an ISZ wait loop so that tended to point to an ISZ or JMP execution issue. Anyhow, by running an ISZ diagnostic program whilst vibrating the circuit cards by running the end of a pencil over the exposed ends, a similar halt finally occurred with a DEC tech on-site. The tech then replaced a card related to the ISZ execution circuitry and the problem was resolved!

The fixed head disk drives were also a source of problems in that reoccurring persistent read errors would sometimes halt program execution. The main issue lay with the fact that removing AC power from the drives resulted in the read/write heads contacting and scraping the surface of the platter before the platter stopped rotating. The fix was to replace the platter but it happened too frequently to be acceptable so we were more than eager to replace the fixed head drives with the movable head RK05s which did not have the problem (and had much greater, and removable, storage capacity. Going to the 8E CPU version was also very helpful from the reliability standpoint.

Not to be too negative I hope but another problem that bugged us occasionally was the paper tape reader(s) in that they had no read error checking ability. On a couple of occasions we had a single character dropped when reading a source tape that happened to change one statement label to another thus introducing an undetected bug into an otherwise tested program. In another instance, an entire statement was missing (one that restored the accumulator on exit from the interrupt handler) which resulted in occasional strange computational errors that took a long time to track down.

All-in-all though the PDP-8s (we had five or six in all) were considered to be a success. They were kept installed until around 1989 at which point much more capable processors were commonly available (and software which did not require as much coding or assembler coding in particular).

A couple of other software things we undertook included programming a fixed head disk emulator for use when we migrated to the moving head RK05s. This was necessary as we had a great deal of software that made use of the fixed head disk's ability to address its content down to the word level whereas the RK05s could only address down to a 256 word block level IIRC. The procedure was to read the appropriate block into core and extract the relevant single or few words of data. For disk writes, the block would be read in, the relevant single or few words would be modified and the block re-written to the disk. It worked well and I was surprised at how fast the data reads or writes were compared to the fixed head drives (it was a bit slower but not significantly so).

Another thing that might be useful to others was modifying the DEC SABR assembler (normally used as the second pass to the Fortran compiler) to make use only of its automatic page escape capability. This was a great time saver as it removed the need to shuffle existing code from one page to another to make room for code additions, especially for additions near the start of a large program. The assembler then acted essentially the same as the PAL8 but with auto-paging built in.

I look back on those days with a lot of nostalgia and would much like to have an actual 8E with a RK05 hard drive or, a good Windows emulator similar to the one apparently available for Apple Macs.

Back to memories page



Feel free to contact me, David Gesswein djg@pdp8online.com with any questions, comments on the web site, or if you have related equipment, documentation, software etc. you are willing to part with.  I am interested in anything PDP-8 related, computers, peripherals used with them, DEC or third party, or documentation. 

PDP-8 Home Page   PDP-8 Site Map   PDP-8 Site Search