In the very early days of general purpose 16 bit computing there was a lot of interest in emulating the Z80 and 8080 since the huge amount of legacy 8 bit code

In the very early days of general purpose 16 bit computing there was a lot of interest in emulating the Z80 and 8080 since the huge amount of legacy 8 bit code was still very important. Unfortunately the emulations were inherently around 10 times slower than native code since around 10 overhead instructions (a jump table, save and restore flags, and a loop) were needed for each emulated instruction. I made my own emulator with no jump table or loop, and so no need to save and restore flags. It comprised just three instructions. lodsb mov ah,al jmp ax These instructions were appended to the emulation code for each of the 256 opcodes which were distributed sparsely through 64K of memory at 0x0000, 0x0101, 0x0202 etc. (no such thing as a free lunch - spending 64K of RAM to get some speed seemed like a daring decision at the time). So my emulator was inherently only 4 times slower than native, and faster PC hardware made up the difference much earlier for me than for people stuck with 10 times slower emulators. Of course these days it would probably mean the difference between running the 8 bit code 1000 times faster or 2000 times faster than native (something like that). Rather than going as fast as possible, the challenge now is accurately reproducing the original timing, as discussed in the article. I'll quietly admit that the 8 bit software I was using extensively at the time ran happily on an 8080, and I never did all the extra work required to get Z80 emulation.