nesdev.org

Memblers wrote:

mic_ wrote: ; you should adjust your game to work on inaccurate emulators.

You mean shouldn't?

Yeah, that was a typo. It was supposed to say "shouldn't".

It did seem when I was developing, that zSNES and SNES9x would run anything. But I used an SNES clone for initial and periodic testing, which seemed to be fairly close to the actual hardware (except for a couple oddities with the controller ports). On that, nothing would work right until I had initialized probably every single register in the system.

I got the NESticle-effect with the very first thing I wrote for the SNES (an SPC uploading routine). Snes9x happily ran the code even though it had bugs in it that would cause a deadlock (among other things) on a real SNES. My conclusion from that was that Snes9x is useless for development purposes (at least for me).

The big unspoken fact is that ZSNES is probably less accurate to the SNES than NESticle is to the NES. You don't notice as much because the SNES being faster, games are less sensitive to timing.

Think about system requirements:
NESticle -> 100MHz (written in x86 ASM too)
ZSNES -> 166MHz
Nestopia -> 800MHz
Nintendulator -> 1,500MHz

There's something seriously not right when a system that has five processors instead of two, all clocked faster, on a substantially more complex system, results in emulators that are far faster than their quintessential NES counterparts.

I basically got it wrong. I believed people flocked to Nestopia because it was so much more accurate. But it was a combination of many things. 800MHz is well within 90% of peoples' hardware ranges, Nesticle was dying off and discontinued, was closed source, was DOS only and was no longer even producing sound. People had to switch, and they went to the best option of the time.

With ZSNES being the #1 choice these days, it has caused people to believe that its system requirements are what an SNES emulator "should" require. And don't get me wrong, for what it does it's amazing, and it certainly has its place. But for any kind of dev work, forget it.

And just suggesting that anything was like NESticle has become something of a pejorative in the emulation community.

But if you've run any kind of code on it, you know. Here's some fun facts if you don't:

There is no S-SMP opcode timing. All opcodes consume "a clock". The 12-cycle DIV YA,X takes the same amount of time as the 2-cycle NOP. This was done to avoid a single indirect memory access penalty.

The S-CPU does not support FastROM memory access. When you turn it on, it simply uses a different lookup table that takes one less cycle for every opcode, even if that opcode never accesses any FastROM regions, or even if it accesses it multiple times (eg 16-bit RMW).

S-CPU open bus is faked. It returns address>>8 because that is faster than storing the MDR after each successful read. Works great on lda $004212, not so great on lda [$00]. Enjoy MMX v1.0 Chill Penguin stage.

DMA does not consume any CPU time.DRAM refresh is non-existent. Different memory access speeds do not exist. The S-PPU field bit was not implemented until v1.51, which would deadlock all of my timing tests.

The S-CPU runs 40% faster than a real CPU, because you're more likely to break a game by running too slow than by running too fast.

Unlike NESticle, where people hacked NES ROMs to run in it, the hacks are stored internally. Even when you think you've found them all, you miss the "hidden" ones, like for Uniracers. It knowingly behaves wrong on OAM address reset to get the game to have the right value to work, and this affects every game instead of just one.

The S-DSP never writes to the echo buffer at all, it keeps its own internal one.

And it wouldn't be a "byuu post" if I didn't bring up that I first reported the VRAM write during active display bug in 1998. It's a one-line fix.

I'm also somewhat disappointed with the direction of Snes9X v1.52. They went with blargg's accurate DSP core, but they paired it with opcode-based CPU and SMP cores, largely negating its merit (try Earthworm Jim 2.) A much better accuracy to performance tradeoff would have been a cycle CPU core with blargg's fast DSP or anomie's DSP. 9X is now "only" ~80% faster than bsnes, but not much more accurate than when it used to barely compete with ZSNES on speed.

And of course, my emulator is slow as a snail and the GUI+drivers are buggy as all hell. Thanks to Qt there's a new mystery bug with every build.

We really, really, really need some new blood.

The S-CPU does not support FastROM memory access. When you turn it on, it simply uses a different lookup table that takes one less cycle for every opcode, even if that opcode never accesses any FastROM regions, or even if it accesses it multiple times (eg 16-bit RMW).

