Nk's New Snes Emulator

[shinneri]

Yes at make it sound like a state of the union address or throne speech or something else really formal. "My fellow Earthicans..."

Earthlings?

 

[xinfernoofdantex]

lol

 

[moz]

if you must bash davec, piss off to the off topic section and leave this topic on topic.

 

[g4m3r]

yea i wasnt serious, just wanted to start DaveC again, i'd rather snes on my psp =], though i use gp2x for neogeo and megadrive

But wouldn't you rather carry around only one console (GP2X of course )

 

[Epicenter]

No, it appears to be significantly slower. I really do wonder what the most stressful bit of SNES emulation is if you nix transparencies. That's a ~2.68 Mhz 65c816 (not a very tough CPU to emulate, certainly not next to a 12 MHz 68000 like in GNGeo) .. then I believe 2 custom VDPs and the audio subsystem, neither one of which I can see being TOO tough if they are done wholly in ARM9 ASM. When scaling and rotation were going on I could see why things should be this stressful, but since they're usually not, it's not readily apparent.

Regardless of the performance, parallel development of emulators for the same systems like this benefits everyone .. as devs can share discoveries and innovations in their implementation. I'm glad to see it.

We have handwritten and debugged ARM9 assembler cores?

If so I must say that the interactions of the cores must be the slow-down.

If not than their needs to be handwritten cores to get it to the speed of DrMD.

I thought that the Genesis was a bit more powerful than the SNES? SNES had more chips and games with extra chips in em, all in all I don't think I like the SNES hardware.

There's only one CPU to have an ARM9 ASM core for; the 65c816 main CPU. The bits that still seem to be C are video and audio, which will provide dramatic slowdown since that's about all the powerful hardware the SNES *had*-- its CPU was downright anemic. There's no need for a 'hand-written' 65c816 core since it's not anything special to the GP2X, just the ARM9 architecture, as that's the instruction set it's written for.

As for the MegaDrive/Genesis vs. SNES issue; the MD did have an ENORMOUSLY more powerful processor-- a 16-bit MC68000 @ 7.67 / 7.61 MHz on a full 16-bit bus, compared to the SNES' 16-bit hack of an 8-bit 6502-- the 65c816 at 2.68 MHz (3.58 MHz in some rare cases) on an 8-bit bus. The SNES had an advantage in more displayable colors onscreen and hardware scaling/rotation effects, but its resolution was lower and the slow CPU's inability to move large amounts of big sprites meant it often couldn't keep up with a lot of action happening onscreen quite like the MD/Genesis could. If you wanted the prettiest RPGs and the arguably more gimmicky effects, the SNES was your best bet, but if you wanted the fastest, most responsive and reflex-testing games though with less colors, the MD/Gen was your best bet.

For sound, it boiled down to if you preferred dynamically-generated FM Synthesized audio over PCM pre-recorded audio. I've always been an FM man myself, so I prefer the MD's great Yamaha YM2612 synth (very similar to that used in the NeoGeo-- the N.G. is just like an enhanced MD/Gen.) While some games do sound better with a lot of pre-recorded PCM, I was never too wild about it-- less retro charm. The games that did use FM Synth on the SNES sounded horrible, while most games that used heavy PCM on the MD sounded pretty mediocre (some good, some awful, depending on the skill of the designers.)

Emulating the MD is pretty simple since great, full documentation of the MC68000 processor and Zilog Z80 processors are available and the VDP (video display processor) is based around the Master System's which was built around a Texas Instruments model which is also well documented. The Yamaha YM2612 is a distinct part as well and is well-understood. So, all the core components are very easy to understand, and therefore, easier to emulate.

In the case of the SNES, the CPU is a weird proprietary part with the 65c816 embedded with other hardware, and the PPU is some monstrous proprietary thing that is not fully understood. The same goes for its bizarre sound system. This makes emulating it quite a task.

 

[TelcoLou]

I just have one thing to say.

No shit. <_<

 

