[Sanddancer]

Good emulation is hard, especially when you're dealing with code that was built around the bugs, quirks, and timing issues that the original SNES authors had to deal with. Then you have to worry about buggy software that works because of undefined behavior [1, see Speedy Gonzales]. More recent emulators have focused more on correctness than speed, because it means less work trying to patch and hack around broken games.

[1] http://helmet.kafuka.org/state3.html

[khedoros]

I definitely know that. I've done work on an NES emulator, and a lot of the software uses the hardware in undocumented ways, like odd timing quirks, undocumented CPU opcodes, changing display registers mid-frame to achieve special effects, etc.

I've looked at the SNES and N64's hardware to consider contributing to an emulator for one of them, and the hardware certainly doesn't get simpler as time goes on ;-)

The comparison I was making isn't really fair, anyhow. Corn was fast, but the last revision only really covered two commercial games (Mario and Zelda). I'm sure that they heavily optimized for the code patterns in those specific games, without regard to accurate emulation of the hardware in the general case. Expand the supported cases and the problem immediately becomes much harder. Comparing Corn to an accuracy-focused emulator is like comparing one of the cut-down, portable-friendly SNES9x builds to Higan.