Errata

This page describes quirks in the SNES hardware that programmers need to be aware of. They could be mistakes in the hardware's implementation, or just unintuitive behavior.

Video

• Offset-per-tile never affects the first (leftmost) tile. This is to compensate for a horizontal scroll with a partial column on each end, allowing all 33 visible tiles to have a unique offset.
• When color math is set to affect sprites, it will only affect sprites using the last four palettes.
• If the program changes the vblank NMI from disabled to enabled through NMITIMEN bit 7 while the vblank flag (RDNMI bit 7) is set, an NMI will trigger immediately. This can cause NMI to occur other than at the start of vblank, or cause more than one NMI in a single vblank, as long as it is still during vertical blanking and the program has not yet read RDNMI. (Workaround: Read RDNMI shortly before enabling NMIs.)
• When there are too many sprite slivers on a scanline, the SNES will drop the highest priority slivers instead of the lowest priority ones.
• The SNES programming manual describes a situation where the Time Over flag is erroneously set when the first hardware sprite is 16x16, 32x32, or 64x64, has a horizontal position of 0-255, and other hardware sprites have negative horizontal positions.
• The SNES programming manual says that a hardware sprite should not have its horizontal position set to -256 ($100).
  • Sprites with an X coordinate -256 ($100) will erroneously count towards 32 sprites per scanline limit.
  • When a sprite has an X coordinate -256 ($100), all tile-slivers in the sprite count towards the 34 slivers per scanline limit.
• INIDISP (register $2100) problems
  • Changing the brightness is not instant. On a 3-chip SNES, it may only take a few pixels to change the brightness, but on a 1-chip SNES it may be a gradual fade that takes 72 pixels or more.
    • This can be a problem for games that extend vblank by disabling rendering and enabling it several scanlines into the frame. For this use-case, it's recommended to disable rendering by writing $8F (or $80 ORed with whatever the desired brightness is) to INIDISP instead of $80, so that the brightness is not changed as rendering is enabled.
  • INIDISP early read bug: When INIDISP is written to, the PPU doesn't wait for the value to be put on the bus before attempting to read it. This means that the SNES will end up rendering about one pixel where INIDISP has been set to whatever was on the data bus before the correct value. For instructions that don't use indirect addressing, this will likely be the last byte of the instruction.
    • Workaround: Use long addressing to write to INIDISP during rendering, and take advantage of how PPU registers are available in many different banks. STA $8F2100 will put $8f on the bus before the written value, and STA $0F2100 will put $0f on the bus before the written value, and so on.
• The unofficial 16x32 and 32x64 pixel sprite sizes have quirks.
  • 16x32 sprites do not work correctly with OBJ interlacing
    • When OBJ interlacing is on, 16x32 sprites are treated as if they are 16x16 - the bottom 16x16 is ignored, and the top 16x16 is squished into 16x8. 32x64 sprites behave as expected.
  • 16x32 and 32x64 sprites do not handle being vertically flipped correctly.
    • When a 16x32 or 32x64 sprite is vertically flipped, the top half and the bottom half will flip independently, as if the sprite were really two 16x16 sprites or two 32x32 sprites that are vertically adjacent to each other.

Audio

• The gauss interpolation table has some mistakes in it
• The SNES programming manual warns that writing to the first two SPC700 communication registers ($2140 and $2141) with a 16-bit write can also write to $2143
  • This may be difficult to trigger or perhaps not actually exist
• Writing to SPC700 communication registers ($2140, $2141, $2142, $2143) at the same time the other processor reads it can result in incorrect data being read.
  • A SPC700 program may want to read twice and only proceed when two subsequent reads have the same value.
• The hardware noise unit uses the contents of an LFSR to generate a signed noise sample. Because the LFSR only shifts 1 bit per sample, the correlated lower bits end up producing a strong highpass filter effect on the noise. Especially in the high and low ranges, this will differ from the more typical 1-bit LFSR noise sound seen in other sound chips.

SPC-700

