Accurate NES Emulation

neo_bahamut1985 · Post by **neo_bahamut1985** » Mon Mar 24, 2008 12:46 pm

Okay, this is getting WOT; let's end this whole Snes9x thing, hmm? I just didn't know the current state, that's all.

ZH/Franky · Post by **ZH/Franky** » Mon Mar 24, 2008 4:27 pm

Hey, forgive me if this sounds stupid, but I've just thought of something.

Emulators are liars; the game expects to be run on hardware, but it runs on different hardware and something is fooling it into thinking it is running where it wants to run. So, bsnes is one of the biggest liars of all time

(because it's the best SNES emulator at the moment, it's better able to make the game think it is in the place it's meant to be).

So, emulators that don't emulate a console very well (i.e. when most games don't run because they become aware that they aren't in the right place) are either quite honest, or crap at lying.

(Heh, now I feel sorry for most of the games I play, they are being lied to all the time).

byuu · Post by **byuu** » Mon Mar 24, 2008 4:46 pm

Snes9x already has a updated sound core....

It's still fairly flawed. It's not as up-to-date as even anomie's old 32KHz core, and crashes (locks up) quite frequently in eg Der Langrisser. Some people don't see it with the v1.5x series, but some do.

WTF are you smoking? SNES9x is as active as the ZSNES emulator.

ZSNES active developers (in no particular order):
- pagefault (core developer)
- Deathlike2
- grinvader
- Jonas Quinn
- Nach
- others?

Snes9X active developers:
- zones
- Contributions from Nach

Snes9X lacks a lead maintainer who can perform radical changes to the core (eg replacing the 65816 CPU emulator with a newer one.)

Wait a minute, you want to reproduce bugs in the hardware? why?
wouldn't it be better to emulate a SNES where these bugs are fixed?

The bug I mentioned was the HDMA conflict glitch. What happens is that on the first revision SNES hardware, the entire system would lock up when DMA occurred / terminated near HDMA start.

Nintendo realized this, and fixed the bug in their next CPU revision. They also merged some ICs for cost savings. The SNES units look the same on the outside, but have different PCBs on the inside.

Though it would have been ideal to keep all hardware revisions 100% identical (which is the only real advantage of a console over a computer), they decided to fix this. Presumably because there were already commercially released games that were triggering this bug on occasion.

In order to license an SNES game for sale, Nintendo would have QA testers run the games to make sure they'd work on all hardware revisions, so the differences were mostly mitigated. The bugfix would just help out for those very rarely occurring glitches QA couldn't catch. Sucks to be you if you have a first revision system and hit one of those.

Now, the problem today is that we have ROM hackers who don't know about these limitations. Just recently, one sent me a test ROM that worked on real hardware but not on bsnes. That was due to some DMA WRAM<>WRAM limitations which I've fixed, but there was another problem with his hack: he was triggering the HDMA conflict bug, so it was in fact crashing on my SNES hardware unit.

So, think of it like this: we emulate the hardware to be a perfect mirror. If we cannot do so, then we make the emulator have tighter restrictions than hardware, never looser. By doing so, we know that if a game runs on an emulator, it will run on real hardware.

See bsnes' readme.txt for a list of cases where bsnes violates this rule.

Johan_H · Post by **Johan_H** » Mon Mar 24, 2008 9:44 pm

Gil_Hamilton wrote: The best example is the NES 8-sprite limit. It's used in a handful of games to create graphical effects.

Neat, can you give an example?

blargg · Post by **blargg** » Mon Mar 24, 2008 10:20 pm

Oh no, this is turning into another bsnes thread...

Ninja Gaiden uses the NES sprite limit in some cinemas to mask the sprites outside the letterboxed image strip.

ZH/Franky · Post by **ZH/Franky** » Mon Mar 24, 2008 10:22 pm

Ninja Gaiden is an awesome game. I suggest you all go play it.
(Btw, this is my thread so I make the rules; I don't mind if it turns into another bsnes thread

)

byuu · Post by **byuu** » Mon Mar 24, 2008 11:10 pm

blargg wrote:Oh no, this is turning into another bsnes thread...

Hahahaha, so true. Sorry, I always do that. Talk about what you know and all that I guess ;)

