I was a bit shocked when I tried uzem, it did work, but it can barely do its job, getting stuck at somewhere near 26MHz while keeping a 2.2GHz core busy (not very great for the audible experience). Observing the code, I could push it past this point with a little modification:
Code: Select all
inline void set_bit(u8 &dest, unsigned int bit, unsigned int value)
{
value = ((value + 0xFFFFU) >> 16);
dest = dest & (~(1U << bit));
dest = dest | (value << bit);
}
How it shocks me is that I conceived a 16 bit CPU, and did an emulator for that at 12.5MHz, which I occasionally tested on a Pentium MMX 233MHz, and that could almost do it (although that CPU is designed to work without flags, so probably much less work per instruction). Maybe the big damn switch-case loops are neither turned in jump tables etc. in here and there is a hell of branch misprediction going on, maybe something else, but quite disappointing.
I am thinking about trying to do something about it, but to be honest what is in there looks a bit like a mess (compared to the assembly of say, the display modes of the Uzebox kernel whose construction I could understand well from the code). It would take a while to analyze the assembly output to see how the compiler deals with it (and where may lie so many cycles burning away).
By the way another thing which bugs me is that I cannot get any input to it. What I could deduct from the code seems like it looks for joysticks, and if none exists, there is no input despite what its help says (the keyboard controls). I couldn't get to feel confident enough with the code so far to hack myself around this to actually play games... (I tried softgun though, which seems fast, but had a few other oddities, and some weird alsa bug, so lacks sound, but at least I could try a few games with it for the "look and feel")