GP2X Question On The Snes In General

[sephiroth111]

From just a view from a person who's been with emulation since even before ZSNES had a windows version, zsnes, the snes emulator written in assembly, could run damn close to full speed with only a 486DX (~16mhz) and 16mb ram. we are running a system that has 2x200mhz arm cpus and 64mb ram. Allocating the sound to the second processor and maybe the video processing functions to the ARM940T, would probably be more benificial than having everything housed on one chip (as with the current Squidgesnes). The trade off (as far as i can see) is less battery life, but I dont know if its doing anything as it stands, so I'm not sure of that.

The homebrew DS program SNESDS/ SnezziDS has a specific audio code for the SPC700 (PocketSPC) that runs on the ARM7TDMI (the GBA's processor and the built in DS's coprocessor). As far as I know, its ONLY on that chip on the DS version. Also as far as I know, its in all ARM assembly. While I don't know if pocketSPC would help out much, seeing how its designed to run in tandem with an SNES emulator, and its currently capable of running on a 16mhz ARM7TDMI (and seeing as the ARM940T is not only superior, but can run ARM7tdmi code, as referenced by arm.com) i would think that it would at least be somewhat helpful.


the SVN for SNEZZIDS, The DS tree is currently stored in branches/ds.
https://svn.bountysource.com/snezzids/
maybe the sound code can be ripped from here?

Pocket SPC's page is hosted here,
http://pocketspc.pocketheaven.com/
Latest source is available here:
http://pocketspc.pocketheaven.com/pocketspc-src-v10.zip


Unfortunatly i dont know the current status of SquidgeSNES, but i have great faith in squidge to make the emulator better than ever before. (i heard something about an Assembly based cpu?). unfortunatly i dont have much in the way of coding skills, (rudimentary Java and C++.) or I'd offer as much help as possible.

A final side note, if the backgrounds are ordered wrong, is there some way to change the ordering of them for a specific game?
say, 1 is the far background, 2 is some objects in the background, 3 is the forground and 4 is the sprites

and layer 2 and 3 get switched via priority errors, is there any way to switch them out? i ask because in MMX megaman is sometimes hidden by the backgrounds.

 

[Azalin]

In regards to the second processor:

I've heard that many coders are having a very tough time figuring out how to use it for anything at all, much less such a complicated thing as SNES sound emulation.

 

[sephiroth111]

In regards to the second processor:

I've heard that many coders are having a very tough time figuring out how to use it for anything at all, much less such a complicated thing as SNES sound emulation.

I thought we had code that did this already (the snes9x sound code that moved to the 940t)

 

[BradN]

SNES sound emulation is a perfect fit for the 2nd processor, if only because there is barely any communication between the main CPU and the sound CPU in the real SNES. Those .SPC SNES music files you download are just the contents of the sound CPU memory, and they play the whole song usually... playing a sound effect can involve just sending one or two bytes to the sound CPU.

Now, if some games _need_ the sound CPU synchronized to the main CPU very closely, then it gets a tiny bit trickier, but I bet 99% of games would run fine without any extra effort.

 

[Azalin]

Hmm, perhaps my information was outdated then.

 

[sephiroth111]

SNES sound emulation is a perfect fit for the 2nd processor, if only because there is barely any communication between the main CPU and the sound CPU in the real SNES. Those .SPC SNES music files you download are just the contents of the sound CPU memory, and they play the whole song usually... playing a sound effect can involve just sending one or two bytes to the sound CPU.

Now, if some games _need_ the sound CPU synchronized to the main CPU very closely, then it gets a tiny bit trickier, but I bet 99% of games would run fine without any extra effort.

I have to agree with that, as the only 2 games i could think of offhand is Tales of Phantasia, and Star Ocean.
Reason being is the sound samples they use. the former's intro song is actually numerous SPC "files" layered to make one song.Because of the fact that ToP and SO use almost 90% of the same engine, its pretty safe to say that SO would be equally broken. Though, due to the DSP graphics Star Ocean uses, i dont really think we have to worry about the game even loading, let alone the SPCs it uses. I'm not saying its impossible to run it, as people make the impossible possible, but considering it took the authors of ZSNES that long(until ~2 years ago) to actually properly emulate it (and it was done in graphic packs at first... the horror). In many cases, DSP emulation was "The final frontier" of SNES emulation.

So sound is removed from the code, that leaves CPU, I/O, and Video on the 920. those are obviously cpu intensive. assuming there is a sync with the dual cpus (which admittingly i know there isn't at the moment, due to there being no word from GPH on how to access it) some of the lesser tasks could be allocated to the 940.

posting this really makes me think about the possibilities of the emulator, hence why its good to post such things once and a while.

 

[BobBorakovitz]

start coding then & let us all know what you come up with. :huh:

I'm sure Squidge would've done that already if it was as easy as you think :rolleyes:

 

[Gadget]

start coding then & let us all know what you come up with. :huh:

I'm sure Squidge would've done that already if it was as easy as you think :rolleyes:

Yes, I agree, and with the most of the other comments in this thread, the 2nd CPU could do wonders for the overall performance if sound was completely pushed to the 940. If an emulator was written from the ground up, using lots of clever ASM routines I am sure it would run really well. Most of the problem with the SNES emulation as far as I can see is related to the PPU (or whatever it's called in the SNES). It was a similar problem with the old NES in the early emulation days. The PPU was a pain in the butt to emulate fast (well it was for me and a few others).

 

[sephiroth111]

start coding then & let us all know what you come up with. :huh:
I'm sure Squidge would've done that already if it was as easy as you think :rolleyes:

Yeah, this is the kind of comment i was expecting, totally unhelpful, non-technical, and useless. While i said in the first post, i only have basic programming skills, i was wondering moreso WHY this wasn't done (read: is it possible), rather than an order as to how it should be done. I hardly think this is easy at all, contributing what little i could to blender. This topic was just a misguided approach to a topic probably beaten to death on this board.

Yes, I agree, and with the most of the other comments in this thread, the 2nd CPU could do wonders for the overall performance if sound was completely pushed to the 940. If an emulator was written from the ground up, using lots of clever ASM routines I am sure it would run really well. Most of the problem with the SNES emulation as far as I can see is related to the PPU (or whatever it's called in the SNES). It was a similar problem with the old NES in the early emulation days. The PPU was a pain in the butt to emulate fast (well it was for me and a few others).

This is an example of a helpful comment, the poster actually identifies an aspect that is difficult to emulate, or requires specific timings, removing some of the illusions of ease of coding. Also the poster actually contributes something to the topic at hand. overall, a good post.