GP2X My Solution To The Lack Of A Good Snes Emu

[Lint]

Ok, I had this idea a long time ago, but since I've lost my GP2X console I left it behind, and now I'm on the mood to talk about and see what people think

The problem about snes emulation that gp2x faces is that there are not so many sources for porting a snes emu to it, in fact, I can only name snes9x and zsnes
Snes9x is written in C++, so it means that it's kinda slow (and also its code is not much optimized, since the original platform is PC and PC do have a LOT of processing power nowadays...) but I think all tries gone this way

So why not try to port zsnes, which is faster and has as much support as snes9x?
Well, zsnes is mostly written in assembly language, which is architeture-specific, that's the only reason why you have zsnes only for PC

And why not try translating all the x86 assembly to arm assembly and using it?
The idea was to map all registers eax = r4, ebx = r5, etc... and then you can even accomplish a good percentage of the code being replace by plain text replacement, since "inc eax" will always go for a "add! r4, r4, #1", "jmp mylabel" to "b mylabel" (if the label is reachable) and so on...

Doing it by hand is a lot of (redundant) work, a program could be made to take a chunk of x86 code and output it as arm, and the someone just take a look over to see if it fits ok (well, in fact there will be a lot of places where you can do optimization to an certain extent, but let's not worry about this right now)

So... that was my idea when I had a gp2x... I miss those days

 

[DaveC]

The hardware is way too different. It is not as easy as translating X86 instructions to ARM. The PC graphics/sound system is also way different.

It would just be "easier" to optimise the renderer speed in the emus we already have.

 

[SiDCrAzY]

There is a good SNES emu already, there just isn't a perfect one.



Edit: Before anybody says something I'm not complaining, I'm quite happy with the SNES emus right now.

 

[quartercast]

I think both SquidgeSNES and DrPocketSNES are both very good emus, if you are having trouble with any particular roms, I suggest you alternate between the two.

I love Front Mission on DrPocketSnes!!!

 

[Squidge]

I have thought about this lots of times, but considering the CISC nature of x86 assembler, it would be a complex task - it would be like writing a static recompiler for x86 -> arm.

You basically have two methods: You can translate the binary code of zsnes to arm binary code, this would be easier as it's basically a disassembler, but you would have to differentiate between code and data, which is difficult.

Or, you can translate the assembler text files to arm assembler. You don't need to worry about code and data, but you basically have to write a full assembler.

 

[mrsnature]

And why not try translating all the x86 assembly to arm assembly and using it?
The idea was to map all registers eax = r4, ebx = r5, etc... and then you can even accomplish a good percentage of the code being replace by plain text replacement, since "inc eax" will always go for a "add! r4, r4, #1", "jmp mylabel" to "b mylabel" (if the label is reachable) and so on...

Writing something in ASM does not make it directly faster. It just allows you to have more control over optimizing the code; Even if your suggestion were possible...the asm code is optimized for PC, but the output from this 'translation' will not be optimized for the gp2x.

Also, what you are suggesting is nearly an emulator based on static recompilation...

And i agree with the others, SNES emulation is mostly good anyway.

 

[notaz]

The idea was to map all registers eax = r4, ebx = r5, etc... and then you can even accomplish a good percentage of the code being replace by plain text replacement, since "inc eax" will always go for a "add! r4, r4, #1", "jmp mylabel" to "b mylabel" (if the label is reachable) and so on...

Only small amount of instructions can be replaced like this, others would need much more. It would require a lot of effort to do this and I really doubt the end result would be any faster then what we have now.

 

[Exophase]

Even though on the surface they appear to be the same thing, converting from source is much more feasible than static recompilation. You get to retain the structure of the code (including macros, comments, etc) and more importantly you keep the label abstraction. You don't have to resolve addresses at all, or care about dynamic ones (because they should map directly). You probably don't have to worry about self modifying code or other gotchas that would defeat a more general static rec either. The CISCness isn't that big of a deal just for getting something running, it'd mostly involve loading memory into registers or loading immediates from an immediate pool (which the assembler should handle). The main thing is that you'll always have enough registers to handle it. I don't really understand why instructions can't map one to one.

And whatever doesn't turn out right can be hand modified until it does. It'd just be a starting place, but it could be very difficult to debug. About other hardware differences - the Windows version uses SDL now, so that's definitely an asset, isn't it?

You could also use gas or nasm or something else as a frontend to do the assembling for you, I suppose.

The thing with ZSNES is that its source is just not very easy to understand, which is probably it hasn't been much ported and the conversion process back to C has been slow.

 

[Lint]

Whoa, a lot of people reply to this one

Ok, so let's see, first of all, I'm by no mean saying that it is the definitely solution for the problem, it's not. The solution could be porting all x86 asm -> c and then compiling it to x86 AND arm with ease, but that must be done by someone who actually knows very well zsnes (not me) and even the authors were not up to it (they could, but apparently they don't have enough reason why, I think..) What I'm proposing is an easier and careless way to port it (since you don't have to understand zsnes inner parts, just make sure that every opcode is translated ok and you'll be on your way), it's likely to be the second option squidge pointed, but could be made by hand, by a text-replacing tool or by a proper program. (squidge just pointed the last)

