About Snes Emulation

[___]

how about using the second cpu of the gp2x? Maybe the 940 could be used for sound processing. That might give a large speedboost and also lots of other emus are now taking that approach and we've got some amazing results.

We've got picodrive running both processors and now gngeo aswell.

 

[notaz]

how about using the second cpu of the gp2x? Maybe the 940 could be used for sound processing. That might give a large speedboost and also lots of other emus are now taking that approach and we've got some amazing results.

PD relies on moving ym2612 synth emulation (which demands quite a lot of computation @ 44kHz) to 940. SNES synth emulation is not as demanding, so there is no point moving that to 940. But then why not to move spc700 (sound cpu) along with all it's DSP and stuff, which composes SNES sound module, to 940?

The problem is synchronization. While it's enough to do one [ym2612]<->[other genesis stuff] communication once per frame, it is not enough to do the same for [snes sound]<->[remaining snes stuff]. Snes9x runs them cycle-by-cycle (doing that with sound @940 would require hundreds/thousands communications per frame) and still some games are detected and different timing is used for them.

I don't say it's impossible, it would require too much effort to make it work.

 

[___]

okay, I guess optimizing snes emulation is not so easy, eh? Is there anything else that could be loaded off onto the 940? Maybe special chipsets and graphics processing for scaling? scaling wouldn't really help speed up emultaion but eventually if we used the 940 for graphics and scaling, smooth gfx could become a reality without further slowdowns...

 

[Squidge]

The 940 is ideal for off-loading cpu intensive code, but it's useless if there's a lot of data movement required. Everytime the 940 reads main memory (ie, non-cached), it stalls the 920, as there's only a single memory controller.

Since the 940 only has 4KB of dcache, moving some things from the 920 to the 940 may actually slow down the emulation, unless the data (and code) is small enough that it can use the caches efficiently.

I thought the best trade off was having two different renderers, one being fast, and the other one slower, but being more accurate; but it seems people didn't like that approach, so I've not done any further work on it.

 

[___]

i guess then we can't utilize the 940 efficiently... is there any other ideas that you might have to optimize snes emulation further?

 

[cowai]

I'm really curious... Is it possible to move most of the work to the 940 with prior access to the ram, then let the 920, with all the cache, be let alone for some other stuff, like graphics?

Sorry for my not-so-good english

Ari

 

[Squidge]

Of course it's possible.

Whether it makes any different to the speed is another question entirely however

What you might find is that doing it that way improves the rendering of the graphics considerably, but due to the lower cache on the 940, the rest of the emulation runs slower and doesn't generate enough data for the graphics renderer to actually run any faster.

What we have now is several techniques that /might/ improve emulation by an unknown amount, but what require significant effort. I don't think any of the people here will have enough time, motivation, and interest to do that.

 

[Godmil]

So... if those things aren't worth the effort, how about multiple joypad support
If speed is fine as is, how about increased functionality.

 

[___]

that's too bad. I guess we won't see fullspeed snes emulation for a while. Not a serious issue though, as snes emulation is already good enough. But fullspeed would be nice and smooth.

 

[DaveC]

Couldn't the renderer in DrPocket SNES just be re-done in ASM and maybe a few GP2X specific optimisations? It is already pretty accurate but Reesy said the renderer was just ported from a PPC with little optimising. It would seem that optimising that would be easier than re-writing a renderer from scratch to run on the other core. We would get some speedup from that which would be better than nothing.

 

[PokeParadox]

For me the SNES emulation is good enough speed-wise, I don't mind a bit of overclocking since I luvs the SNES.
I agree with the joystick support, that would be a very nice addition.

I'd like some of the custom chips to have better support, but I do realise there is a lot effort that would be required.

Squidge: I'm sorry you feel demotivated about working on SNES. TBH one of the only reasons I'm not using your emulator right now is because it was released as beta, and I was waiting for the next full release. The beta isn't even on the archive either.

 

[Jaguarandine]

I think many people here realize better SNES emulation would be a long term process, and all of the ways to improve it here look like long-term solutions. If game compatibility were to go down, well that's just part of the process; it wouldn't be that way forever (just continue to use the older version until it goes back up). The GP2X probably still has a couple years of life left in it. If work were done on this little by little, I'm sure everyone would be happy.

 

[Exophase]

I've been tempted to try an SNES renderer for a long time now. The one in SNES9x isn't bad, but there's a lot of overhead in some places. It is line/tile hybrid, but anywhere it's forced to be updated line by line it's going to get scrunched pretty hard. It probably doesn't cope with mid-frame VRAM and palette modifications too well either.

Of course I want to try some ideas on gpSP first to see how they go. If it goes well they can probably be tried for SNES emulation too.

 

[Squidge]

Couldn't the renderer in DrPocket SNES just be re-done in ASM and maybe a few GP2X specific optimisations?

Sure, we could rewrite the bulk of a snes emulator in asm, but why do that when we can remove effects such as transparency and raster effects, and then watch you spit bubbles and bitch like crazy on the forums?

After all, it's not like there a reason the graphics routines have never been converted to assembler ever since snes appeared on the gp32 (and the ppc, gp2x, psp, etc), its just that we developers are idle bastards that like winding people up.

Any more stupid questions?

 

[naples39]

I thought the best trade off was having two different renderers, one being fast, and the other one slower, but being more accurate; but it seems people didn't like that approach, so I've not done any further work on it.

I thought it was a great idea, it's a shame the feedback was so negative IMO. Why wouldn't people want to have the best of both worlds? I guess that means that a bugfix release for zip support and some sound stuttering under PS renderer isn't coming. Don't blame you if no one's using that version.

 

[ste_167]

