Is someone interested in a PSX emulator?

[link68759]

This confuses me, 20FPS? The HD2 could run most games @ 60FPS. Is the available instruction set / coding language REALLY that inefficient and terrible, that a phone from 2009 with lesser hardware can outpace what we have today?
Sent from my RM-824_nam_att_101 using Board Express

 

[EdSherriff]

The main problem with windows phones is tha lack of support to recompilation(JIT) so it may run great on 2D games, playable with some 2.5 and 3d Games but full 3D games may be too slow to be playable. I've made a simple port and it Crash 3 runs at 15~20 FPS, its playable but it is not using any ARM code, what can make it faster but will give a little of work(I own a lumia 620 so on a 920 it can run better). That is why I've created this thread :smile:.

Hey OP I have a bit of experience with emulator development, so maybe I can offer some helpful advice.

Firstly regarding JIT there is allegedly a way to access the VirtualProtect() function you'd need to make data executable. I posted about it on these forums. Have you tried that in C++? it still isn't known if this technique will "pass the censors" either, if you go down this route it may be better to submit a small test app first that does something mundane while using this code.

The second option is of course an assembly interpreter which is entirely feasible and above board store wise but obviously a lot of work. I would suggest starting small by converting your most heavily used leaf functions. You can profile the code to find these but you can usually guess what they'll be. Functions to decode CPU addressing modes are the first things that spring to my mind.

Third you can also make use of ARM Neon intrinsics to vectorise code into native SIMD. While VS2012 can auto vectorise (for x86 at least), it can be annoying to re-write all your loops to get it to work.

 

[juanitoriv]

Yes please

 

[EdSherriff]

This confuses me, 20FPS? The HD2 could run most games @ 60FPS. Is the available instruction set / coding language REALLY that inefficient and terrible, that a phone from 2009 with lesser hardware can outpace what we have today?
Sent from my RM-824_nam_att_101 using Board Express

Just to clarify for those less knowledgeable in software development why exactly WP is so hard to develop emulators for vs Android...

Every emulator works by converting machine code instructions written for one system into another code, usually this is to the native instruction set of the platform the emulator is running on. So essentially a WP8 PS1 emulator is trying to convert MIPS instructions and calls to the PS1 BIOS into ARM machine code and DirectX calls. The simplest way to do this is an interpreter, it reads an instruction from the game's code then attempts to decode it, in the simplest case this would be a gigantic switch statement in C code.

Unfortunately this is very slow, many native instructions are being executed for a single game instruction. Many of these are caused by the overhead introduced by using a high level language like C. So the next step we can do is re-write our interpreter in native assembly language and get access to some instructions that may be available on our platform's CPU but not directly accessible from C code. However there will still be many more instructions executed per emulated instruction and needless to say writing a massive program in assembly language is not trivial, nor can it be ported to other architectures (e.g. x86 to ARM).

The final step which is actually so powerful that you can often skip using assembly and go straight for a C program is dynamic binary translation (also known as dynamic recompilation/dynarec or JIT/Just in Time compilation). In this case the emulator still has an interpreter but the emulator dynamically profiles the code, recording how often certain sections are run. The emulator also stores the eventual output of the interpreter (native machine code instructions). When the emulator detects it has run a piece of code before, it can skip the interpretter and just pull the stored native code from memory and execute that. The end result is a massive performance increase.

To give you some perspective. On a PC emulators for 8-bit systems like NES or SMS can be written using C, C++ or C# interpretters. 16-bit systems like SNES and Megadrive usually use assembly code interpreters. Anything newer like PS-1 has always used dynamic binary translation/dynarec to get the required performance.

Problem is that WinRT and WP8 apps cannot use dynarec because this technique requires that the program use self-modifying code. Why is this? It just so happens that self-modifying code is commonly used by viruses to conceal themselves. Android and jailbroken iphones allow self modifying code to be executed.

EDIT: I'm updating this post to reflect a minor breakthrough achieved for emulation on WP8. I neglected to mention there is a technique that falls in between pure interpretative emulation and dynamic binary translation called "threaded interpretation". In this method when an instruction is run by the interpreter the emulator caches a pointer to the decoded interpreter instruction. When it encounters that instruction again (i.e. the program counter address matches) the emulator can retrieve the pointer and jump directly to the decode instruction, the intervening series of operations to decode the instruction is avoided. In theory at least no self-modifying code is required since the emulator is just calling code that already existed elsewhere in the program. N.B. The technique is called "threaded" because it is essentially generating threaded code, not because it is multi-threaded.

