Sometimes Mistakes Multiply

My first job out of college in 1982 was with a small Ottawa company called Cybernex.  At their zenith, they had about 200 employees.  Cybernex manufactured plug-compatible video terminals.   In those days, you had to buy IBM terminals to plug into your IBM mainframe, or Honeywell terminals for your Honeywell mainframe (and don’t forget Burroughs, DEC, Wang, and the other old dogs).  Cybernex made compatible terminals for these large systems that cost a lot less than the manufacturer’s.  Canada Post and other large government orgs loved our prices.

They had a (very) small IT department, and I was hired as a junior programmer to work on internal business systems.  The engineering side of the house had just transitioned their base technology from TTL to microprocessor-based terminals, and realized they could just as easily make a microcomputer, so they did that too.  And in an early case of eating one’s own dogfood, they decided to build their order entry, purchasing, and other business systems on it.  In that day, business software was available only on mainframes and mini’s, and was expensive.

A Motorola 6800 powered it this microcomputer, dubbed the LC-2, and they created their own operating system and programming language:  Cymon and Cybol I believe they were called.  Cybol was BASIC-like, except that it was compiled, rather than interpreted.  This language had one annoying behavior that never got fixed:  If you didn’t declare a string variable before using it, the compiler would assume it was an 16-bit integer and automatically allocate 2 bytes of memory storage for it, along with a branch instruction to jump over those two bytes.  When the program ran, and 50 bytes of string data was moved into it, it would over-write the code that followed it.  In the 6800 world (no protected memory), code and data were freely intermixed in memory.  Since some of the program memory had been overwritten with 48 bytes of data, the 6800 would blindly start executing the data bytes as though they were instruction bytes, casually ignoring any instruction codes that were illegal or undefined.  The result was a total system crash, with a processor wildly issuing reads and writes to random memory locations.

The LC-2 computer had on-board hardware custom designed to control the floppy drive, but his  hardware had a minor oversight:  Writing to the floppy drives was done by writing to specific hard-wired memory addresses, and there were no mechanisms protecting access to those addresses from accidental writes.  Inevitably, when your program and operating system crashed, random writes to these addresses occurred, which activated the floppy drives and wrote gibberish on your floppy drives.  Of course, the operating system was on one floppy, and your program code and data on the other.  Us programmers lost many, many hours as our disks were ruined almost daily by these occurrences.

Lesson:  One engineering oversight is often innocuous.  But if you don’t clean it up, another may cozy up beside it, turning the pair into a potent pain point.