[Jurrasic]

I believe that full speed w/ transparencies and audio are very possible on the 2x, but perhaps not at 200MHz.

With the skilled programmers we have working on this (and even moreso with open-source code for the parallel developers to borrow ideas from each other) you guys should be able to merge the higher speed of SquidgeSNES and the functioning transparencies of NKSnes.

I have faith. What DaveC thinks means bugger-all to me. And should to you too. Downers waste your time and mine.

 

[OMars]

I just have one thing to say.

No shit. <_<

What?

 

[kgcs10]

Do games that have the superfx work with this?(kirby superstar)

 

[Ravnos]

Yes at make it sound like a state of the union address or throne speech or something else really formal. "My fellow Earthicans..."

Earthlings?

Earthicans.

 

[shinneri]

Yes at make it sound like a state of the union address or throne speech or something else really formal. "My fellow Earthicans..."

Earthlings?

Earthicans.

ah, I see.

 

[TelcoLou]

I just have one thing to say.

No shit. <_<

What?

The mod who approved this topic knows what I mean ...

 

[grahf]

In the early days of SNES emulation back in the 90s, there was a really breakthrough emulator called NLKsnes (Nerlaska or some similar name). It was MUCH faster than the competition at the time. Im pretty sure it later became what is now ZSNES after joining forces.

The point of this post: NLKsnes used a 256 color mode, but offered transparencies. The author used a trick to round to the nearest color. It worked well, with hardly any slowdown if i remember. Now of course x86 does not equal Arm, but i think this just goes to show that transparencies do not always mean a huge speed hit. There are ways.

 

[mahavailo7]

hey, this is nice! The way things are coming along in the gp2x community is amazing! Ya know? All we got to do is get these guys to start developing together, give them some time and A LOT of support, then we should come to expect a lot out of snes emulation on this hardware. Very nice. Inspiring even; that's what the gp2x is about: community.

keep up the good work! I'm looking forward for what the future holds.

 

[Epicenter]

I just have one thing to say.

No shit. <_<

What?

The mod who approved this topic knows what I mean ...

I don't. A question was asked and I answered it ...

 

[paxl]

Even what anyone said,

BEAUTIFUL JOB !!!

paxl

 

[Phil]

In the early days of SNES emulation back in the 90s, there was a really breakthrough emulator called NLKsnes (Nerlaska or some similar name). It was MUCH faster than the competition at the time. Im pretty sure it later became what is now ZSNES after joining forces.

The point of this post: NLKsnes used a 256 color mode, but offered transparencies. The author used a trick to round to the nearest color. It worked well, with hardly any slowdown if i remember. Now of course x86 does not equal Arm, but i think this just goes to show that transparencies do not always mean a huge speed hit. There are ways.

Maybe you should post that to squidge?

 

[Squidge]

The problem with transparencies isn't calculating the colors, it's drawing the backgrounds.

Eg. a standard screen could have 4 backgrounds, this is the equivalent of drawing a screen four times, one screen over the top of the previous to generate the final result.

With transparencies, this can double to 8 backgrounds. You draw the first four in one buffer, and the second four in another. Once you have the two finished results, you subtract one screen from the other to get the transparency effect.

It's this additional drawing that causes transparencies to be slow.

There have been attempts to try and not bother drawing the additional backgrounds, but without actually drawing them, it becomes difficult to find out which parts of the screen are supposed to be transparent. If the snes simply said "render this as x% transparent", it would be childs play, but it doesn't; it uses color subtraction and addition (as described above), which is a lot more complicated.

 

[grahf]

Yeah, i remember you battling with ideas a while back. Im afraid i dont have any real arm experience or else i would have been trying to attribute.

I hope you dont take all the nitpicking personal squidge, everyone who knows better really appreciates all youve done.

 

[Aninhumer]

Wasn't there some talk about using an opaque mask for transparencies?

Although if I understood what you said in your last comment it sounds like this would have little advantage, just like the rounding to 256 colours.