What does this mean in terms of performance? Well it's still not going to be as fast as dynamic binary translation, because the emulator is still having to jump around the program every instruction as opposed to executing a big block of native code stored in memory. However this difference is extremely small in comparison to the gain over a traditional interpreter. Will it work on WP8? We don't know yet but Andre is trying this technique out on emiPSX so we'll have to see what happens...

TLDR WP8 cannot emulate games at the same speed as the same hardware running Android. But we may be able to get close...

 

[Ebira]

Definitely, I'll BUY it......please make this emulator.

 

[Andre o Botelho]

Hey OP I have a bit of experience with emulator development, so maybe I can offer some helpful advice.

Firstly regarding JIT there is allegedly a way to access the VirtualProtect() function you'd need to make data executable. I posted about it on these forums. Have you tried that in C++? it still isn't known if this technique will "pass the censors" either, if you go down this route it may be better to submit a small test app first that does something mundane while using this code.

The second option is of course an assembly interpreter which is entirely feasible and above board store wise but obviously a lot of work. I would suggest starting small by converting your most heavily used leaf functions. You can profile the code to find these but you can usually guess what they'll be. Functions to decode CPU addressing modes are the first things that spring to my mind.

Third you can also make use of ARM Neon intrinsics to vectorise code into native SIMD. While VS2012 can auto vectorise (for x86 at least), it can be annoying to re-write all your loops to get it to work.

I don't believe that a app using self modifying code will pass certification, I've tried Neon Intrinsics and got slower that arm intrinsics but have to revise the code to see if it gets faster, I've made some changes on the interpreter but without writing Assembly code by hand is complicated to make it really faster, inline assembler would work but is not supported by the sdk, I must have to write a whole new interpreter that is really a lot of work. PS: the emulator is written in C++ or else I courd get 1FPS :smile:.

 

[EdSherriff]

Yeah it's pretty frustrating not having in-line ARM assembly available in visual studio. Can't you rewrite a small number of functions in assembly, then cross assemble them using armasm and just link to the resulting object files in VS2012?

Have you checked the disassembly of your release build? I'd hope for some embarrassingly parallel operations like large memcpys to be vectorised by the compiler. I assume you've already taken care of the obvious C optimisations for an interpreter, for me these were:
Using a tree of function pointers organised similarly to the real CPU's decode (such that the hardware decode time is roughly proportional to the call depth of the interpreter for a given instruction).
Passing just the op code into the function tree as a constant. The addressing mode functions return pointers to members of the CPU context struct.
Using pointers that can be leveraged directly by the target platform's addressing modes.
Not using objects where they weren't needed (sacrifice maintainability for speed/reduced overhead).

