I was asked about the expected performance of my upcoming rpix86 emulator on the Atari800 thread. Instead of hijacking that thread, I think it would be better for me to create a new thread specifically for rpix86, so here it is.

The performance expectation for a non-overclocked Raspberry Pi currently looks to be around a 486/20 machine. This is somewhat slower than what I think RPi should be capable of, so there are probably some bottlenecks in my code that I just haven't found yet. Or perhaps simply running the Linux OS causes a big hit on the available CPU power. The DS2x86 version for a 400MHz MIPS processor (without an operating system) runs Doom at 5.1 fps, and the current rpix86 version (on Raspbian Wheezy) only at 5.5 fps, even though the ARM processor should be almost 2x more efficient per MHz than the MIPS processor. My Android tablet with a 1.3GHz quad-core processor runs Doom in ax86 at 27.5 fps, so I think 5.5 fps is slower than what it should be.

My plan is to run some cycle counter tests in the near future to see where the performance problems are. Also my CPU core is still using plain ARMv5 assembly, so using some of the new instructions for ARMv6 could bring some performance improvements.

I guess Rpix86 is using libSDL, so I will be repeating myself here once more:
-In SDL programs, most time in the Rpi is spent (wasted) in the software blitting procedures. libSDL has nice mmx-accelerated blitting on X86 architecture, but it uses an inefficient software implementation on ARM.
-Scaling is also done in software if you use the default, broken fbdev libSDL backend.

Maybe you're using Andrey's GLES2 rendering method instead of SDL? If that's the case, are those numbers coming from a GLES2-render version of Rpix86? Then scaling should be no problem.

Vanfanel wrote:Maybe you're using Andrey's GLES2 rendering method instead of SDL? If that's the case, are those numbers coming from a GLES2-render version of Rpix86? Then scaling should be no problem.

Hello Vanfanel!

Yes, I am using Andrey's GLES2 version (though I only just got it working with Doom, so I may have forgotten some debug stuff in), and I believe the scaling is done by hardware. The Doom speed in rpix86 with the original software blitting I used was around 4.7 fps if I remember correctly. So a considerable improvement, even if it is still not fast enough.

Pate

Now working on piro: http://piro.patrickaalto.com
See my rpix86 project at http://rpix86.patrickaalto.com

thanks for clearing this up and sorry for hijacking the atari thread.
One more question. What video standard(s) are you emulating?
I assume that some could be highly optimised? (Like 640x480x256 vesa standards)

obcd wrote:One more question. What video standard(s) are you emulating?
I assume that some could be highly optimised? (Like 640x480x256 vesa standards)

I'm emulating all the standard VGA modes, most common ModeX versions, and 640x400 and 640x480 VESA SVGA 256-color modes. I think I can use the emulated VGA memory directly as source for the glTexSubImage2D in most of the 256-color modes, works fine in Doom for example. Some ModeX games let the VGA memory wrap inside a frame so that needs some special handling (I hope I can build a single OpenGL texture from two separate glTexSubImage2D calls in those cases, but haven't tested if that actually works. ).

Just to let you know, I have submitted rpix86 to Raspberry Pi Store Community Approval Process (for "In Progress" status) last week, so after it passes (hopefully) the approval, it will be available for free download from the store.

If you can not wait and want to get a sneak peak even before the approval, I can grant you a private license to it if you provide me with your Raspberry Pi Store username.

Thanks for your interest in rpix86!

Pate

Now working on piro: http://piro.patrickaalto.com
See my rpix86 project at http://rpix86.patrickaalto.com

Moving my conversation over from the Dosbox thread... When I try and install it from the Pistore it downloads and then the terminal pops up and says everything has installed properly. Then in the lower right corner a message from the pistore app says that there were errors. I get no option within the pistore to run the software after the fact. If I could figure out where pistore places the zipped contets I have no issues running from the CLI. I don't think this is an error with your software I think this is a pistore problem, I have had nothing but greif from the pistore.

A direct download to the files would be my prefered method of installation if you have one.

Thanks for the extra info Jessie! Looks like my keyboard/mouse event file handling routines have some problems. Can you show what sort of files you have in /dev/input, and specifically in /dev/input/by-id? I am not sure if my system of checking for which of the event files is for keyboard and which for mouse is very good, I scan over all the links in /dev/input/by-id, and the first one that has "event-kbd" in it's name is considered the keyboard, and the first one with "event-mouse" is the mouse file. In my Raspberry Pi I have the following files:

Ok, now the bad news. I tried to play Quest for Glory VGA. Performance is real good, however, I'm getting random input all over the place. The game is acting like I'm clicking the mouse and pressing the right arrow key. The sound is also not working, but I haven't even made sure if it is functioning on the device itself so for now don't worry about that.

Wow, interesting setup you have Jessie.. Looks like the same event file (event0) will handle both keyboard and mouse input. I don't think I have taken that into account when coding my keyboard/mouse reading routines..

I'll try to figure something out in the near future.

Glad to hear the performance is acceptable, at least.

Pate

Now working on piro: http://piro.patrickaalto.com
See my rpix86 project at http://rpix86.patrickaalto.com

This looks fantastic. I'll have to give it a go with The Incredible Machine and Theme Park. Out of interest, could you tell me more about the techniques you're using in your family of emulators? Are you using any form of dynarec or just an interpreter? What portion is hand-tuned assembler vs C?

I haven't tested either The Incredible Machine nor Theme Park, let me know whether they work or not.

My emulators are plain brute force interpreters, there is no dynarec in use. All the CPU core routines are fully coded in ASM, so that the emulator runs C code basically only when calling software interrupts, otherwise it stays inside ASM routines.

There are a couple of major differences between my emulation core and that of DOSBox, for example. Firstly, I don't do cycle counting at all, my core simply runs as fast as it can. Interrupts happen when the hardware (or in case of rpix86, a separate thread) tells the core it is time to handle an interrupt. Secondly, in a sense I don't emulate the x86 CPU flags, I use the ARM CPU flags directly in place of the x86 CPU flags. In practice this means that my code avoids doing any conditional operations, as those would force me to save and restore the CPU flags. Jump tables is the name of the game.

Since my core was originally designed for Nintendo DS, it is not really optimal when running under an operating system. I am hoping that some day there is a development kit for the Bare Metal style development for RPi, that should enable rpix86 to run at proper speeds. If a 66MHz ARMv5 processor can run at 10MHz 80286 speed, a 700MHz ARMv6 processor should run at least 10 times faster, not only 3 to 4 times faster as it now does under Raspbian Linux.

Pate

Now working on piro: http://piro.patrickaalto.com
See my rpix86 project at http://rpix86.patrickaalto.com