标签: microcomputer

My degree course was of a kind known as a sandwich course (referred to as a "co-op" in America), which meant that we spent a year in college, then six months working for a company (whatever company you could persuade to take you on), then a year back in college, then another six months out in the field, then a final year at the university. I also noted that my second industrial placement was at the Research and Development centre for a large glass manufacturer. This second placement occurred around 1979, when microprocessors and microcomputers were still relatively new on the scene. To put things into some sort of perspective, one of the computers we used at the university was a humongous analogue beast composed of voltage/current summers (adders and subtractors), amplifiers (multipliers and dividers), integrators, differentiators, and so forth. In order to make this work, we had to use flying leads to connect different functional units together, turn knobs and twiddle dials, and hop up and down on one leg while whistling the national anthem ... well, maybe not, but it sometimes felt like it.   An analogue computer (no, that's NOT me :-)   The only digital computer we had access to at that time was a honking mainframe that lived in its own building. We captured our programs on decks of punched cards using teletype machines, and then we hand carried them across to the computer building, handed them in, and were told something like "Come back next Wednesday." And when you did return, it was only to be told that there was a syntax error and you'd missed a comma, and the whole thing started again ... it took at least a semester to get even the simplest program to run. (Ah, the good old days :-) But we digress... I had been at the RD centre for only a week or so when my supervisor took me to one side and asked if I knew anything about computers (I later discovered that most of the electronics in a glass factory at that time was either analogue or relay-based digital sequencing type "stuff"). It turned out that someone had ordered a Texas 9000 (or was it a 9900?) microcomputer system, which had just arrived. The problem was that the person who had ordered this little rascal had subsequently accepted a position with another company, and no one else in the RD centre had ever seen a microcomputer before. The bottom line was that they put me in a room with the microcomputer and a manual and left me to it. My instructions were (a) learn how to use the computer and (b) come up with something useful for it to do so that they could justify having purchased it in the first place. What a great opportunity!!! The first step was to learn how to use the computer, which had to be programmed in assembly language (this was the first time I'd been exposed to assembly language, all I knew at that time was FORTRAN on the mainframe). I still remember the feeling of triumph when I managed to get my first "Hello World" type program to work. Once I had mastered "the beast", the next step was to think of something to do with it. The folks at the RD centre already had a laser, and they allowed me to purchase a diode-array camera. I think the resolution of the camera was either 32 x 32 or 64 x 64 pixels; whatever it was, it was pathetic by today's standards, but it really great for the time. I no longer remember how I did it (some simple cable interface – perhaps it was even RS-232), but it was possible to use the microcomputer to instruct the camera to capture (latch) whatever image was currently being detected by the sensor, and to then read the output from the sensor byte-by-byte. My idea was to bounce the laser off the liquid glass as it flowed in channels from the furnace to the bottle-forming machines, and to use the diode array camera to detect the reflected laser beam and use this to calculate the level of the glass (it's not like you can use a float or something... in fact, I'm not sure how they used to do it). But my real triumph was using the camera-microcomputer combo to read the numbers on the bottom of the glass bottles as they zipped down a conveyer belt. There was already some way to detect cracks in the body of the bottles – the trick was to be able to determine which glass-forming machine a damaged bottle had come from based on the number on its bottom. This was actually a non-trivial task, because the numbers were formed by raising the level of the glass on the underside of the bottle, which was illuminated by two light sources aimed at 90 degrees from each other. The thing was that, depending on the orientation (rotation) of the bottle, different faces of the raised numbers would be illuminated. So first I had to detect the bottle going by and trigger the camera to take a snapshot. Next I had to identify the facets forming the number from random "noisy" areas of the glass, calculate the "centre-of-gravity" of the number, rotate everything around until it was "vertical" and then identify it – all before the next bottle shot past. Actually, when I consider how little I knew in those days, I now realise how amazing it was that I got any of this to work at all. Fortunately, I had no idea as to just how out of my depth I was, so I beavered away and eventually got it all working. I was dancing my happy dance that day, let me tell you! Apart from the (not insignificant) boost to my confidence, this experience was really important to me because (a) I got a chance to work with a microcomputer before a lot of other folks even saw one, (b) I learned an assembly language and (b) I discovered that I was actually pretty good at assembly-level programming (I know that it's not very modest of me to say so, but it's true). I also think I was really lucky to be learning all this stuff at that time when memory was so limited and processor clocks speeds were so low, because you had to use all sorts of tricks to minimise your memory usage and wring the last drop of performance out of your programs. All of these tricks and techniques have served me well over the years in all sorts of esoteric applications.  

Note: Here's a "How it used to be" story as told by Aubrey Kagan, 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 wrote Excel by Example: A Microsoft Excel Cookbook for Electronics Engineers (Newnes, 2004). In the 70s and 80s (and even the 90s if you include South Africa itself) the news in Southern Africa was flooded with the acronyms of dozens of liberation groups in colonial Africa. In 1980, when South Africa was engaged in a not-so-secret incursion into Angola, there were three contenders that captured the public's attention – UNITA, MPLA and FNLA. So when I attended a seminar on programmable logic and was introduced to the FPLA and PAL, I guess I could be forgiven for thinking that I had stumbled into a news conference or political meeting. The Field Programmable Logic Array (FPLA) was a Signetics product and was known only by name in South Africa. The Programmable Array Logic (PAL) from Monolithic Memories (MMI) was marketed at the time by a local distributor called Radiokom who was hosting the seminar. The databook that I got at the seminar (I still have an electronic copy) included all of MMI's products and the PAL only took up one section. There were only 13 products in the family. All were in 20 pin 0.3" DIL packages. There were only 3 with registered outputs, the rest were different combinations of AND/OR gates. The PALS were bipolar (technologically, not psychologically speaking) and were only superior to TTL in that you could replace 2-3 TTL packages with one PAL. These were humble beginnings. At the time I was designing a memory storage card for the Intel iSBX bus (a mezzanine bus on a Multibus card – I am sure there is a "How It Was" to be written about that). The board was constrained by specification to about 3"x 2" and so space was at a premium, hence my choice of PAL despite the hefty current consumption. The devices had programmable fuses, but once a fuse was programmed it could never be "unprogrammed".   The author "Then" (left) and "Now" (right)   At the time, MMI had already defined a programming language called PALASM. The 1980 catalog only introduces it. The 1981 catalog describes it as a program written in FORTRAN. At the time there was no standard host on which to run the software. The IBM PC only came out in 1981. There was a quasi-standard operating system called CP/M, but the floppy disks could only be interchanged if the floppy disk drive was an 8" single density (360KB if I remember) and maybe it was even restricted to IBM drives. MMI said there was a list of machines, but it certainly wasn't presented in the manual. Radiokom also distributed a machine from South West Technical Products (SWTPC) , but it couldn't run PALASM. So we were left to do this manually as described in the MMI books. (I see from Wikipedia that the programmer from Structured Design actually had PALASM embedded.) First you would photocopy (we actually did have photocopiers in those days, but often they used to smell of some very toxic chemicals and were hard to write on with ball point pen) the logic diagram of the PAL that you wanted to use. First step was to mark the I/O names. Then you would figure out either using logic equations or by inspection which connections you wanted and mark them with an "X" as you can see in Figure 1. The "X" indicated that the fuse was intact; all the other fused were to be blown. Each small AND gate actually had multiple inputs, so that multiple "X"s on the same input row actually represented these multiple inputs and not that the inputs were connected together. For instance look at row (Product Term) 24 of figure 1 .     Figure 1 You may notice an "X" in some of the AND gates (look at the AND gate on product term 7 in figure 1 ). Since each input consists of a signal and its complement they cancel themselves on the AND gate. Where no input to an AND gate is assigned, the output it 0 and does not affect the following OR gate. The X in the body of the AND gate is a short-form notation to indicate that all the fuses on the product term are intact. The next step was to photocopy the template of the fuse map as shown in figure 2 . Any intact fuse would show up as an "L" and a blown fuse as an "H". You had to pay attention since the order of the product terms in the template was not the same as the order on the logic diagram.     Figure 2 Although MMI provided details on how to program the devices, there was a list of five approved programmer manufacturers. I was only aware of two. There was a universal programmer for Data I/O which cost and arm, a leg and a lung and one from Pro-Log. (Pro-Log was also responsible for the STD microcomputer bus, I believe still used today in expanded form by companies like Ziatech. Actually I remember an article from Pro-Log that dismissed the 8048 specifically and single chip micros in general as being of limited use. I wish I still had it.). According to the MMI manual the programmers used a paper tape input to load the data, but with no method of generating the paper tape this was a moot point. The Pro-Log programmer was housed in a large black attaché case making it transportable. As I recall the entry was not by keypad, but by toggle switches, but maybe I am wrong. Probably not coincidentally, Radiokom was the distributor of Pro-Log and so I used their programmer to program the device. I remember spending several hours entering and correcting the data for this simple device. Incidentally, similar to the EPROM/PROM/ROM marketplace, the PAL was aimed at a development and low volume marketplace. Once the design was finalized it was expected that the design be committed to a HAL- a mask programmed Hard Array Logic device. Now that I think about it, I realize quite how influential the IBM PC was in determining the approach we take today to any kind of electronic development. I think its influence here must exceed its influence over what we do at home or even business using the PC. I remember reading that Intel believed that the development system market was not cost-sensitive and they certainly priced their development tools accordingly. The PC not only standardized the user interface and the inter device communications (RS232 and parallel port), but also drove the entry level costs for development right down. Over the next 5 or 6 years the changes in the programmable logic market were rapid and rather fuzzy in my memory. New manufacturers popped up and densities increased along with revised architectures. Altera introduced static CMOS devices that drew very little power and were erasable. Lattice was similar, but despite being called CMOS drew quite a bit of power on its GAL devices. ICT produced a variations in EEPROM. Each PLD (although I don't think that acronym was used till much later) manufacturer had their own user interface and programming language, but always hosted on the PC. PALASM was still quite popular and could be used in some cases for other manufacturer's products. Data I/O introduced their own programming language called Abel, and there was another universal contender called CUPL. There was the EP300 and EP600 from Altera and the 22V10 from AMD (and then others). Xilinx and Actel popped up in there somewhere A number of the big players tried to get into the market. Intel (I think they acted as the foundry for Altera) tried. TI had a shot. National Semiconductor second sourced Lattice parts. MMI was taken over by AMD which spun the result of as Vantis and then absorbed by Lattice.