Couldn't the renderer in DrPocket SNES just be re-done in ASM and maybe a few GP2X specific optimisations?

Sure, we could rewrite the bulk of a snes emulator in asm, but why do that when we can remove effects such as transparency and raster effects, and then watch you spit bubbles and bitch like crazy on the forums?

After all, it's not like there a reason the graphics routines have never been converted to assembler ever since snes appeared on the gp32 (and the ppc, gp2x, psp, etc), its just that we developers are idle bastards that like winding people up.

Any more stupid questions?


A slight clash between the elite gp2x perfectionist and elite coder, but I know you two have common passions. I'm sure DaveC will be the first to admit that without experts like Squidge his gp2x wouldn't be the handheld it is, and truely appreciates the work put into making this happen.

 

[Orkie]

A slight clash between the elite gp2x perfectionist and elite coder, but I know you two have common passions. I'm sure DaveC will be the first to admit that without experts like Squidge his gp2x wouldn't be the handheld it is, and truely appreciates the work put into making this happen.

I'm sure he'd also be the first one to start moaning again after the argument were over .

 

[Series-8]

I think a Hybrid tile, pixel by pixel render is the way to go. (SNES may have a wimpy CPU~ but it has non-wimpy PPU chips)

Mind you it will be 100% ARM9 ASM. leveraging the MMSP2 2d hardware.

It would have to be many stages:

Stage 0:

Background Tiles;

Would convert all SNES background tiles into a 16Bit Type format,
(Paying attention to each tiles pallet (mid-frame pallet fiddling is argh!))
and buffer these in memory. (I'd rather have it create new tiles for pallet change than change all the tiles, burn, memory, burn!)

They just get fast, block moved to the frame buffer. (possibly using rotation of the 2D accel. too.)

There is a background tile map, that keeps track of what is where. If the background map is changed, but still only scrolling up/left/right/diagonnaly/down (e.g not a whole new screen) then the tile buffer is just shifted over with a MMSP2 memory block move

There are actually 4? layers of background tiles, thus transparency / mask data is also stored in the tiles.
The MMSP2 2D Accelerator supports this. ( I think, the docs arn't the clearest)

Stage 2 (0):

Mode 7.

Either brute CPU matrix transforms on the 'stock' layer rendered by stage 0, or possibly with some matrix transform help from the MMSP2 video??? decode hardware (????).

This Stage actually takes the output of stage 0 and messes with it basically.

Stage 1:

Sprites;

They render right on top of the now background filled fb for that frame.
(in the render order the SNES uses of course)

Trick A:
Areas that have not had any sprites cover the tile area are skipped over from the last frame.
(Assuming the Stage 1: tile buffer is not 'dirty' -- the background is the same)

This stage is actually using a modified version of the Stage 1 pipeline (Tiles), except sprites are like tiles that can be anywhere and have alpha channel information (true transparency)

and there are fewer of them, and they have more complex order. The MMSP2 may also handle sprite clipping(?)

only standard sprites with no colour addition or subtraction (only rotation and mask information)


Stage 3:

Transparency layer;

HDMA and other funky layered effects, especially colour addition.
(for sprites and backgrounds)

It may be possible to use lots of indexed pallets, thus transparency effects become 'cheap'~
It makes a cross-lookup pallet for each colour combination. Or not as the SNES has a 15-bit total pallet...
(MMSP2 supports 16-bit in hardware) -- but only for games without any transparency / colour addition...

Thus no nasty colour addition math per pixel / line. Just fast lookup of a pre-cooked value in a table somewhere. (assuming sprite A does not cover Sprite B and Sprite C, just background 1/ 2/ 3/ 4, ect...)

Do any SNES games have sprites that use colour addition / subtraction with MANY sprites?

E.g: More than 2?

I just had a stupid idea.

The LCD makes colour addtion rather tricky... (RGB5:6:5 conversion, pallet lookup insanity,ect... and SNES many and strange pallets)

The TV output has all kinds of video --nee scanline type fiddling capabilities...

Why not have colour addition ~ and perhaps HDMA like effects on that instead of messing about with a frame buffer (s).

 

[Squidge]

Nice idea, Series-8, I like your method, so good luck with that

However, I wouldn't bother trying to blit the tiles onto the screen (or offscreen) buffer - setting up the hardware registers would take longer than doing it in software, considering that tiles are usually 8x8 pixels.

The reason I don't intend on developing such a technique myself is that I don't use my gp2x for emulation. In fact, I don't use it at all, so development gets done when I get interested in something (on whatever platform, not just the gp2x).

 

[Series-8]

I'd hope doing it in hardware would actually allow the CPU to use its cycles for 'other' stuff besides rendering.
~Or not use the ARM920 and use the secondary ARM940 for rendering...

Also according to the docs; the 2D hardware can perform one ROP (Raster Operation) and have another one buffered to run next.

Still even before I would evaluate the performance (and write something) of this I'd need:

#1. Learn ARM9 Assembly.

#2. Learn MMSP2 HW Registers properly

#3. Learn Linux Kernel level driver implementation

#4. Learn exactly HOW the SNES's PPU chip works (and its glitches and oddities)

#5. Hope that there are no weird surprises (Like not being able to convert the colour spaces correctly 15-bit palletized RGB is NOT the same as 16-bit 5:6:5 RGB. Half-High colour to High-Colour (not True colour).
Also possible bad effects from overclocking, due to memory timing changes. And/or the fact that the 2D hardware just may not be enough.

Ideally, I'd build this as a generic 2D Accelerator Driver for the MMSP2-Linux kernel to that this could be plugged into any other project that needs it.

All then that would be needed is a SNES-PPU to MMSP2 Generic Tile/Sprite Rendering Engine.

Or inspire someone else to do it.