• The TSET1 (Test and set bits) and TCLR1 (Test and clear bits) instructions does an equality test (z/n flags = ALU(A - old_value)), not a bit test.
• The flags modified by the MUL (Multiply) instruction are based on the Y register (high-byte) value only..
• The output of the DIV (Divide) instruction is only valid if the quotient is <= 511 (9 bit result).
• The z/n flags modified by the DIV (Divide) instruction are based on the A register (bits 0-7 of quotient) value only.

5A22

• Starting a multiplication ($4203 WRMPYB) or division ($4206 WRDIVB) while the 5A22 is still processing a previous multiplication or division can cause the 5A22 to output erroneous values to RDDIV and/or RDMPY.

Mode 7 multiplier

• The Mode 7 multiplier (MPY) result can be corrupted if an interrupt or HDMA transfer writes to a BG1 scroll register or Mode7 Matrix register in-between the two M7A writes. (The Mode7 scroll and Mode 7 matrix registers share the same write-twice latch).

65c816

• Setting the index register to 8-bit (via SEP, PLP or XCE) will clear the high byte of X and Y.
  • When saving/restoring registers in an ISR, you should switch to 16-bit Index and Accumulator before pushing or popping the stack.
• The JMP (addr) and JMP [addr] instructions read from Bank 0 (ie, JMP ($1234) will read 2 bytes from $00:1234)
• The JMP (addr,x) and JSR (addr,x) instructions read from the Program Bank (PB) (ie, JSR ($1234,x) will read 2 bytes from PB:{$1234 + X})
• The MVN and MVP instructions will change the Data Bank (DB) to the destination bank.
• The syntax and operand order of the MVN and MVP instructions vary across assemblers.

DMA

• Some A-Bus addresses are invalid:
  • The A-Bus address cannot access a B-Bus address ($21xx)
  • The A-Bus address cannot access the MMIO or DMA registers ($4000-$41ff, $4200-$421f, $4300-$437f)
  • The A-Bus address cannot be a Work-RAM address if the B-Bus address is WMDATA ($2180). This means DMA cannot be used to copy from one section of the SNES's RAM to another.
• On version 1 of the 5A22 chip ("S-CPU"), the chip can crash if DMA finishes right before HDMA happens. This is generally only a problem for games that want to use DMA to clear WRAM or copy data from a coprocessor to WRAM, as that's the main reason to use DMA during rendering.
• On version 2 of the 5A22 chip ("S-CPU-A"), a recent HDMA transfer to/from INIDISP (Meaning that BBADn is set to zero $00) can make a DMA transfer fail. Nothing will happen and the DMA size registers (DASnL, DASnH) will be unchanged, instead of zero like they normally are after a DMA has been completed.
  • Workaround: Set BBADn to $ff instead, and set the transfer pattern to 1. This will cause HDMA to write to $21ff (nothing) and then $2100 (INIDISP). Both bytes should be set to the same value to prevent the INIDISP early read bug.
  • S-CPU (the first version), S-CPU-B and the 1-CHIP SNES are not affected by this bug.
• HDMA can fail if a DMA transfer ends when HDMA starts (just after the start of scanline 0) and the previous value read by DMA is 0.
  • When this glitch occurs the HDMA channel stops at the start of scanline 0 and there are no H-Blank transfers for an entire frame.
• Enabling a HDMA channel (writing a non-zero value to HDMAEN) outside of the Vertical-Blanking period (even when the screen is disabled) can cause unwanted erroneous writes to the PPU.
  • At the start of scanline 0, the DMA controller initialises HDMA state registers (A2An, NLTRn) for only the active HDMA channels.
  • Enabling a HDMA channel outside of VBlank, without setting the HDMA state registers, will cause the DMA controller to read HDMA table entries from an erroneous memory address.

Input

• Automatic controller reading begins between H=32.5 and H=95.5 of the first vblank scanline. This means that checking HVBJOY ($4212) is not quite sufficient to avoid an in-progress auto-read if used immediately after the start of vblank.
• Autoread result may change unexpectedly during a lag frame. Either copy it to a variable or disable autoreading while game logic is running.

References

• https://undisbeliever.net/snesdev/registers/inidisp.html#glitches-and-hardware-bugs
• SNES Development Manual Book 1, section 2-25-1: Documented Problems