I now have some more information on running the VGA bios through the emulator on the epia-m
I have implemented both real mode and emulated VGA initialisation. The real mode brings up the vga properly, whilst the emulation does not. The emulated version runs to completion and also returns with Carry Flag set which I'm assuming means that it has given up trying.
Using TSC, a performance counter set to count instructions, and a simple instruction counter in the main loop of the emulator, I have come up with the following statistics for the vga initialisation sequence:
Real Mode --------- CPU Clocks = 691,530,971 (600Mhz processor = 1.1 seconds approx) Instructions executed = 16,481,875
Interestingly this gives a clocks/instruction ratio of about 43, which we can put down to intensive I/O and which must stall the processor by many clock cycles per I/O.
Emulation mode -------------- CPU Clocks = 4,618,464,706 (= 7.7 seconds approx) Instructions executed = 1,946,308,181 Emulated instructions = 13,756,300
This gives us 2 ratios of interest: Average clocks per instruction = 2.37 (much less than real mode since the emulation is much more memory intensive) Average instructions per emulated instruction = 141
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.
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:
1) 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.
2) hard code the emulator memory base at 0, so that this addition is avoided on every memory access (since linuxbios always sets it at 0 anyway)
3) Implement the primitive operations in assembler - as has been done in prim_asm.h for the Watcom compiler, but this time for gcc
4) Investigate the emulated repeat move string operation to see if this is done efficiently by the emulator
etc....
Nick Barker