This page serves to document known instances where bsnes emulation does not match observed results of hardware. Typically, things listed here are not emulated due to lack of understanding of how the hardware works. This is usually due to the massive difficulty of reverse engineering said behaviors.
NMI has priority over IRQ, which has priority over BRK / COP. When a higher priority interrupt is triggered, interesting things happen to the (pseudo-) opcode, depending upon which cycle it has reached. If the interrupt happens early enough, the vector load address will be overridden, and the original interrupt will not occur. If it happens too late, the new interrupt will occur before the old interrupt, and when it finishes, the old interrupt will complete. At least, that is the theory. Exact details are not known, and have not been tested at this time. Fixing the interrupt pseudo-opcode delay takes priority over this, as perfect interrupt timing will be needed to properly test this edge case.
Assume PIO.d7 is set. Clearing PIO.d7 will then latch counters and disable future latching behavior. Once PIO.d7 is re-enabled, if SLHV is read immediately afterward, counters will not latch again. There is a hardware delay, that is at most 28 clocks, before reading SLHV will latch the counters again.
Exact length and cause of this behavior is unknown.
After writing to WRMPYB / WRDIVB, calcuation is started by hardware. Multiplication takes roughly 48 clocks, and division roughly 96. Attempting to read RDMPY* / RDDIV* before the calculation has completed returns partially calculated (eg incorrect) results.
The exact delay between each seems to vary based upon which clock cycle the operation was started on, suggesting an internal clock divider mechanism. It also seems to vary based upon the input WRMPY* / WRDIV* values.
If HDMA begins immediately after DMA terminates on a revision 1 CPU, very bizarre things happen, and often the entire machine will lock up. This bug was fixed on SNES CPU revision 2 hardware.
The exact behavior that occurs when this bug is triggered is virtually impossible to determine. The effect can be simulated by locking emulation, but this is highly undesirable.
Perhaps after adding a dialog to select processor revisions, it would be appropriate to emulate this hardware bug.
The S-PPU is emulated using a scanline-based renderer. This is so inaccurate that there is no point in even listing errata. It is sure to be an endless list. This section will be started if and when bsnes gains a clock-based PPU renderer.
The reason work has not begun on this yet is because it will require massive amounts of CPU power. A rough estimate is that the emulator will run roughly 3-5x slower with a clock-based PPU renderer. With the emulator already being as processor intensive as it is, it is more worthwhile to perfect the other processors before relegating bsnes to an even greater niche, where no testing will occur by end users.
It is known that if the S-SMP accesses CPUIO* at roughly the same time that the S-CPU accesses APUIO*, bus conflicts will occur that result in what appears to be bitwise ORed data to be read back.
I have quite literally permanently killed a copier by attempting to test this behavior to get more information. Though it may have been one amazing coincidence, due to the enormous cost of these devices, I am unwilling to attempt to test this behavior again to get more information.
If TnTARGET is changed immediately after stage 1 tick, and the written value matches the new stage 2 counter value, a glitch will sometimes occur that will cause the counter to be set to a pseudo-random value.
The most difficult part of emulating this behavior is the pseudo-random nature of the glitch. It's also a very bad idea to implement true randomization into the core of an emulator. Current thoughts are to emulate this using a PRNG that will re-seed to a fixed value upon reset; however this will not properly emulate the pseudo-random behavior of hardware, as the source of the "randomness" is not currently known.
It appears that enabling mute will cause a pulse of some sort for ~37 samples before actually taking effect. Currently, emulation will perform mute immediately.