STICKY: rpix86 (Raspberry Pi x86 emulator) ver 0.19 released!

[Pate]

Hi!

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.

Edit:
rpix86 version 0.19 released June 28th, 2015!

You can download the new version from the Raspberry Pi store: http://store.raspberrypi.com/projects/rpix86 or alternatively directly from my web pages: http://rpix86.patrickaalto.com/rdown.html

New users, be sure to read Ben Garrett's tutorial for rpix86 installation and usage at http://ipggi.wordpress.com/2013/04/23/r ... r-computer

Pate

[Vanfanel]

Hi there, Pate

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.

[Pate]

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

[obcd]

Hi,

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)

[Andrey]

Pate

I checked your C++ to C conversion, all fine except shader code.
You need to modify shader sources with your 1024x512 texture size (half-pixel offsets).

[Pate]

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. ).

You need to modify shader sources with your 1024x512 texture size (half-pixel offsets).

You mean for example this line?

Code: Select all

vec4 c0 = texture2D(u_palette, vec2(p0.r + 1.0/256.0*0.5, 0.5));

I noticed that causing problems, so I experimented with replacing it with:

Code: Select all

vec4 c0 = texture2D(u_palette, vec2(p0.r, 0.5));

and that worked better, but I have to admit I have absolutely no idea what I am doing there.

Thanks for getting back to me on this, Andrey!

Pate

[Andrey]

You mean for example this line?

Code: Select all

vec4 c0 = texture2D(u_palette, vec2(p0.r + 1.0/256.0*0.5, 0.5));

Yes, and in filtering pixel shader code.

[Pate]

Hi all!

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

[ulysess]

I'm interested Patrick. My username is ulysess

[Pate]

Ok, I granted a license to you, you should get an email from Raspberry Pi Store about this.

Thanks, looking forward to your test report.

Pate

[ulysess]

Ok, I granted a license to you, you should get an email from Raspberry Pi Store about this.

Thanks, looking forward to your test report.

Pate

I do not received any mail. Maybe something wrong. My mail is ulysess@gmail.com

Anyway, I can wait if you can't send

[Pate]

Okay, rpix86 is now publicly available on the store, in the "In Progress" section:

http://store.raspberrypi.com/projects/rpix86

Feel free to check my rpix86 pages for some more usage info etc:

http://rpix86.patrickaalto.com/

Thanks for your interest!

Pate

[crookedmouth]

Great news! Thank you for your work Patrick. Will definitely check this out.

[Jessie]

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.

[Jessie]

Well I found the application file and the error I get is that it can't open the event handler. Then it tells me I may need to run as root, but I am running as root.

[Pate]

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:

Code: Select all

total 0
drwxr-xr-x 2 root root 120 Jan  1  1970 .
drwxr-xr-x 4 root root 180 Jan  1  1970 ..
lrwxrwxrwx 1 root root   9 Jan  1  1970 usb-Dell_Dell_USB_Wired_Entry_Keyboard-event-if01 -> ../event2
lrwxrwxrwx 1 root root   9 Jan  1  1970 usb-Dell_Dell_USB_Wired_Entry_Keyboard-event-kbd -> ../event1
lrwxrwxrwx 1 root root   9 Jan  1  1970 usb-Logitech_USB_Optical_Mouse-event-mouse -> ../event0
lrwxrwxrwx 1 root root   9 Jan  1  1970 usb-Logitech_USB_Optical_Mouse-mouse -> ../mouse0

Can you immediately see what might be the problem in your system?

Thansk for taking the time to test rpix86!

Pate

[Pate]

rpix86 version 0.02 released!

You can download the new version from the Raspberry Pi store: http://store.raspberrypi.com/projects/rpix86

This version contains the following fixes and improvements:
- Added int2F AH=AD functions for FreeDOS KEYB.EXE handling.
- Implemented missing EGA REP MOVSW version for "Bard's Tale".
- Added command line parameters -k? and -m? for overriding the default keyboard event and mouse event file detection.

The last addition might help in Jessie's situation, you should now be able to override the failing detection and force rpix86 to use certain event files. Hopefully this helps...

Some more info about this update is available in my blog: http://rpix86.patrickaalto.com/rblog.html

Thanks for your interest in rpix86!

Pate

[Jessie]

I will give it a try sometime tonight and report back. Thanks for your hard work.

[Jessie]

Progress has been made. By using the -k command it loads.

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.

Here is what my "by-id" directory looks like.

Code: Select all

lrwxrwxrwx 1 root root 9 Mar 17 22:03 usb-Logitech_USB_Receiver-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Mar 17 22:03 usb-Logitech_USB_Receiver-if02-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Mar 17 22:03 usb-Logitech_USB_Receiver-if02-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 Mar 17 22:03 usb-Logitech_USB_Receiver-mouse -> ../mouse0

I'm using a wireless mouse/keyboard combo that has a single wireless reciever. It is a Logitech K400.

[Pate]

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

[Jessie]

Performance is very nice for this emulator. I was able to run Quest for Glory VGA with sound at full speed with no overclocks to the R Pi.

[Pate]

rpix86 version 0.03 released!

You can download the new version from the Raspberry Pi store: http://store.raspberrypi.com/projects/rpix86 or alternatively directly from my web pages: http://rpix86.patrickaalto.com/rdown.html

This version contains the following fixes and improvements:
- Improved support for combined keyboard/mouse USB devices (for example Logitech K400).
- Fixed a problem in Mode-X STOSD opcode (fixes "Settlers").
- Implemented read from file directly to EGA VRAM ("Heimdall").
- Fixed SB command DSP_RESET to stop auto-init DMA play ("Doom").

Some more info about this update is available in my blog: http://rpix86.patrickaalto.com/rblog.html

Thanks for your interest in rpix86!

Pate

[ulysess]

Testing!

Thks Patrick. You are the man!

Maybe a great idea would be a parameter to load an EXE directly. For example:

./rpix86 -exe /home/pi/rpix86/KEEN/KEEN4e.EXE

[asb]

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?

[Pate]

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