原创 How it used to be: Programming (and debugging) microprocessors (Part 1)

Note: This "How it used to be" story is told by Aubrey Kagan, who is a professional engineer with a BSEE from the Technion-Israel Institute of Technology and an MBA from the University of the Witwatersrand. Aubrey is engineering manager at Emphatec, a Toronto-based design house of industrial control interfaces and switch-mode power supplies. In addition to writing several articles for Circuit Cellar and having ideas published in EDN and Electronic Design, Aubrey is the author of Excel by Example: A Microsoft Excel Cookbook for Electronics Engineers (Newnes, 2004).

I cut my teeth on the RCA COSMAC 1802 microprocessor. In 1977 I was working for Racal (a British telecommunications manufacturer) and we needed a CMOS processor for a hand held radio set. There was only one other alternative – the Intersil IM6100 12bit micro built around the DEC PDP8 minicomputer instruction set. 8 bits was much easier than 12 from the perspective of byte wide memories and peripherals. Actually there were precious few of either, but those that existed were either 4 or 8 bits. At the time there was an article in Popular Electronics to build the "Elf" micro development board. Using this as a base I created a "development system" designed around several single Eurocards in a 19" rack. The front panel had the luxury of an address bus and data display in hexadecimal, rather than a binary display with many LEDs. The keyboard had toggle switches rather than a keypad. It was possible to dissociate the micro from the bus and enter an address and data directly into memory. Aside from this, the only debug feature was the ability to halt and single step through the program. There was no breakpoint capability – the equivalent was only possible by inserting a "GOTO HERE" loop in the program. I don't recall how I did it, but I did manage to implement a 1K program that included reading and sending code over a 150-baud modem, interfacing to a Baudot teletype, programming a 32x8 PROM with a unit identity and activating several outputs.

The author "Then" (left) and "Now" (right)

I had a blank programming sheet template with allocated spaces for the mnemonics, op-codes and comments. After the flow chart was created, I would write the program in mnemonics and then translate it into op-codes, which was particularly difficult when working with relative jumps. Once coded into hex format, I would then enter the code via the toggle switches into RAM and debug. When a bug presented itself, you didn't want to edit and re-enter the code, so you inserted a "GOTO" at the appropriate place and then inserted the corrected version of the code somewhere else. I developed the habit of leaving gaps between subroutines and allocating fixed addresses to the subroutines to allow me to tack the corrected part later without having to recalculate all the jumps. The RAM was not battery backed up, so any power fluctuation would result in keying in the data afresh. Fortunately, the electricity supply in South Africa back then was a lot more consistent than it is now, and I think that only happened once.

At that time there were no CMOS PROMS (erasable or otherwise) and so the design used a 1K x 8 bipolar PROM for the program storage and loaded bits of the program into a pair of four-bit 256B CMOS RAMs. Power to the PROM was only applied when data was fetched. I don't know why we decided to make our own programmer, but we did. There was no connection to allow me to download data from the development system to the programmer – this had to be done manually as well.

Testing the product had to be performed at elevated temperatures. After a while the unit started exhibiting some very unusual behaviour. It took me some time to try and understand the problem. At some point I had read a report that the fuses on the PROM could regrow, but dismissed that as one of those things that happen once in a million years. In frustration I read back the PROM and compared it byte by byte with the handwritten listing. Sure enough the fuse in one byte had re-grown. And they say that those were the good old days!

In 1979 I succumbed to the entrepreneurial bug and started my own business with a partner. Our idea was to develop a desktop computer running the CP/M operating system. My partner (marketing and mechanical design) was already planning for providing the whole package – hardware and enterprise software. I started designing around an Intel SDK85 (see image below), which provided a monitor in addition to the LED display and was thus a significantly improvement over my original 1802 design. When working with CMOS the easiest test for correct operation was simply to put your finger on the IC. If there was any detectable temperature there was a problem. The 8085 was an N-MOS device, and I remember thinking as I sucked the burn on my finger that something was definitely wrong. The SDK85 still required program entry by keypad and I needed something better.

Intel SDK85

At the time, the Z80 was all the rage and so I bought a single board development kit from SGS-Ates (an Italian outfit now subsumed into ST... which was a French manufacturer Thomson... which acquired Mostek as well). The kit had a monitor and drivers to connect to a teletype and a high speed paper tape reader. This was living. The monitor would allow you to load the editor from paper tape. You would then enter your program, edit it and list it if so desired. When complete, you could dump your program out onto paper tape. Since the teletype worked at 110 baud, the benefits of a high speed reader quickly became obvious and I acquired and figured out how to connect one.

Documentation wasn't great in those days either! Although direct telephone dialling was possible, it was terribly expensive and I was thoroughly disenchanted when tech support in England was unable to give any help at all.

Once the program was on paper tape it was time to assemble it (this was in assembler only). Firstly you had to read the assembler program from paper tape into the memory. Assemblers in those days were referred to as two-pass or three-pass. This meant that your program had to be read two or three times to arrive at the desired object code. This was necessary to create a cross address table in order to calculate the jumps etc. As I recall mine was a two-pass assembler. So, at the prompt of the assembler, you would run your assembler code through the reader, rewind the paper tape, and then wait for the second prompt and do it all again.

The output would be a program listing and a paper tape containing the object code. There was no possibility for module development to reduce the length of the paper tape, although it was possible to enable and disable portions of the listing through in-line switches. A twenty-page listing at 110 baud can be very time-consuming. The paper used for the listing was friction feed and came as a continuous non-perforated roll. Although the listing was formatted, you still had to cut each sheet with a ruler and then bind it either with a staple or with a clasp.