You'd cringe if you saw my ARM emulator then. All LDR/STR ops take the same number of cycles regardless of whether they access ROM or DTCM, and whether they are part of a chain of sequential accesses or not.
My swiWaitVblank emulation simply adds to the cycle counter the number of remaining cycles until the next vblank and returns immediately.
But accuracy was never a goal of that project - speed was (which in retrospect should've made me go dynarec instead of interpreting).

Speaking of zSNES, it has another major flaw: no debugger. None that I've seen anyway. At least Snes9x has a mod that contains a debugger, but it doesn't help much when the emulator emphasizes compability with the existing library of commercial games rather than accuracy.

ZSNES has a debugger, but whoever converted it to ncurses completely ruined it in trying to make it portable.

Get v1.42 for DOS and run in DOSbox. "zsnes -d romname.sfc"
I personally think it's a fantastic debugger, and it's how I did all my ROM hacking for seven years. I much prefer it to Geiger's, probably because I don't have to be on Windows or Wine.

But accuracy was never a goal of that project - speed was (which in retrospect should've made me go dynarec instead of interpreting).

Yeah, I always come off as an ass with these rants. If the goal is speed, then they did an even better job than NESticle. ZSNES is the only way to go when you want to game on your Packard Bell Navigator. 9X is the only way to go for your PSP.

They both definitely have their places. Accuracy and development are not two of them. And if people would understand this and stop comparing two entirely different goal emulators, I would have a much more enjoyable experience in this community.

byuu wrote: Yeah, I always come off as an ass with these rants. If the goal is speed, then they did an even better job than NESticle. ZSNES is the only way to go when you want to game on your Packard Bell Navigator. 9X is the only way to go for your PSP.

Which reminds me of this email that someone sent to Bloodlust back in 1997:

Hello, this is a question.

you do nots think to make a SNESTLICLE or think to make it?

if make it make please it but that they could so that run to a speed 100 % in a pentium to 133 MHz with 16MB of RAM, make it it but similar to nesticle that for my the best emulator.

Ahh and that good has sound as nesticle.

Thanks and I wait a good response.

I guess it doesn't matter that snes9x is displaying a screen full of garbage, just as long as it works on bsnes.

As long as it works on all revisions of the Super NES, it's fine. Any difference between the Super NES and an emulator is either a defect in the emulator (for emulators intended to work on current desktop PCs) or a tradeoff (for emulators intended to work on handheld or set-top devices). If you can arrange the garbage to spell "Use a real SNES" in the snesticle-class emulators, that might help drive the point home.

Yes, test on hardware if you can. Otherwise, make sure you initialize absolutely every register and memory device (just to be safe, avoid the randomness of real hardware on power-on), and make sure it works in bsnes. If it works on hardware but not any emulator, don't care to the emulator.

byuu wrote: S-CPU open bus is faked. It returns address>>8 because that is faster than storing the MDR after each successful read. Works great on lda $004212, not so great on lda [$00]. Enjoy MMX v1.0 Chill Penguin stage.

What happens exactly? Never heard of this before but I'd heard of many other ZSNES accuracy issues in the past.

Health power ups vanish as soon as soon as they hit the ground.
Shooting certain objects in the CP stage takes you to the password screen.
This happens in the v1.0 ROM, not the v1.1 ROM. Some people think it was anti-piracy that got removed (maybe it was falsely triggering sometimes); others think it's a game glitch. I personally think I'm too lazy to find out or care which one it was :P

Speedy Gonzales 6-1 switch was the best. It reads from open bus in a loop, and even standard open bus isn't enough. You have to allow for an edge case where HDMA triggers right before the address read, so the HDMA routine will eventually fetch the byte that will break you out of the loop after a few hundred passes :D

Any difference between the Super NES and an emulator is either a defect in the emulator (for emulators intended to work on current desktop PCs) or a tradeoff (for emulators intended to work on handheld or set-top devices)

I like that. If an emulator wants to be correct but makes a mistake it's a defect, so you can say "I'm only worried about speed" and ignore all emulation issues, even the ones that have virtually no impact on speed, and now it's a tradeoff :)
Nobody does that, but it sounds like a fun solution. I should do that with my performance core when it gets a bit faster.