The emulator is also running nearly 3 million fewer instructions, which could be down to it doing fewer loop iterations whilst waiting for things to come ready, or could also be attributed to the bios giving up early.
Since you say that the emulator doesn't work. I suspect that this is probably because the emulator causes the bios to take a different path. A quick example would be the video memory check. If that's not up properly then its going to bail out in the first few tests where the one that works would go through a lot more.
Also if things are failing then your emulator path may be doing tons more work. The legacy bioses I've worked with try to figure out what type of adapter they are by what memory range will pass the video check. So if your video ram is failing the bios may be going and checking for a VGA, then EGA, then CGA, and then Monochrome.
Until the emulator actually works I don't think this comparison will be valid.
I am now working on the hypothesis that the emulator has to be faster if it is going to work at all for the epia-m, which means fewer instructions per emulated instruction. I have a few ideas which I intend investigating and trying out:
- embed/inline the memory read/write and io functions directly where they
are used rather than having trivial subroutines accessed via arrays of function pointers. I believe that this processor is easily stalled by jumps to subroutines, and so inlining these should help.
Again what version of the emulator are you running? There was a lot of work done to the emulator recently to reduce its size so it could be included in the the boot image. One of the major things was moving a lot of the individual functions into one single function with different arguments. There were numerous other things done to reduce the size so make sure you are looking at the latest codebase.
Size and speed used to be inverse of each other but now due to instruction caches smaller can sometimes run faster than inlined "speed" optimized code. You seem to have a good setup for running comparison tests to determine all this. That will be good info to have. I don't think anyone has run any qualitative tests with hard numbers on emulator performance.
The first step though is figuring out why the emulator is failing.
-- Richard A. Smith