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. Both the SNES CPU and the SA-1 CPU can access the ROM and RAM on the cartridge. It runs at 10.7MHz, and has a special bus master chip. 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? 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. It's not like the NES, where a mapper was pretty much just an MMU possibly with a PIT. > Worse yet, Game Paks have coprocessors that can sense cycle-level sync with the main CPU. What's really needed is a logic analyzer. I would certainly welcome any help on this front. 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. VRAM is completely disabled to CPU code, which is just lovely. CGRAM seems to be just the raw color fetch for each pixel, easy stuff there.
#Bsnes vs snes9x full#
Id use bsnes for LPs as well, but I can rarely get it to run at full speed in tandem with Camtasia Studio and its screen recorder.
It allowed me to see at which cycles the PPU fetched from it, and I copied that pattern. I use SNES9X for most LPs and for ripping SPCs, and I use bsnes (currently, 0.80-compatibility) for pretty much everything else. This page is powered by a knowledgeable community that helps you make an informed decision. 'Built-in audio capture' is the primary reason people pick ZSNES over the competition. In one instance, I read from the OAM data port on every possible cycle with a special sequence of bytes in OAM. ZSNES, Higan (Formerly BSNES), and SNES9X are probably your best bets out of the 6 options considered. I was able to log some of it with some fancy test ROMs. We don't know the exact points that everything happens. > Are SNES emulators even as equivalently accurate as NES ones regarding the PPU?