Computer History

or how I learned to love computers

My first personal computer was a Color Genie. After playing around a bit with it and of course writing some BASIC programs, it was soon boring. Therefore I wrote a small program that peeked into the system ROM and displayed the contents of it. I then disassembled  the whole system ROM by pencil & pater, to get a clue how this thing actually did worked. But that was actually some time after I came into contact with computers.

In 1976 I started studying chemistry at the Vienna University. One of my first lessons I took was something like "Using computers for measurements". The computer used there was (very likely) the HP 2114 mini computer. I can't remember what the first program we wrote actually did, but I remember how we composed it: write down the assembler code on paper, then translate the assembly into octal notation, then turn on or off the 16 switches on the front panel and put in that code, then press the NEXT button...

While this sounds a bit boring, it was quite impressive to us. But the machine also had a tape reader and a TTY attached to it. The next program we wrote was a bigger project: we converted an oscilloscope into a computer screen by connecting the oscilloscope with a D/A converter and deflecting the beam in such a way, well that it did show some ASCII text. This time we typed our program with the TTY onto a paper tape, fed the assembler tape into the 2114, then our program tape, run and debug it, started over, with occasional fixes of torn tapes.

Not long after that I had a small job at the university: I had to write some FORTRAN programs that should make figures and 3D diagrams out of certain physico-chemical measurement data. We didn't have a capable computer at the chemistry department at that time (and no there wasn't something like an internet connection either), therefore I had to walk  to the informatic institute and do the programming there. This went like this: punch the measurement data and the program, put program control cards at appropriate locations, put that stack of card into the card feeder and ... wait. The operator occasionally came along and starts the card feeder, so your job is scheduled to run sometimes on the computer, which was a CDC Cyber 170 (IIRC) running the NOS/BE operating system. After a few quarters of an hour, the result of your computation was printed at the line printer. Then the operator came along again separated the pile of papers into user jobs and sorted the jobs into a drawer, where then I eventually found (under "T") my result page stating some syntax error in line 477 (typically a typo). Do it again Leo.

While that was really time consuming, the program worked and I eventually got the pemission to use one of the few interactive terminals attached to the CDC. Wow, the edit-compile-run cycles were reduced from hours to the 10 minutes region, despite of the fact that the editor was some ancient variant of ed(1):

$ ed the_file
21
l
line 3$
2l
line 2$
i
line 1.5
.
1,4l
line 1$
line 1.5$
line 2$
line 3$
w
30
q

At that time we also started building our own "personal" computers at the chemical department. These were either Intel 8085 or Zilog Z80 based PCB computers running under the CP/M operating system. For mass storage we had 8" and 5 1/4" floppies first, then we used the brand new SONY 3 1/2" floppies, which we formatted up to 1.8 MByte. This was also the time when we switched to CP/M 3 and when we got the budget to buy the first hard drive. It was a full-height (5"), heavy brick able to store the huge amount of 10 MBytes on it. It came along with a sheet of printed paper with three subroutines (in 8080 assembly) on it: how to read, write, and format a sector of the disc. I integrated these routines into the CP/M 3 "kernel" so we had a nice PC with a hard disc (which BTW we never managed to fill up totally).

A bit later, we plugged in another 64 KByte RAM card into this PC and I wrote a LRU-based disc cache to use this memory. This gave a nice speedup for all floppy and hard-disc accesses.

And now for something completely different: I eventually stopped studying chemistry and switched over to just hacking computers. One of the early projects was to program a huge machinery; a round table with 12 stations on it that step by step put together a small relay like that one shown here. This machine was controlled mainly by one PLC, which I wrote the program for. Wow, that was fun, when you see your program cause all these claws move around, up and down, forth and back, putting the half-built relay from the inner to the outer construction circle. It was less fun, though, when due to one programming error half of the tools where down, while the table circled 1/12th clock-wise to the next production cycle. Well, the construction guys did put in dummy tools then for the next tests ;-)

When that machine was eventually finished, we started adjusting and testing it at the customer site. After a lot of work and debugging, it started producing relays nicely, but was too slow, not quite in the specifications the customer has demanded The problem was that due to some not-quite or almost matching raw materials, a lot of half-created parts moved around the table two rounds and then finally got thrown away, which was a) some waste of raw parts and b) it did block a lot of the 2 x 12 production slots for creating working relays. Therefore I wrote a simulation program (in Turbo PASCAL), which did show, how to improve the machine. E.g. an empty relay casing could be reused in the next cycle instead of throwing it away as unusable waste. After some reprogramming of the machine and more adjustments, we eventually got the production cycle from 3.5 s down to 2.x seconds and the customer was happy. We too.

Another project I wrote most of the software for, was a liquid-nitrogen-based refrigerator. I wrote the low-level parts, eg. how to run the LCD or the small keyboard and I wrote the temperature control code. The latter was really interesting. The user could program that frig and say: cool down to -50 C by 10 C per minute, hold that temperature for 10 minutes, then go down to -90 C at another rate and keep that temperature (until the nitrogen was finished at least). I managed to implement a PASCAL-based PID controller, which, after calibration, was able to hold a given constant temperature within some 0.5 C, but more impressively, when cooling down to some target temperature did not overshoot more than 2 C.

In the late 80s I started writing a stock management program for a company, which has subsidiaries all over eastern europe. The program should also be able to write some offers too, but that was a really demanding task. All these countries had totally different accouting terms and there wasn't just one per country. I decided that such a program would need a lot more flexibility. Therefore I first wrote a small computer language and an interpreter for it. Around that I created screen and printer masks, which had access to that interpreter. With this approach I had a small C program with the interpreter, some data base, screen, and printer code and everything else configurable and customizable as extern text files. This approach evolved really great. Improving the program and schooling EDV staff all over eastern Europe filled up the next +10 years of my life.

And then was Parrot.