I have been toying with writing a Megadrive emulator for WP8, I wrote a nice little interpreter for the 68k in plain C, while the VDP is a class (haven't bothered with the audio yet ). But I decided I was going to wait for SDL to be ported to WP, I just can't stand all this DirectX boilerplate and DirectXTK seems half arsed in comparison to SDL 2.

 

[Kyle Bridges]

I've been away from WP's for since last year and have grown a love for android phones but not because of the hardware but because of the amount of emulators and 2nd the customization. I now have a Nokia 920 and would love to see a PSX emulator maybe even collaborate with themeister developer of a famous multiemulator called RetroArch. All he needs is someone to write a GUI as his app uses cores compatible with any device; that's my understanding as I've discussed this topic with him in the past. Still I hope PSX can be brought to the WP series I would gladly pay!

 

[Andre o Botelho]

Yeah it's pretty frustrating not having in-line ARM assembly available in visual studio. Can't you rewrite a small number of functions in assembly, then cross assemble them using armasm and just link to the resulting object files in VS2012?

Have you checked the disassembly of your release build? I'd hope for some embarrassingly parallel operations like large memcpys to be vectorised by the compiler. I assume you've already taken care of the obvious C optimisations for an interpreter, for me these were:
Using a tree of function pointers organised similarly to the real CPU's decode (such that the hardware decode time is roughly proportional to the call depth of the interpreter for a given instruction).
Passing just the op code into the function tree as a constant. The addressing mode functions return pointers to members of the CPU context struct.
Using pointers that can be leveraged directly by the target platform's addressing modes.
Not using objects where they weren't needed (sacrifice maintainability for speed/reduced overhead).

I have been toying with writing a Megadrive emulator for WP8, I wrote a nice little interpreter for the 68k in plain C, while the VDP is a class (haven't bothered with the audio yet ). But I decided I was going to wait for SDL to be ported to WP, I just can't stand all this DirectX boilerplate and DirectXTK seems half arsed in comparison to SDL 2.

Thanks the tips, I've read a lot about fast interpreters and got a little more breath on the emulator changing from the original switch based interpreter to funcion table but with my limited knowledge on the ARM architeture I coudn't advance (tail call, multiple calls on a loop,returning next opcode, didn't work). If you can share the 68k code can give me some Ideas because I'm running out of it to speed UP the main loop, I would like to do something like recompilation at least for the simple opcodes...

 

[Andre o Botelho]

I've been away from WP's for since last year and have grown a love for android phones but not because of the hardware but because of the amount of emulators and 2nd the customization. I now have a Nokia 920 and would love to see a PSX emulator maybe even collaborate with themeister developer of a famous multiemulator called RetroArch. All he needs is someone to write a GUI as his app uses cores compatible with any device; that's my understanding as I've discussed this topic with him in the past. Still I hope PSX can be brought to the WP series I would gladly pay!

by what i've read RetroArch uses DYNAREC (PCSX REARMED source)and maybe OpenGL ES so it is not useful on WP.

 

[tester1998]

 

[Roman Ekaterininsky]

Thank you for beta! Testing Vagrant Story now. Default settings. Lumia 620

 

[EdSherriff]

Thank you for beta! Testing Vagrant Story now. Default settings. Lumia 620

Is the 17 fps indicative of the average frame rate? How variable is the frame rate and by how much does it vary?

 

[Dk92]

Is the emulator out?

 

[Roman Ekaterininsky]

Is the 17 fps indicative of the average frame rate? How variable is the frame rate and by how much does it vary?

60 fps at the main video, 20-30 during game, 15-20 when fighting. FPS meter not very accurate it updates just every sec and seems to shows average FPS. Sound is not good but I didn`t change emulator settings.

Is the emulator out?

You can get beta if you send your Microsoft Account email to developer (Andre o Botelho)

2 new pics for you:

 

[EdSherriff]

60 fps at the main video, 20-30 during game, 15-20 when fighting. FPS meter not very accurate it updates just every sec and seems to shows average FPS. Sound is not good but I didn`t change emulator settings.

Good stuff, Vagrant Story is quite a good benchmark for a PS1 emulator given the heavy use of 3D and lighting. If you're interested in benchmarking, the following games are the most graphically intensive on PSX (to the point that the original hardware exhibited slowdown on some of them).

Full 3D
Gran Turismo 2
Tekken 3
Driver 2

2D/3D
Final Fantasy IX
Chrono Cross

2D
Adventures of Lomax
Legend of Mana

In any case I'd be grateful if you could post FPS numbers for any other games you test to give people an idea of what to expect performance wise.

@Andre
Are you still working to increase performance (with the threaded interpreter etc) or does the beta used by Roman reflect the best you can get out of the given hardware?

 

[Andre o Botelho]

I'm now working to get the emulator working, the speed is enough for while - there's lots of games playable, at low framerate but working - but there's lots of things that can be done to speed but involves changes on the source code and can be made after it is usable on WP, for full 3D games I've tested Gran Turismo and is slow to hell ^^, Tekken 3 is playable but there's some bug on the Interpreter that hangs on wrong opcodes randomly - I think is a timing issue, I can't test all games so the Beta Testers can help.
PS: I've received some email about people wanting to get the beta - I'll add these as soon as I can.

 

[EdSherriff]

I've also been thinking some kind of game compatibility list for EmiPSX would probably help to reduce the number of ridiculous complaints about "X game not working! I demand you fix it this instant!". Pretty much guaranteed given the size of the PSX game catalog, widespread appeal of the concept and the extensive modifications you've had to make to port the core (which laymen will be oblivious to). It needs some kind of wiki like page or something for beta testers to contribute to (community any ideas?!). At least you could give would-be users something to refer to before they get the app by providing the URL in the app description.

I'm still shocked by the number of idiots who seem to download emulator apps without any idea of what they or ROMs are or how they work then leave a one star review saying it doesn't work. I'm guessing your support mailbox will be bombarded with stuff like that if it isn't being already for Emigens.

 

[Nathan McGraw]

Glad I found this thread! Looks promising!

 

[Amar Jamakovic]

I registered simply because of this thread.

Make this shenanigans happen, and you get a customer for your app if it's at reasonable, if a bit higher price than most (because this is a ******* PS EMULATOR!).

Anyway, good luck and keep me posted