In the last few weeks of 12th grade, the company that sold the school district the new Interdata Model 7/32 minicomputer was American Business Computers. They were a small band of sleazy operators. (You will find out more later.) One of their contracts was that they had offered to write the software for operating a company that made European car parts. The guy in charge was named Neil. The Interdata computers were 16-bit word size. Pretty obviously, 16 bits will not handle typical commercial transactions. $655.36? Floating point was seven bits of mantissa so that won't work either. NO, BUT YOU COULD ONLY GET SEVEN DIGITS DECIMAL PRECISION WITH THE FLOATING POINT FORMAT.
Even worse, this guy could not write a binary to decimal unpack in assembler language. If you do not recognize "unpack," how do you turn the binary number 01001010 into the ASCII equivalent 74? And how do you pack 74 back to the binary equivalent? Now while many of our contemporaries were drag racing or seeing how many different drugs you could use in a weekend without dying, we were engaged in ferocious competition to see who could write the most efficient pack and unpack subroutines in assembler language. While Neil had persuaded the customer to use hexadecimal part numbers (4EF2, 1C0B), they were somewhat resistant to using hexadecimal for billing customers. "I owe you $EC54?"
Worse: I was later told that this company was Mafia-owned. So were many of their competitors. When they found out that each of them was getting the same "custom" software, the salesman moved to Australia to avoid a contract hit.
Anyway, Neil explained the urgency of being able to do 32-bit arithmetic on a 16-bit machine. Add, subtract, multiply, divide. Add and subtract were easy. Add the lower 16 bits and add the carry bit to the upper 16 bit operation. Subtract was similar. Multiply and divide were not so easy, but with a little help from my friends, problem solved.
He paid me ($80: big money for a poor kid just graduating high school) and offered me a summer job: $80 a week. So I had to drive from Santa Monica to Irvine every day. Gas was about $0.39 a gallon. (About an hour of transit time then; now, retirement age at the end of the first day.)
First he assigned me to a customer named Trinetics in Long Beach. I have no idea what they did; the owner had a thick Southern accent and was a nice enough guy. The only part of the experience I remember was having to run the source code (assembler language) through the assembler (which converted mnemonics like AHM to the machine code 4A). It also resolved variable addresses and symbolic constants, much like #define in C. Then all the individual object modules with references to variables in other modules would be run through the link editor, which would resolve the undefined addresses. The source code was on punched paper tape:
To assemble and link required reading through the source three times (resolving forward references with no temporary storage): about nine hours of waiting for feed errors which sometimes tore the tape.
For reasons that I no longer remember, but probably did not reflect well on the interpersonal skills of a 17 year old introvert with his first job, Neil moved me to the parts manufacturer project. There I tried to clean up the mess that Neil's unique programming techniques had produced. We had promised 4 separate data entry terminals. Neil could not figure out how to read keystrokes, writing them was easy. I remember one part of the puzzle was the Programmable Asynchronous Line Adapter (PASLA). The intent was an interrupt-driven interface. When a keystroke happened it would produce an interrupt, at which point you would input the keystroke. But I did not really understand interrupt service routines yet, so I hacked together a sense-status loop approach: keep reading the status bits until they showed a character available and read it. Terribly inefficient but better than nothing.
It was not a bad month or so. The company served soup for lunch to all its employees and I learned a lot. But the high point of technical learning was in the last month. At the time the idea of Plug Compatible Modules was a dangerous idea: you bought RAM and I/O parts only from the maker of your minicomputer. Then a troublemaker named Keronix started offering PCM RAM at much cheaper prices. Eventually, after upsetting Data General, Keronix mysteriously burned to the ground. (Coincidence, I am sure.)
Anyway, we had bought a 64K Keronix memory card (these were a foot or two square) for one of the Interdata minicomputers. The operating system would not boot. So I was assigned to figure out why. I had a slightly out of date listing of the assembler language of the operating system. But there was no way to use the O/S debugger; it never got that far.
What I did: minicomputers had front panels through which you could read and write memory locations. As breakpoints, I would insert the one word BS * (branch short to your current address). I worked my way through the O/S from where control was given by the boot process until I found the guilty party, removing that BS * and putting the original instruction back in, until I found the instruction that caused the failure.
To read from the hard disk, the O/S would set up the DMA so that when the OC (Output Command) executed, it would read the requested sectors from the disk into the requested RAM. At which point, bit 13 in every word in the first 16K of RAM turned off! The instruction after the OC was now an illegal instruction. Obediently the illegal instruction trap fired. The first instruction of every interrupt service routine including this one was DI (Disable Interrupts). But with bit 13 off, that first instruction was now illegal, and off it went, chasing its own tail.
The Keronix RAM was okay; the Interdata disk controller was out of spec; the DMA request was turning off bit 13.
I knew people in our high school who also drag raced or participated in extreme pharmacology. One did both, until his van caught fire and burned up.
ReplyDelete