Is it odd if a NES emulator is on average 2x slower than snes9x? My NES emulator is cycle accurate (rendering 3 pixels for each CPU cycle, even mid instruction, but I'm not sure thats the issue here.)
That's because Snes9x isn't cycle-accurate. Try bsnes, or higan as it's called now. bsnes is going to be FAR slower than your NES emulator.
Even being cycle accurate though, that alone is enough to make it twice as slow?
From what I've heard, Snes9x is way far from accurate, so I bet it takes all kinds of shortcuts in order to improve performance.
Does Higan even emulate the NES?
Are SNES emulators even as equivalently accurate as NES ones regarding the PPU? I don't think there's a decap of the SNES PPUs, and even before that I don't think there was(/is?) anything at the detail level of that about the NES PPU. That is, all the things that happen on each dot, all the internal shift registers, buffers, etc. This is partly because SNES games aren't as varied in how they access the PPU mid-frame, so the detailed information isn't needed to emulate those games correctly. For example, I believe that it was only in the past few years that mid-scanline timing was handled properly in bsnes/higan, to fix a game that did the shadow with mid-scanline timed writes.
I think that given emulation at the same accuracy level, a SNES emulator should be slower. It has two CPUs, two PPUs, a DSP, and multi-channel DMA with table-based mid-frame writes.
Dwedit wrote:
Does Higan even emulate the NES?
The old version of bsnes I found in my Linux distribution's repository emulates the NES.
blargg wrote:
I think that given emulation at the same accuracy level, a SNES emulator should be slower. It has two CPUs, two PPUs, a DSP, and multi-channel DMA with table-based mid-frame writes.
Worse yet, Game Paks have coprocessors that can sense cycle-level sync with the main CPU. It's not like the NES, where a mapper was pretty much just an
MMU possibly with a
PIT. Good luck
really emulating the Super FX.
> Does Higan even emulate the NES?
Yep, fairly well, too. Also does SNES, GB, GBC and GBA.
> Are SNES emulators even as equivalently accurate as NES ones regarding the PPU?
We don't know the exact points that everything happens. I was able to log some of it with some fancy test ROMs. In one instance, I read from the OAM data port on every possible cycle with a special sequence of bytes in OAM. It allowed me to see at which cycles the PPU fetched from it, and I copied that pattern. CGRAM seems to be just the raw color fetch for each pixel, easy stuff there. VRAM is completely disabled to CPU code, which is just lovely.
The overhead is from the synchronization level (the PPU cannot ever run ahead of the CPU no matter what), determining the exact positions of each fetch won't slow the emulation down, but will improve the accuracy. I would certainly welcome any help on this front. What's really needed is a logic analyzer.
> Worse yet, Game Paks have coprocessors that can sense cycle-level sync with the main CPU. It's not like the NES, where a mapper was pretty much just an MMU possibly with a PIT. Good luck really emulating the Super FX.
I emulate the SuperFX instruction cache (and it's 16x16 block fetching pattern), prefetch, ROM buffer cache, RAM buffer cache, primary pixel cache, secondary pixel cache, etc. Only issue I can't figure out is what to do when the secondary pixel cache fills up while the CPU is pegging the RAM non-stop: does it interleave draining the cache and executing cycles, does it stall out the pixel cache entirely, or does it stall out the CPU entirely?
The SA-1 is by far the worst. It runs at 10.7MHz, and has a special bus master chip. Both the SNES CPU and the SA-1 CPU can access the ROM and RAM on the cartridge. But if the SA-1 tries to access, or is already accessing, the same physical chip that the SNES accesses, the SA-1 CPU will stall/abort the current instruction, allow the SNES instruction to complete, and then try and read the data in again. To emulate that, I would have to -force- the SA-1 to step one cycle at a time, and watch what the SNES CPU is accessing each cycle.
Byuu wrote an article on this subject for arstechnica back in 2011. Definitely worth a read.
Accuracy takes power: one man's 3ghz quest to build a perfect snes emulator.