标签: minicomputer

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.    

  The market for computers remained relatively small till the PDP-8 brought prices to a more reasonable level, but the match of minis and ICs caused costs to plummet. By the late 1960s everyone was building computers. Xerox. Raytheon (their 704 was possibly the ugliest computer ever built). Interdata. Multidata. Computer Automation. General Automation. Varian. SDS. Xerox. A complete list would fill a page. Minis created a new niche: the embedded system, though that name didn't surface for many years. Labs found that a small machine was perfect for controlling instrumentation, and you'd often find a rack with a built-in mini that was part of an experimenter's equipment.   The PDP-8/E was typical. Introduced in 1970, this 12bit machine cost $6,500 ($38k today). Instead of hundreds of flip chips, the machine used a few large PCBs with gobs of ICs to cut down on interconnects. Circuit density was just awful compared with today's densities. The technology of the time was small scale ICs that contained a couple of flip flops or a few gates, and medium scale integration. An example of the latter is the 74181 ALU, which performed simple math and logic on a pair of four bit operands. Amazingly, TI still sells the military version of this part. It was used in many minicomputers, such as Data General's Nova line and DEC's seminal PDP-11.   The PDP-11 debuted in 1970 for about $11k with 4k words of core memory. Those who wanted a hard disk shelled out more: a 256KW disk with controller ran an extra $14k ($82k today). Today's $100 terabyte drive would have cost the best part of $100 million.   Experienced programmers were immediately smitten with the PDP-11's rich set of addressing modes and completely orthogonal instruction set. Most prior, and too many subsequent, instruction set architectures were constrained by the costs and complexity of the hardware, and were awkward and full of special cases. A decade later IBM incensed many by selecting the 8088, whose instruction set was a mess, over the orthogonal 68000 which in many ways imitated the PDP-11. Around 1990 I traded a case of beer for a PDP-11/70, but eventually was unable to even give it away.   Minicomputers were used in embedded systems even into the 1980s. We put a PDP-11 in a steel mill in 1983. It was sealed in an explosion-proof cabinet and interacted with Z80 processors. The installers had for reasons unknown left a hole in the top of the cabinet. A window in the steel door let operators see the machine's controls and displays. I got a panicked 3 a.m. call one morning—someone had cut a water line in the ceiling. Not only were the computer's lights showing through the window—so was the water level. All of the electronics were submerged. I immediately told them the warranty was void, but over the course of weeks they dried out the boards and got it working again.   I mentioned Data General: they were probably the second most successful mini vendor. Their Nova was a 16bit design introduced a year before the PDP-11, and it was a pretty typical machine in that the instruction set was designed to keep the hardware costs down. A bare-bones unit with no memory ran about $4k—lots less than DEC's offerings. In fact, early versions used a single 74181 ALU with data fed through it a nibble at a time. The circuit boards were 15" x 15", just enormous, populated with a sea of mostly 14- and 16-pin DIP packages. The boards were typically two layers, and often had hand-strung wires where the layout people couldn't get a track across the board. The Nova was a 16bit machine, but peculiar as it could only address 32 KB. Bit 15, if set, meant the data was an indirect address (in modern parlance, a pointer). It was possible to cause the thing to indirect forever.   Before minis, few computers had a production run of even 100 (IBM's 360 was a notable exception). Some minicomputers, though, had were manufactured in the tens of thousands. Those quantities would look laughable when the microprocessor started the modern era of electronics.