Alternate Retrocomputing Histories

There's a computer science course that goes like this: First you build an emulator for a fictional CPU. Then you write an assembler for it. Then you close the loop by defining an executable format that the emulator can load and the assembler can generate, and you have a complete, if entirely virtual, development system.

Of course this project is intended as an educational tool, to gain exposure to hardware and operating systems concepts. When I took that course, the little homemade CPU felt especially hopeless, making an expensive minicomputer slower than an Apple II. Use it to develop games? Not a chance.

And now, there's MAME.

The significance of this deserves some thought. All those processors that were once so fast, from the 6809 to the 68000 to the lesser known TMS34010 CPU/GPU combo that powers Mortal Kombat and NBA Jam, being completely duplicated by mere programs. This pretend hardware can, in real-time, reanimate applications always cited as requiring the ultimate performance: high frame rate games. When you look at the results under MAME, the screen full of enticing pixels, that instructions are being decoded and dispatched by a layer of C code isn't something that makes its way through the system and into your mind.

Maybe that virtual CPU from that college class isn't so crazy any more?

Now, sure, you could design your own processor and emulate it on a modern desktop or phone. You could even ship commercial software with it. This little foray into alternate retrocomputing histories will result in systems that are orders of magnitude simpler than what we've currently got. Your hundred virtual opcodes is a footnote to the epic volumes of Intel's x86 instruction set manuals. No matter what object code file structure you come up with, it pales in comparison to the Portable Executable Format that's best explained by large posters.

I wouldn't do that. It's still assembly language, and I don't want to go back down that road.

The most fascinating part of this thought experiment is that it's possible at all. You can set aside decades of cruft, start anew in a straightforward way, and the result is immediately usable. There's not much personal appeal to a Z80 emulator, but many applications I've written have small, custom-built interpreters in them, and maybe I didn't take them far enough. Is all the complaining about C++ misguided, in that the entire reason for the existence of C++ is so you can write systems that prevent having to use that language?

(If you liked this, you might enjoy Success Beyond the Barrier of Full Understanding.)

permalink December 28, 2015

previously