franpa · Post by **franpa** » Tue Mar 25, 2008 1:25 am

I thought snes9x was introducing a new hybrid sound core after 1.51's release?

Snark · Post by **Snark** » Tue Mar 25, 2008 9:39 am

Franky wrote:
byuu wrote:After that, CPU mul/div partial results would be a nice 3-6 month excursion, and then we could try and simulate bus conflicts and hardware bugs (eg CPUr1 HDMA lockup.)
Wait a minute, you want to reproduce bugs in the hardware? why?
wouldn't it be better to emulate a SNES where these bugs are fixed?

*slaps forehead*

blargg · Post by **blargg** » Tue Mar 25, 2008 10:21 am

Franky wrote:Wait a minute, you want to reproduce bugs in the hardware? why? wouldn't it be better to emulate a SNES where these bugs are fixed?

Bugs are a human notion. The only way to tell if something is a bug is if it differs from what's documented to happen, or if the behavior seems wrong, all human notions. The SNES and game code make no distinction. Buggy behavior is no different than correct behavior; it's all behavior that games can and do depend on. Point fingers all you like, if an emulator wants to run games the same as they run on the SNES, it must make no distinction between buggy and correct behavior, instead emulating it all as closely as possible.

Fixing bugs would be ill-advised even for later versions of the SNES hardware, for the same reason. Consoles, especially older ones, have the advantage of very little change to the hardware, allowing games to use every nuance and quirk of the hardware. Even modern consoles still offer an advantage of a consistent platform, as compared to a general-purpose PC.

declan · Post by **declan** » Tue Mar 25, 2008 10:27 am

Franky wrote:Hey, forgive me if this sounds stupid, but I've just thought of something.

Emulators are liars; the game expects to be run on hardware, but it runs on different hardware and something is fooling it into thinking it is running where it wants to run. So, bsnes is one of the biggest liars of all time
(because it's the best SNES emulator at the moment, it's better able to make the game think it is in the place it's meant to be).

So, emulators that don't emulate a console very well (i.e. when most games don't run because they become aware that they aren't in the right place) are either quite honest, or crap at lying.

(Heh, now I feel sorry for most of the games I play, they are being lied to all the time).

You are quite the philosopher Franky

franpa · Post by **franpa** » Tue Mar 25, 2008 10:34 am

Lol even i dont post that bad anymore.. i hope.

FirebrandX · Post by **FirebrandX** » Tue Mar 25, 2008 11:39 am

Johan_H wrote:
Gil_Hamilton wrote: The best example is the NES 8-sprite limit. It's used in a handful of games to create graphical effects.
Neat, can you give an example?

I'd say the most classic example is Legend of Zelda, when Link walks through the top and bottom doors in a labyrinth. If you turn off sprite limit, his body appears over the door frame. I remember I originally thought this was a bug in the emulator, but didn't realize I had turned off sprite limit.

blargg · Post by **blargg** » Tue Mar 25, 2008 12:12 pm

Franky wrote:Emulators are liars; the game expects to be run on hardware, but it runs on different hardware and something is fooling it into thinking it is running where it wants to run.

Looked at another way, games simply expect that when they do X, they get Y in response. The SNES hardware responds appropriately, and an accurate emulator does as well. As far as the game is concerned, both are identical, so it performs the same. But I guess I usually avoid anthropomorphizing computers, since they hate it.

This concept of expectations and responses is the basis for the many kinds of interfaces in a computer, like APIs (high-level application interfaces), ABI (low-level machine language-level interface), and hardware interfaces like USB or memory. All these reduce things to their essence, allowing a wider variety of things to be interfaced with each other, since each depends on no more than necessary.