Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator

This would be possible in most cases, but the SNES throws another problem at you: the video renderer can set flags that can affect the operation of the CPU. Range/tile over sprite flags, H/Vblank signals, etc.

In my model, I chose to forgo timestamps because they are very tricky to get right with subtle details. Instead, I render one pixel at a time, but I use a cooperative threading model. Whenever the CPU reads something from the PPU, it checks to see if the CPU is currently not caught up with the PPU. If so, it will switch and run the PPU. The PPU does the same with respect to the CPU.

Even with that, all the extra overhead of being -able- to process one pixel at a time knocks the framerate from ~240fps to ~100fps. And it fixes maybe a half-dozen minor issues in games for all that overhead.

This is because scanline-based renderers are notoriously good at working around these issues. There are lots of games that do a mid-scanline write in error, but only a few that do more than one on the same scanline. So all you have to do is make sure you render your line on the correct 'side' of the write. We actually took every game we could find with this issue, and averaged out the best possible position within a line to run the highest number of games correctly. Other emulators take that further and can make changes to that timing on a per-game basis to fix even more issues.

Air Strike Patrol's shadow is actually the only known effect where two writes occur on the same line, and there is no one point that would render the line correctly.

I never intended to convey that this is a new idea, sorry. I do believe my cooperative threading model is a new concept in emulation, but it's still a ridiculously old one in computer science.

> The NES scene in particular ...

... is not as rosy as it seems. Having recently written an NES emulator, I can tell you that they're far from completion. For just one example, all of those mapper chips are basically a big unknown. Those chips have ways of detecting scanline edges to simulate IRQs and split-screen effects. This is done by monitoring the bus for certain patterns from the cart-side. And the details of this stuff? Completely unknown. Not even Nestopia nor Nintendulator attempt to simulate this: they just have the PPU -tell- the mapper when a scanline edge is hit. I could be wrong, but I believe I'm the first to even attempt to have the mapper detect scanlines by monitoring the bus.

And we're talking chips that are dozens of times less complex in the worst case than some of the SNES coprocessors.

> It's no longer the 90s and people shouldn't even have to mention NESticle existed in an article unless they're that out of touch with trends of the last decade.

The important part of that article is that the SNES was (and largely still is) in the NESticle phase of development, which was the purpose of bsnes. Unfortunately, just as we go from NESticle (25-50MHz) to Nestopia (800MHz required); ZSNES (200MHz) to bsnes (2-3GHz) needs a huge jump. But this time, that jump is hitting the wall of where most computer users are at. While people didn't notice Nestopia because everyone has at least a 1GHz processor these days, bsnes was not so fortunate.

So the article was more about explaining what that level of overhead is required for.