About Snes Emulation


damned

Still Fresh
Joined
May 11, 2007
Messages
59
would a dynarec help its performence like it helped alot for gba and psx? :huh:
 
no just wondering how much it would help like getting emulation picodrive quality
 
damned said:
no just wondering how much it would help like getting emulation picodrive quality
I was being sarcastic, but a dynarec might help SNES emulation, however that would require alot of work/time from a developer. Keep in mind they do this for free and out of their own personal time.

Not to mention I don't think a dynarec would be required to get it fullspeed, but what do I know? There's alot of better qualified people to answer that.
 
Last edited by a moderator:
maybe one of the devs are working on a dynarec since snes emu news has been quiet for a while
 
Three things.

First, SNES isn't CPU heavy, its power is more in the rendering and audio. If the 2D rendering engine and the audio DSP are heavily optimized (especially the former) you'll probably see much bigger wins. The CPU is all in all pretty slow.

Second, SNES's CPU is a CISC design. It's the type that lends itself well to a highly efficient interpreter, and doesn't lend itself well to being translated to RISC code. So you don't get the kind of performance improvement you do when recompiling a RISC CPU like the one in GBA or PS1. On the other hand, there are some word size flags that could make things rather expensive for an interpreter. If these things don't change frequently then you recompile as if they were fixed.

Third, the SNES games that people complain most about when it comes to emulation are the ones that use special chips. Doing a dynarec for those, especially SuperFX, would make a huge difference (maybe from the realm of unplayable to fullspeed, if everything else is done better too).. but it'd probably be difficult to motivate people into writing a dynarec for a CPU used in just a few games.

And this isn't worthy of being on the list, but since you mentioned Picodrive.. Genesis emulation has always fared better than SNES and always will. It's a simpler and slower console. Even the CPU, clocked over twice as high, isn't really faster (if at all) because m68k has such bad cycle timings. But then again, 65c816 does too, so I hear. Really old consoles just have super slow CPUs, that's why people didn't bother with dynarec until PS1 emulators came around.
 
Exophase said:
Three things.

First, SNES isn't CPU heavy, its power is more in the rendering and audio. If the 2D rendering engine and the audio DSP are heavily optimized (especially the former) you'll probably see much bigger wins. The CPU is all in all pretty slow.

Second, SNES's CPU is a CISC design. It's the type that lends itself well to a highly efficient interpreter, and doesn't lend itself well to being translated to RISC code. So you don't get the kind of performance improvement you do when recompiling a RISC CPU like the one in GBA or PS1. On the other hand, there are some word size flags that could make things rather expensive for an interpreter. If these things don't change frequently then you recompile as if they were fixed.

Third, the SNES games that people complain most about when it comes to emulation are the ones that use special chips. Doing a dynarec for those, especially SuperFX, would make a huge difference (maybe from the realm of unplayable to fullspeed, if everything else is done better too).. but it'd probably be difficult to motivate people into writing a dynarec for a CPU used in just a few games.

And this isn't worthy of being on the list, but since you mentioned Picodrive.. Genesis emulation has always fared better than SNES and always will. It's a simpler and slower console. Even the CPU, clocked over twice as high, isn't really faster (if at all) because m68k has such bad cycle timings. But then again, 65c816 does too, so I hear. Really old consoles just have super slow CPUs, that's why people didn't bother with dynarec until PS1 emulators came around.
thanks for explaining :)
i thought snes would be easier to emulate cause it was slower but never mind :lol:
 
Last edited by a moderator:
Might be a good idea to port Zsnes over to the gp2x as it`s linux based and i think its open source. I dunno how easy it would be but as it carries everything a snes can do it would be the most complete. I do like the snes emu`s though on the gp2x it`s very good and i cant wait to see what`s in store next.
 
IIRC ZSNES relies heavily on lots of x86 processor ASM code which doesn't really help when porting to GP2X since the processor architecture is different.
That's why SNES9X is more commonly used a base for an SNES emulator port...
 
If your remove the graphic rendering functions from snes9x, every game I've tried runs at full 60 fps with sound enabled. If you remove the frame limiter, a lot of games get > 100fps.

Therefore, I would say changing the main cpu to a dynarec would make little difference - certainly not enough compared to the time it would take to code and debug.

I seem to recall however that the SA-1 used the same processor as the main SNES CPU, and this still used a C core - maybe some speedups could be found by changing this over to the assembler version of the CPU used in the SNES.

ZSNES was originally 100% Intel X86 Assembler. Since it has been ported to Linux, it is now about 75%. SNES9X has always been in 100% C, so it's the most ported emulator.
 
Cool answers, Very informative.
On a side note I was listening to Retronauts today and they were talking a lot about Secret of Mana. I was wondering if 2 (or 3) player joypad support could ever be implemented?
 
Squidge said:
If your remove the graphic rendering functions from snes9x, every game I've tried runs at full 60 fps with sound enabled. If you remove the frame limiter, a lot of games get > 100fps.

ZSNES was originally 100% Intel X86 Assembler. Since it has been ported to Linux, it is now about 75%. SNES9X has always been in 100% C, so it's the most ported emulator.
I am too lazy to look at it myself, so I hope someone can tell me if the GP2x SNES emulators use asm in the video renderer. If not, it seems like a good point to start optimising them.
 
Last edited by a moderator:
Nope, there's no asm in any of the snes emulators, and asm implementation would be quite a task.

Optimising parts of the renderer at the expense of graphic quality seems to just get people complaining ("Why create a snes emulator that looks like nes" for example).

If you created your own from the ground up with speed in mind, people would complain about compatibility (and probably the above too).

So, developers lose interest & motivation.

It's easier to just wait for processor speeds to increase in future GP2X's
 
Squidge said:
Nope, there's no asm in any of the snes emulators, and asm implementation would be quite a task.

Optimising parts of the renderer at the expense of graphic quality seems to just get people complaining ("Why create a snes emulator that looks like nes" for example).

If you created your own from the ground up with speed in mind, people would complain about compatibility (and probably the above too).

So, developers lose interest & motivation.

It's easier to just wait for processor speeds to increase in future GP2X's
Ehhh? What about "render8 orr.S"? Tile renderers written in ARM ASM, aren't they?
 
Last edited by a moderator:
i guess i never will be able to play mario rpg and kirby 3 on my gp2x then :(
 
Godmil said:
Cool answers, Very informative.
On a side note I was listening to Retronauts today and they were talking a lot about Secret of Mana. I was wondering if 2 (or 3) player joypad support could ever be implemented?



I'm a fan of Retronauts too, but even with joypad support, you couldn't read the text, because of the Mana games' hi-res text display.
 
Last edited by a moderator:
Wrong. SoM renders at the standard SNES video resolution.
(And it IS fully readable with a reduced resolution)

The Text ONLY applies to the Menu screens. Not ingame. Indeed SoM2 with some USB Joypads would be hella-cool.
 
Exophase said:
Ehhh? What about "render8 orr.S"? Tile renderers written in ARM ASM, aren't they?
These are the remains of OS9XGP for GP32 (AFAIK ssnes was started from OS9XGP code). GP32 has it's video memory laid out differently (it's rotated), so those renderers are not suitable for GP2X and the code is unused. I've used that code for my UIQ2 port of snes9x, and it's not that much faster anyway.
 
Last edited by a moderator:
Back
Top