Migrant Software Worker: A Technical Memoir of the Beginning of the PC EraThe primary focus would be my career as a software engineer, which was somewhat unusual. I was writing telemetry software for the Voyager mission at Jet Propulsion Labs when I was 18, and I worked for several startups in the 1980s and 1990s.
Being a technical memoir also avoids the danger of too much self-revealing. I am reminded of P.J. O'Rourke's remark that if you accuse a Hollywood celebrity of being a drunken, drug-addicted pervert, his response would be, "Thank you for reading my autobiography."
Of course, to make it interesting requires explaining technologies that are largely hidden from modern developers, such as a problem at one small company where we were installing one of the first of the plug-compatible memory cards for Interdata minicomputers. With the memory card installed, the operating system would not boot. I had an assembly language listing of a slightly older version of the operating system. My only debugging tool was inserting a JSR * (jump relative to self) instruction through the front console into various memory addresses and seeing if I got that far. I keep inserting this further and further back. I finally demonstrated that the failure was when the OC (Output Command) instruction started the DMA operation that loaded data from the hard disk into RAM. After that executed, bit 13 of every word in the first 32 KB (yes, that's KB) was turned off. The next instruction after the OC was now an illegal instruction. The processor therefore performed an Illegal Instruction interrupt. The first instruction of the Illegal Instruction interrupt service routine (ISR) was DI (disable interrupts) but with bit 13 off, it was an illegal instruction, and so the the Illegal Instruction interrupt happens again, and the ISR again throws the exception.
After much analysis with an oscilloscope by our hardware engineer, it turned out the memory card was fine. Interdata's hard disk controller was not conformant to their own specifications. It was missing a data line on the data bus; hence the DMA turned off bit 13.
The guy that ran this company also could not figure out how to write an assembly language subroutine to unpack binary to decimal. He had persuaded the customer to use hexadecimal part numbers; he hired me because he couldn't use this approach for prices.
Have you seen this yet http://www.catb.org/esr/faqs/things-every-hacker-once-knew/
ReplyDeletei'd be interested in reading it.
ReplyDeleteThose were the days!
ReplyDeleteWhile programming on the GE'635 in 1969, I noticed that my program was crashing unexpectedly. I tracked it down to one instruction that, when executed using an unusual addressing mode, would sometimes pic a bit or two in an "indirect tally word." It turns out that the instruction had been added as a field modification, and the wiring was routed in a way that caused to much coupling between wires.
We had another problem where the machine would just crash, hard. It happened any time someone submitted a job without enough memory specified.
The engineer who fixed that, ironically nicknamed "Octal Fox" since he was missing two fingers, determined that when the job was swapped into memory, and part of it hit the memory protection, the I/O Controller would flash all three status lights (a code 7 error). That would glitch the power supply causing things to go nuts.
On my first day on the job as a systems programmer at Hughes Aircraft, I ran a little seven card assembly language program to see if the field engineer or myself was right about a subtle feature. The program started, and the machine just stopped dead. This was a big machine - Hughes' only scientific/engineering computer - and it just stopped running. It didn't crash, it froze. That meant that my guess about what the program would do was correct. But, doing it in the middle of the day was perhaps not the best thing to do.