Our good friend G.R.G. has shared some fun stories from his decades of working in the industry. Insecurity Doors, Mystery of the High Test Scores, and Twelve on a Line are among my favorites. Today, G.R.G. takes us back with a neat anecdote from the goold ol' days of the 8080 ...

Not too long ago, there was mainly just one operating system for 8080-based microcomputers: CP/M. It didn’t totally suck -- it could store files, load code into memory, run code in memory -- really, what more could one possibly need from an operating system? Well, when the 8086 CPU came out, it presented a small problem: CP/M (and all of the wonderful CP/M applications) could not run. Different CPU architectures, don't you know? In a brain flash, I thought: Why don't I create an 8080-emulator for the 8086! It could then boot to CP/M and run all of that wonderful CP/M software!

At the time, "all that wonderful CP/M software" referred to WordStar (ugh!) and DataStar (double ugh!). Granted, there was already a perfectly capable 8086 operating system called CTOS. And that operating system was pretty advanced for its day with features like a Screen Editor, Copy/Cut & Paste, Unlimited Undo, Transparent Local Area Networking, Forms Interface for Programs, and so many more. Booting to CP/M -- the operating system with such great features as Storing Files and Running Code -- was like pulling a manure spreader with a Cadillac.

But, don't you know, with out CP/M, you don't get any of that *wonderful* CP/M software. Of course, after just a moment's reflection, said software was only wonderful in comparison to writing on the sidewalk with the end of a burnt stick. However, everyone seemed to be blinded by the superiority of WordStar for CP/M, so I went ahead and started writing the 8080-emulator.

Speed was essential, as the 8080 had a variable clock speed (1 to 4 MHz) and the 8086 had a fixed, 4MHz clock. In addition, the 8086 was microcoded, meaning that it needed a good half dozen clock cycles to run many instructions. The 8080 only needed one or two. So, right out of the gate, the emulator was bound to be slower than what it's emulating. The idea was that, in the long run, the *humungous* 14MB harddrive would more than make up for the slowness of CP/M floppies.

Week after week, hack after hack, I finally got the emulator working! Well, almost. CP/M started booting for about five seconds and then took a dive. Pretty good, but no cigar. Worse still, I had absolutely no idea what was wrong. I poured over my code, line by line, and just couldn't figure it out. I figured it had to do something with the CPU flags register.

Stepping through the assembly code offered nothing but a bad headache. The best way to solve the crashing, I figured, was to write a logfile with every emulated instruction and the state of the registers at each instruction. My gigantic harddrive could easily store this file. With no luxuries like printf() available, I coded up a formatter that would write line after line of this:

PC: 0100 MOV AL,(HL) A: E3 B: 00 C:07 D:A5 HL:0400 FL:04

A few rounds of testing later, I was ready to boot up CP/M. Minutes later, I realized I had a bit of a problem: the emulator crashed, leaving a "disk full" message, a still-madly whirring away harddrive, and not a single CP/M boot message. Before my logging code, the message would pop up within a second.

It too me a few minutes to realize it, but the hours that I had spent writing an instruction logger were a complete waste. There was no way such a logger could ever possibly work. Can you figure out why?

As it turns out, I didn't have nearly enough CPU power or hard drive space. Not by a long shot. Formatting a hexdump of a single 8080 instruction requires at least a few hundred instructions and requires at least 60 bytes on disk. As slow as the 8080 was, it filled up the 14MB disk in a quarter of a second of simulated CPU time. Had I let it run (and, of course, overwrite the old instructions), I would not have lived long enough to watch CP/M boot.

It took a few more weeks, but I eventually, was able to get CP/M to boot. A minute later, I was sick of it and went back to CTOS. Fortunately, I was able to pawn off my 8080 emulator to the CTOS-folks and they ended up using it somewhere, for something else.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!