Now, from what I've already translated a long time ago (by hand, just to see how it would feel like), the resulting code will be 2 to 3 times slower but can very, VERY easily be optimized to be as fast/faster than the original, you'll have at least 4 registers for general purpose usage that you can cache local-routine memory addresses, wich would reduce memory access to much less and speed up things, but that's just to mention 1 kind of (common) optimization, there are countless, we just need to see the proof of concept first to know how much work would have to be done

And yes, I know just because it's arm-written doesn't make the emulator fast, just try running zsnes on a pentium-133 machine and then say the emulator is not damn fast h34r:

If you think about running the proof of concept as plain static asmfile translation, the code will be slow for absolutely sure (dunno how much slow, but it'll be slow), even if many opcodes code be translated to just 1 arm opcode, there will be some that would take 3 or 4 opcodes to translate and others that would have to do in a separate branch-with-link like "div ebx" or something..
But if you open the code you'll see a lot of things that can be optimized, and everywhere! I would definitely love to do this part of the job.... If anyone ever made to that part, call me and I'll do it just for fun!

And hey, I did enjoy some squidgesnes when I had a gp2x, don't take my speech as "snes emus on gp2x are crap" but snes emus on gp2x can be better, let's try something, what can be done? Optimizing a cpp-based snes emu is not an option for me (doctors call it cppphobia) but can be for others...

I posted this somehow to be a conversation stimulator, I gotta tell ya.. It worked at least to that extent

 

[damned]

i think the only real problem is no special game support(kirbydreamland3, mario rpg, tales of phantasia)

 

[craigix]

I happen to think that the snes emus we have are pretty good.

 

[xhyldazhk]

I love Front Mission on DrPocketSnes!!!

You too? :lol:

 

[Rivroner]

It would be cool if someone starts to try this new method to see what happen

Maybe the code could be modified enough to use the second core to make the 3D part of the FX games to run smooth.

 

[Lint]

Yeah, I thought that so
But it really looks like everybody is happy with their current snes emus, so nobody handled the idea, so sorry...

I don't understand why people think that porting x86 asm to arm asm could be so hard... I think that most people would find the resulting code inefficient and
inoptimizable, I really disagree with the second part..

 

[RockOut]

If you want to port it, go ahead!

I have no clue what anyone here said in terms of coding terminology, however I will happily test and evaluate any attempt to port zsnes.

 

[Squidge]

Yeah, I thought that so
But it really looks like everybody is happy with their current snes emus, so nobody handled the idea, so sorry...

I don't understand why people think that porting x86 asm to arm asm could be so hard... I think that most people would find the resulting code inefficient and
inoptimizable, I really disagree with the second part..

Its not that, I believe it's the fact that people have been working on snes emu's for a long time, and have eventually got bored with looking at the same old code every day. They want fresh code to look at.

 

[Lint]

but wouldn't that encourage people to try something new?

 

[Squidge]

Exactly, and thats what they do, try something completely different, such as other consoles.

 

[Series-8]

Unfortunately (or very fortunately) most of the 'other' popular consoles are already emulated pretty damm fast.

Still the 'primitive' SNES lags behind the others. (even maintaining a AVG. ~30FPS is beyond most emus capabilities with full rendering enabled.)

I was looking at PocketSNES's SPC700 code, I don't see any show stoppers for moving it to the 2nd CORE.
(but is there any good reason to, I think there are larger performance gains else where)

Is there a need for the SPC700 to be synchronized with the 'main' 65c816 CPU?

 

[rememberthe8bit]

I was looking at PocketSNES's SPC700 code, I don't see any show stoppers for moving it to the 2nd CORE.
(but is there any good reason to, I think there are larger performance gains else where)

Is there a need for the SPC700 to be synchronized with the 'main' 65c816 CPU?

Well, I'd like to think that moving it to the 2nd core would be nice, as it'll likely take some load off the 920 if done right. But, yes, the SPC has to be synchronized with the main CPU. Squidge made a hack that is available in the latest SquidgeSNES that will not synchronize the SPC with the CPU so much. The syncronization with the main CPU may be the main thing that keeps the SPC from being put onto the 2nd core. (I'm not well versed in SNES emulators, or GP2X development, though...)