blueberryMSX

I doubt that the hardware video rendering is the bottleneck in this case, since blueMSX is a relatively demanding emulator - even on newer hardware. I originally tried running the emulator on X, using SDL's software renderer. Sadly, I didn't gain that much with GLES2 - which is why I'm not convinced DispmanX will help.

I appreciate the suggestion, however - I will check it out.

I have very little experience with raspi and just spend some 10 minutes reading some articles on its architecture, so take this with a truck sized grain of salt: the raspi 1 doesn't seem to have an L2 cache for the CPU, only for the GPU. Since the CPU shares the memory with the GPU you really want the GPU to access the RAM as little as possible (unless everything fits inside the L2 cache and never changes, but that's nor relevant for our case here). This means to select the lowest possible, but still usable for blueberryMSX, screen mode. Fewer pixels -> less RAM access -> less blocking the RAM for the CPU.
The L1 cache also seems to be rediculously small, so the next bit probably won't make any difference at all, but still: try compiling with -Os instead of -O3. This will compile optimizing for executable size (and also for speed where it doesn't increase the code size). If a processor has little cache then -Os can result in faster execution than when compiled with -O3, since more loops stay inside the cache.

Anyway, I'm not sure I read all information right and even my reasoning might be completely off, but it should be easy and quick to try out both things (using max 640x480 or something and -Os compiling).

Cheers

As the person who ported it, I don't see why that would be the case . Most of my work was just switching the display code to use native GLES and adding joystick/mouse support (via udev).