Anomie_regs.log

=============================================================================
 Anomie's Register Doc
 $Revision: 1157 $
 $Date: 2007-07-12 16:39:41 -0400 (Thu, 12 Jul 2007) $
 <anomie@users.sourceforge.net>
=============================================================================


REGISTERS
=========

Addr rw?fvha Name
        bits

        Explanation

"Addr" is the address this register is mapped into the SNES memory space.
"Name" is the official and unofficial name of the register
"bits" is either 8 or 16 characters explicating the bitfields in this register.

The flags are:
rw?fvha
||||||+--> '+' if it can be read/written at any time, '-' otherwise
|||||+---> '+' if it can be read/written during H-Blank
||||+----> '+' if it can be read/written during V-Blank
|||+-----> '+' if it can be read/written during force-blank
||+------> Read/Write style: 'b'     => byte
||                           'h'/'l' => read/write high/low byte of a word
||                           'w'     => word read/write twice (low then high)
|+-------> 'w' if the register is writable for an effect
+--------> 'r' if the register is readable for a value or effect (i.e. not
            open bus).

To find the entry for a particular register, search for the register number
(i.e. '2100') at the very beginning of the line. Note that the DMA registers
are combined, so e.g. to find $4300, $4310, $4320, $4330, $4340, $4350, $4360,
or $4370 you'd search for '43x0'.

For most registers (and most undefined bits of readable registers), the
returned value is Open Bus, that is the last value read over the main bus from
the ROM (typically part of the opcode arguments or the indirect base address).

Registers matching $21x4-6 or $21x8-A (where x is 0-2) return the last value
read from any of the PPU1 registers $2134-6, $2138-A, or $213E. This is known
as PPU1 Open Bus. Similarly, PPU2 Open Bus involves reading registers $213B-D
or $213F (NOT $21xB-D though).

Note that it may be possible to write registers anytime even if marked '-', but
until we have proof '-' is a better guess.

--------------------------------------------------------------------------------

        rw?fvha
2100    -+b++++ INIDISP - Screen Display
        
        x---bbbb

        x    = Force blank on when set.
        bbbb = Screen brightness, F=max, 0="off".

        Note that force blank CAN be disabled mid-scanline. However, this can
        result in glitched graphics on that scanline, as the internal rendering
        buffers will not have been updated during force blank. Current theory
        is that BGs will be glitched for a few tiles (depending on how far in
        advance the PPU operates), and OBJ will be glitched for the entire
        scanline.

        Also, writing this register on the first line of V-Blank (225 or 240,
        depending on overscan) when force blank is currently active causes the
        OAM Address Reset to occur.

--------------------------------------------------------------------------------

        rw?fvha
2101    -+b++?- OBJSEL - Object Size and Chr Address
        
        sssnnbbb

        sss  = Object size:
            000 =  8x8  and 16x16 sprites
            001 =  8x8  and 32x32 sprites
            010 =  8x8  and 64x64 sprites
            011 = 16x16 and 32x32 sprites
            100 = 16x16 and 64x64 sprites
            101 = 32x32 and 64x64 sprites
            110 = 16x32 and 32x64 sprites ('undocumented')
            111 = 16x32 and 32x32 sprites ('undocumented')

        nn   = Name Select
        bbb  = Name Base Select ( Word Addr >> 13, Byte Addr >> 14)
            See the section "SPRITES" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2102    -+l++?- OAMADDL - OAM Address low byte
2103    -+h++?- OAMADDH - OAM Address high bit and Obj Priority
        
        p------b aaaaaaaa

        p    = Obj Priority activation bit
            When this bit is set, an Obj other than Sprite 0 may be given
            priority. See the section "SPRITES" below for details.

        b aaaaaaaa = OAM address
            This can be thought of in two ways, depending on your conception of
            OAM. If you consider OAM as a 544-byte table, baaaaaaaa is the word
            address into that table. If you consider OAM to be a 512-byte table
            and a 32-byte table, b is the table selector and aaaaaaaa is the
            word address in the table. See the section "SPRITES" below for
            details.
        
        The internal OAM address is invalidated when scanlines are being
        rendered. This invalidation is deterministic, but we do not know how
        it is determined. Thus, the last value written to these registers is
        reloaded into the internal OAM address at the beginning of V-Blank if
        that occurs outside of a force-blank period. This is known as 'OAM
        reset'. 'OAM reset' also occurs on certain writes to $2100.

        Writing to either $2102 or $2103 resets the entire internal OAM Address
        to the values last written to this register. E.g., if you set $104 to
        this register, write 4 bytes, then write $1 to $2103, the internal OAM
        address will point to word 4, not word 6.

--------------------------------------------------------------------------------

        rw?fvha
2104    -+b++-- OAMDATA - Data for OAM write
        
        dddddddd

        Note that OAM writes are done in an odd manner, in particular
        the low table of OAM is not affected until the high byte of a
        word is written (however, the high table is affected
        immediately). Thus, if you set the address, then alternate writes and
        reads, OAM will never be affected until you reach the high table!

        Similarly, if you set the address to 0, then write 1, 2, read, then
        write 3, OAM will end up as "01 02 01 03", rather than "01 02 xx 03" as
        you might expect.

        Technically, this register CAN be written during H-blank (and probably
        mid-scanline as well). However, due to OAM address invalidation the
        actual OAM byte written will probably not be what you expect. Note that
        writing during force-blank will only work as expected if that
        force-blank was begun during V-Blank, or (probably) if $2102/3 have
        been reset during that force-blank period.

        See the section "SPRITES" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2105    -+b+++- BGMODE - BG Mode and Character Size
        
        DCBAemmm

        A/B/C/D = BG character size for BG1/BG2/BG3/BG4
            If the bit is set, then the BG is made of 16x16 tiles. Otherwise,
            8x8 tiles are used. However, note that Modes 5 and 6 always use
            16-pixel wide tiles, and Mode 7 always uses 8x8 tiles. See the
            section "BACKGROUNDS" below for details.

        mmm  = BG Mode
        e    = Mode 1 BG3 priority bit
            Mode     BG depth  OPT  Priorities
                     1 2 3 4        Front -> Back
            -=-------=-=-=-=----=---============---
             0       2 2 2 2    n    3AB2ab1CD0cd
             1       4 4 2      n    3AB2ab1C 0c
                        * if e set: C3AB2ab1  0c
             2       4 4        y    3A 2B 1a 0b
             3       8 4        n    3A 2B 1a 0b
             4       8 2        y    3A 2B 1a 0b
             5       4 2        n    3A 2B 1a 0b
             6       4          y    3A 2  1a 0
             7       8          n    3  2  1a 0
             7+EXTBG 8 7        n    3  2B 1a 0b

            "OPT" means "Offset-per-tile mode". For the priorities, numbers
            mean sprites with that priority. Letters correspond to BGs (A=1,
            B=2, etc), with upper/lower case indicating tile priority 1/0. See
            the section "BACKGROUNDS" below for details.

            Mode 7's EXTBG mode allows you to enable BG2, which uses the same
            tilemap and character data as BG1 but interprets bit 7 of the pixel
            data as a priority bit. BG2 also has some oddness to do with some
            of the per-BG registers below. See the Mode 7 section under
            BACKGROUNDS for details.


--------------------------------------------------------------------------------

        rw?fvha
2106    -+b+++- MOSAIC - Screen Pixelation
        
        xxxxDCBA
        
        A/B/C/D = Affect BG1/BG2/BG3/BG4
        
        xxxx = pixel size, 0=1x1, F=16x16
            
            The mosaic filter goes over the BG and covers each x-by-x square
            with the upper-left pixel of that square, with the top of the first
            row of squares on the 'starting scanline'. If this register is set
            during the frame, the 'starting scanline' is the current scanline,
            otherwise it is the first visible scanline of the frame. I.e. if
            even scanlines are completely red and odd scanlines are completely
            blue, setting the xxxx=1 mid-frame will make the rest of the screen
            either completely red or completely blue depending on whether you
            set xxxx on an even or an odd scanline.

            XXX: It seems that writing the same value to this register does not
            reset the 'starting scanline', but which changes do reset it?

            Note that mosaic is applied after scrolling, but before any clip
            windows, color windows, or math. So the XxX block can be partially
            clipped, and it can be mathed as normal with a non-mosaiced BG. But
            scrolling can't make it partially one color and partially another.

            Modes 5-6 should 'double' the expansion factor to expand
            half-pixels. This actually makes xxxx=0 have a visible effect,
            since the even half-pixels (usually on the subscreen) hide the odd
            half-pixels. The same thing happens vertically with interlace mode.

            Mode 7, of course, is weird. BG1 mosaics about like normal, as long
            as you remember that the Mode 7 transformations have no effect on
            the XxX blocks. BG2 uses bit A to control 'vertical mosaic' and bit
            B to control 'horizontal mosaic', so you could be expanding over
            1xX, Xx1, or XxX blocks. This can get really interesting as BG1
            still uses bit A as normal, so you could have the BG1 pixels
            expanded XxX with high-priority BG2 pixels expanded 1xX on top of
            them.

        See the section "BACKGROUNDS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2107    -+b+++- BG1SC - BG1 Tilemap Address and Size
2108    -+b+++- BG2SC - BG2 Tilemap Address and Size
2109    -+b+++- BG3SC - BG3 Tilemap Address and Size
210a    -+b+++- BG4SC - BG4 Tilemap Address and Size
        
        aaaaaayx
        
        aaaaaa = Tilemap address in VRAM (Word Addr >> 10, Byte Addr >> 11)
        x    = Tilemap horizontal mirroring
        y    = Tilemap veritcal mirroring
            
            All tilemaps are 32x32 tiles. If x and y are both unset, there is
            one tilemap at Addr. If x is set, a second tilemap follows the
            first that should be considered "to the right of" the first. If y
            is set, a second tilemap follows the first that should be
            considered "below" the first. If both are set, then a second
            follows "to the right", then a third "below", and a fourth "below
            and to the right".
        
        See the section "BACKGROUNDS" below for more details.
        
        MoN Note: I changed the "writable during H-Blank" from '?' to '+' due to
        the same behavior observed both on a real system and in bsnes.
        How the change affects the PPU exactly is something the hardware experts should investigate.
        I might try designing an HDMA sequence to toy with this. It may already be known that this
        is writeable, as bsnes seems to replicate it well, though i don't know if it's a perfect copy.
        That is, whether the value written only takes effect during the next frame or during the
        current one.

--------------------------------------------------------------------------------

        rw?fvha
210b    -+b++?- BG12NBA - BG1 and 2 Chr Address
210c    -+b++?- BG34NBA - BG3 and 4 Chr Address
        
        "NBA" stands for "Name Base Address"
        
        bbbbaaaa
        
        aaaa = Base address for BG1/3 (Word Addr >> 12, Byte Addr >> 13)
        bbbb = Base address for BG2/4 (Word Addr >> 12, Byte Addr >> 13)
        
        MoN Note: It's interesting that these provide the capability to address
        farther than the amount of available VRAM (64K in two 32K chips).
        Since VRAM is word addressed, perhaps the designers of the PPU
        anticipated being able to use two 64K VRAM chips instead. It's just a
        thought. Perhaps word addresses $0000-$7fff were originally intended to
        be for tilemaps, and the CHR data would have had the added perk of
        being able to reside anywhere.
        
        See the section "BACKGROUNDS" below for details.


--------------------------------------------------------------------------------

        rw?fvha
210d    -+w+++- BG1HOFS - BG1 Horizontal Scroll
        -+w+++- M7HOFS  - Mode 7 BG Horizontal Scroll
210e    -+w+++- BG1VOFS - BG1 Vertical Scroll
        -+w+++- M7VOFS  - Mode 7 BG Vertical Scroll
        
        ------xx xxxxxxxx
        ---mmmmm mmmmmmmm
        
        x = The BG offset, 10 bits.
        m = The Mode 7 BG offset, 13 bits two's-complement signed.
        
        These are actually two registers in one (or would that be "4 registers
        in 2"?). Anyway, writing $210d will write both BG1HOFS which works
        exactly like the rest of the BGnxOFS registers below ($210f-$2114), and
        M7HOFS which works with the M7* registers ($211b-$2120) instead.
        
        Modes 0-6 use BG1xOFS and ignore M7xOFS, while Mode 7 uses M7xOFS and
        ignores BG1HOFS. See the appropriate sections below for details, and
        note the different formulas for BG1HOFS versus M7HOFS.
        
--------------------------------------------------------------------------------

        rw?fvha
210f    -+w+++- BG2HOFS - BG2 Horizontal Scroll
2110    -+w+++- BG2VOFS - BG2 Vertical Scroll
2111    -+w+++- BG3HOFS - BG3 Horizontal Scroll
2112    -+w+++- BG3VOFS - BG3 Vertical Scroll
2113    -+w+++- BG4HOFS - BG4 Horizontal Scroll
2114    -+w+++- BG4VOFS - BG4 Vertical Scroll
        
        ------xx xxxxxxxx

        Note that these are "write twice" registers, first the low byte is
        written then the high. Current theory is that writes to the register
        work like this:
          BGnHOFS = (Current<<8) | (Prev&~7) | ((Reg>>8)&7);
          Prev = Current;
            or
          BGnVOFS = (Current<<8) | Prev;
          Prev = Current;

        Note that there is only one Prev shared by all the BGnxOFS registers.
        This is NOT shared with the M7* registers (not even M7xOFS and
        BG1xOFS).

        x = The BG offset, at most 10 bits (some modes effectively use as few
            as 8).

        Note that all BGs wrap if you try to go past their edges. Thus, the
        maximum offset value in BG Modes 0-6 is 1023, since you have at most 64
        tiles (if x/y of BGnSC is set) of 16 pixels each (if the appropriate
        bit of BGMODE is set).

        Horizontal scrolling scrolls in units of full pixels no matter if we're
        rendering a 256-pixel wide screen or a 512-half-pixel wide screen.
        However, vertical scrolling will move in half-line increments if
        interlace mode is active.

        See the section "BACKGROUNDS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2115    -+b++?- VMAINC - Video Port Control
        
        Register name hint: "Video Memory Address Increment"
        
        i---mmjj
        
        i    = Address increment mode:
            
            0 => increment after writing $2118/reading $2139
            1 => increment after writing $2119/reading $213a
            
            Note that a word write stores low first, then high. Thus, if you're
            storing a word value to $2118/9, you'll probably want to set 1
            here.
        
        j = Address increment amount. It is expressed in number of words to
            increment by (as opposed to by byte.)
            
            00 - Normal increment by 1
            
            01 - Increment by 32
                 
                 Useful for reading / writing a normal tilemap
                 when one would like to have the target address
                 move to the next row upon increment.
            
            10 - Increment by 128
                 
                 Useful for reading / writing a mode 7 tilemap
                 when one would like to have the target address
                 move to the next row upon increment.
            
            11 - Increment by 128
                 
                 (Note: Same as address increment amount '10' above)
        
        m    = Address remapping
        
            00 - Normal 
            
                No remapping
            
            01 - 2bpp Full Graphic Mode 
            
                Remap addressing aaaaaaaa BBBccccc => aaaaaaaa cccccBBB
            
            10 - 4bpp Full Graphic Mode
            
                Remap addressing aaaaaaaB BBcccccc => aaaaaaac cccccBBB
            
            11 - 8bpp Full Graphic Mode
                
                Remap addressing aaaaaaBB Bccccccc => aaaaaacc cccccBBB
            
            The "remap" modes basically implement address translation. If
            $2116/7 are set to 0x0003, then word address 0x0018 will be written
            instead, and $2116/7 will be incremented to 0x0004.
            
            What is the point of this? If for some reason a programmer decides
            that they want all of the bitplanes for a horizontal row of pixels
            stored sequentially, these remapping modes should be used. Remapping
            seems to be soley intended for writing CHR data. There doesn't,
            however seem to be any point to using it for Mode 7 CHR, as it is
            stored quite differently.
            
            Example: A 2bpp variable width font buffer is being generated row
            by row. Bitplanes 0 and 1 for the first row of the first tile are
            stored as the first word in the buffer. Then, bitplanes 0 and 1 for
            the first row of the second tile, all the way up to the 31st
            tile. The next 64 bytes would consist of the bitplane 0 and 1 data
            for the second rows of each of the tiles. By the time the BBB bits
            have filled up and overflowed, we should be ready to draw the next
            row of 32 tiles in vram.
            
            To reemphasize, this is catering to programmers that would prefer
            to store their source graphics in a different manner than is
            typical. It would not seem that is a superior or inferior mechanism,
            it's just different. Though, it may make variable width font
            generation slightly easier if it is deemed necessary to generate it
            vertically, line by line.
            

--------------------------------------------------------------------------------

        rw?fvha
2116    -+l++?- VMADDL - VRAM Address low byte
2117    -+h++?- VMADDH - VRAM Address high byte
        aaaaaaaa aaaaaaaa

        This sets the address for $2118/9 and $2139/a. Note that this is a word
        address, not a byte address!

        See the sections "BACKGROUNDS" and "SPRITES" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2118    -+l++-- VMDATAL - VRAM Data Write low byte
2119    -+h++-- VMDATAH - VRAM Data Write high byte
        
        xxxxxxxx xxxxxxxx

        This writes data to VRAM. The writes take effect immediately(?), even
        if no increment is performed. The address is incremented when one of
        the two bytes is written; which one depends on the setting of bit 7 of
        register $2115. Keep in mind the address translation bits of $2115 as
        well.

        The interaction between these registers and $2139/a is unknown.

        See the sections "BACKGROUNDS" and "SPRITES" below for details.

--------------------------------------------------------------------------------

        rw?fvha
211a    -+b++?- M7SEL - Mode 7 Settings
        
        rc----yx

        r    = Playing field size: When clear, the playing field is 1024x1024
            pixels (so the tilemap completely fills it). When set, the playing
            field is much larger, and the 'empty space' fill is controlled by
            bit 6.

        c    = Empty space fill, when bit 7 is set:
               0 = Transparent.
               1 = Fill with character 0. Note that the fill is matrix
                   transformed like all other Mode 7 tiles.
        
        x/y  = Horizontal/Vertical mirroring. If the bit is set, flip the
               256x256 pixel 'screen' in that direction.

        See the section "BACKGROUNDS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
211b    -+w+++- M7A - Mode 7 Matrix A (also used with $2134/6)
211c    -+w+++- M7B - Mode 7 Matrix B (also used with $2134/6)
211d    -+w+++- M7C - Mode 7 Matrix C
211e    -+w+++- M7D - Mode 7 Matrix D
        
        aaaaaaaa aaaaaaaa

        Note that these are "write twice" registers, first the low byte is
        written then the high. Current theory is that writes to the register
        work like this:
          Reg = (Current<<8) | Prev;
          Prev = Current;
        
        Note that there is only one Prev shared by all these registers. This
        Prev is NOT shared with the BGnxOFS registers, but it IS shared with
        the M7xOFS registers.

        These set the matrix parameters for Mode 7. The values are an 8-bit
        fixed point, i.e. the value should be divided by 256.0 when used in
        calculations. See below for more explanation.

        The product A*(B>>8) may be read from registers $2134/6. There is
        supposedly no important delay. It may not be operative during Mode 7
        rendering.

        See the section "BACKGROUNDS" below for details.


--------------------------------------------------------------------------------

        rw?fvha
211f    -+w+++- M7X - Mode 7 Center X
2120    -+w+++- M7Y - Mode 7 Center Y
        
        ---xxxxx xxxxxxxx

        Note that these are "write twice" registers, like the other M7*
        registers. See above for the write semantics. The value is 13 bit
        two's-complement signed.

        The matrix transformation formula is:

        [ X ]   [ A B ]   [ SX + M7HOFS - CX ]   [ CX ]
        [   ] = [     ] * [                  ] + [    ]
        [ Y ]   [ C D ]   [ SY + M7VOFS - CY ]   [ CY ]

        Note: SX/SY are screen coordinates. X/Y are coordinates in the playing
        field from which the pixel is taken. If $211a bit 7 is clear, the
        result is then restricted to 0<=X<=1023 and 0<=Y<=1023. If $211a bits 6
        and 7 are both set and X or Y is less than 0 or greater than 1023, use
        the low 3 bits of each to choose the pixel from character 0.

        The bit-accurate formula seems to be something along the lines of:
          #define CLIP(a) (((a)&0x2000)?((a)|~0x3ff):((a)&0x3ff))

          X[0,y] = ((A*CLIP(HOFS-CX))&~63)
                 + ((B*y)&~63) + ((B*CLIP(VOFS-CY))&~63)
                 + (CX<<8)
          Y[0,y] = ((C*CLIP(HOFS-CX))&~63)
                 + ((D*y)&~63) + ((D*CLIP(VOFS-CY))&~63)
                 + (CY<<8)

          X[x,y] = X[x-1,y] + A
          Y[x,y] = Y[x-1,y] + C

        (In all cases, X[] and Y[] are fixed point with 8 bits of fraction)

        See the section "BACKGROUNDS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2121    -+b+++- CGADD - CGRAM Address
        cccccccc

        This sets the word address (i.e. color) which will be affected by $2122
        and $213b.


--------------------------------------------------------------------------------

        rw?fvha
2122    -+w+++- CGDATA - CGRAM Data write
        -bbbbbgg gggrrrrr

        This writes to CGRAM, effectively setting the palette colors.
        
        Accesses to CGRAM are handled just like accesses to the low table of
        OAM, see $2104 for details.

        Note that the color values are stored in BGR order.

--------------------------------------------------------------------------------

        rw?fvha
2123    -+b+++- W12SEL - Window Mask Settings for BG1 and BG2
2124    -+b+++- W34SEL - Window Mask Settings for BG3 and BG4
2125    -+b+++- WOBJSEL - Window Mask Settings for OBJ and Color Window
        
        ABCDabcd

        c    = Enable window 1 for BG1/BG3/OBJ
        a    = Enable window 2 for BG1/BG3/OBJ
        C    = Enable window 1 for BG2/BG4/Color
        A    = Enable window 2 for BG2/BG4/Color
            When the bit is set, the corresponding window will affect the
            corresponding background (subject to the settings of $212e/f).
        
        d    = Window 1 Inversion for BG1/BG3/OBJ
        b    = Window 2 Inversion for BG1/BG3/OBJ
        D    = Window 1 Inversion for BG2/BG4/Color
        B    = Window 2 Inversion for BG2/BG4/Color
            When the bit is set, "W" should be replaced by "~W" (not-W) in the
            window combination formulae below.
        
        See the section "WINDOWS" below for more details.

--------------------------------------------------------------------------------

        rw?fvha
2126    -+b+++- WH0 - Window 1 Left Position
2127    -+b+++- WH1 - Window 1 Right Position
2128    -+b+++- WH2 - Window 2 Left Position
2129    -+b+++- WH3 - Window 2 Right Position
        xxxxxxxx

        These set the offset of the appropriate edge of the appropriate window.
        Note that if the left edge is greater than the right edge, the window
        is considered to have no range at all (and thus "W" always is false).
        See the section "WINDOWS" below for more details.


--------------------------------------------------------------------------------

        rw?fvha
212a    -+b+++- WBGLOG - Window mask logic for BGs

212b    -+b+++- WOBJLOG - Window mask logic for OBJs and Color Window
        
        44332211 [WBGLOG]
        ----ccoo [WOBJLOG]

        44/33/22/11/oo/cc = Mask logic for BG1/BG2/BG3/BG4/OBJ/Color
            This specified the window combination method, using standard
            boolean operators:
              00 = OR
              01 = AND
              10 = XOR
              11 = XNOR

            Consider two variables, W1 and W2, which are true for pixels
            between the appropriate left and right bounds as set in
            $2126-$2129 and false otherwise. Then, you have the following
            possibilities: (replace "W#" with "~W#", depending on the Inversion
            settings of $2123-$2125)
              Neither window enabled => nothing masked.
              One window enabled     => Either W1 or W2, as appropriate.
              Both windows enabled   => W1 op W2, where "op" is as above.
            Where the function is true, the BG will be masked.

        See the section "WINDOWS" below for more details.


--------------------------------------------------------------------------------

        rw?fvha
212c    -+b+++- TM - Main Screen Designation
212d    -+b+++- TS - Subscreen Designation
        
        ---o4321

        1/2/3/4/o = Enable BG1/BG2/BG3/BG4/OBJ for display
                    on the main (or sub) screen.

        See the section "BACKGROUNDS" below for details.


--------------------------------------------------------------------------------

        rw?fvha
212e    -+b+++- TMW - Window Mask Designation for the Main Screen
212f    -+b+++- TSW - Window Mask Designation for the Subscreen
        
        ---o4321
        
        1/2/3/4/o = Enable window masking for BG1/BG2/BG3/BG4/OBJ on the
                    main (or sub) screen.
        
        See the section "BACKGROUNDS" below for details.
        

--------------------------------------------------------------------------------

        rw?fvha
2130    -+b+++- CGWSEL - Color Addition Select
        
        ccmm--sd

        cc = Clip colors to black before math
            00 => Never
            01 => Outside Color Window only
            10 => Inside Color Window only
            11 => Always

        mm = Prevent color math
            00 => Never
            01 => Outside Color Window only
            10 => Inside Color Window only
            11 => Always

        s     = Add subscreen (instead of fixed color)

        d     = Direct color mode for 256-color BGs

        See the sections "BACKGROUNDS", "WINDOWS", and "RENDERING THE
        SCREEN" below for details.


--------------------------------------------------------------------------------

        rw?fvha
2131    -+b+++- CGADSUB - Color math designation
        shbo4321

        s    = Add/subtract select
            0 => Add the colors
            1 => Subtract the colors

        h    = Half color math. When set, the result of the color math is
            divided by 2 (except when $2130 bit 1 is set and the fixed color is
            used, or when color is clipped).
            Note from MoN: that part about bit 1 in 2130 seems... contradictory.

        4/3/2/1/o/b = Enable color math on BG1/BG2/BG3/BG4/OBJ/Backdrop

        See the sections "BACKGROUNDS", "WINDOWS", and "RENDERING THE
        SCREEN" below for details.

--------------------------------------------------------------------------------

        rw?fvha
2132    -+b+++- COLDATA - Fixed Color Data
        
        bgrccccc

        b/g/r = Which color plane(s) to set the intensity for.
        ccccc = Color intensity.

        So basically, to set an orange you'd do something along the lines of:
            LDA #$3f
            STA $2132
            LDA #$4f
            STA $2132
            LDA #$80
            STA $2132

        See the sections "BACKGROUNDS" and "WINDOWS" below for details.


--------------------------------------------------------------------------------

        rw?fvha
2133    -+b+++- SETINI - Screen Mode/Video Select
        
        se--poIi

        s    = "External Sync". Used for superimposing "sfx" graphics, whatever
            that means. Usually 0. Not much is known about this bit.
            Interestingly, the SPPU1 chip has a pin named "EXTSYNC" (or
            not-EXTSYNC, since it has a bar over it) which is tied to Vcc.

        e    = Mode 7 EXTBG ("Extra BG"). When this bit is set, you may enable
            BG2 on Mode 7. BG2 uses the same tile and character data as BG1,
            but interprets the high bit of the color data as a priority for the
            pixel.

            Various sources report additional effects for this bit, possibly
            related to bit 7. For example, "Enable the Data Supplied From the
            External Lsi.", whatever that means. Of course, maybe that's a
            typo and it's supposed to apply to bit 7 instead.

        p    = Enable pseudo-hires mode. This creates a 512-pixel horizontal
            resolution by taking pixels from the subscreen for the
            even-numbered pixels (zero based) and from the main screen for the
            odd-numbered pixels. Color math behaves just as with Mode 5/6
            hires. The interlace bit still has no effect. Mosaic operates as
            normal (not like Mode 5/6). The 'subscreen' pixel is clipped (by
            windows) when the main-screen pixel to the LEFT is clipped, not
            when the one to the RIGHT is clipped as you'd expect. What happens
            with pixel column 0 is unknown.

            Enabling this bit in Modes 5 or 6 has no effect.

        o    = Overscan mode. When set, 239 lines will be displayed instead of
            the normal 224. This also means V-Blank will occur that
            much later, and be shorter. All that happens is that extra lines
            get added to the display, and it seems the TV will like to move
            the display up 8 pixels. See below for more details.

        I    = OBJ Interlace. When set regardless of BG mode, the OBJ will be
            interlaced (see bit 0 below), and thus will appear half-height.

            Note that this only controls whether obj are drawn as normal or
            not; the interlace signal is only output to the TV based on bit 0
            below.

        i    = Screen interlace. When set in BG mode 5 (and probably 6), the
            effective screen height will be 448 (or 478) pixels, rather than
            224 (or 239). When set in any other mode, the screen will just get
            a bit jumpy. However, toggling the tilemap each field would
            simulate the increased screen height (much like pseudo-hires
            simulates hires).

            In hardware, setting this bit makes the SNES output a normal
            interlace signal rather than always forcing one frame.

        See the sections "BACKGROUNDS" and "SPRITES" below for details.

        Overscan: The bit only matters at the very end of the frame, if you
        change the setting on line 0xE0 before the normal NMI trigger point
        then it's the same as if you had it on all frame. Note that this
        affects both the NMI trigger point and when HDMA stops for the
        frame.

        If you turn the bit off at the very beginning of scanline X (for
        0xE1<=X<=0xF0), NMI will occur on line X and the last HDMA transfer
        will occur on line X-1. However, on my TV at least, the display will
        remain in the normal no-overscan position for lines E1-EC, it will
        move up only one pixel for line ED, and it will lose vertical sync
        for lines EF-F4!

        Turning the bit on, only line E1 gives any effect: NMI will occur on
        line E2, although the last HDMA will still occur on line E0.
        Anything else acts like you left the bit off the whole time. Note,
        however, that if you wait too long after the beginning of the
        scanline then you will get no effect.

        Even if there is no visible effect, the overscan setting still
        affects VRAM writes. In particular, executing "LDA #'-' / STA $2118
        / LDA r2133 / STA $2133 / LDA #'+' / STA $2118" during the E1-F0
        period will write only + or only - to VRAM, depending on whether the
        overscan bit was set to 0 or 1.

        
--------------------------------------------------------------------------------

        rw?fvha
2134    +-l+++? MPYL - Multiplication Result low byte
2135    +-m+++? MPYM - Multiplication Result middle byte
2136    +-h+++? MPYH - Multiplication Result high byte
        
        xxxxxxxx xxxxxxxx xxxxxxxx
        
        This is the 2's compliment product of the 16-bit value written to $211b
        and the 8-bit value most recently written to $211c. There is supposedly
        no important delay. It may not be operative during Mode 7 rendering.

--------------------------------------------------------------------------------

        rw?fvha
2137    --b++++ SLHV - Software Latch for H/V Counter
        
        --------
        
        When read, the H/V counter (as read from $213c and $213d) will be
        latched to the current X and Y position if bit 7 of $4201 is set. The
        data actually read is open bus.

--------------------------------------------------------------------------------

        rw?fvha
2138    +-w++?- OAMDATAREAD* - Data for OAM read
        
        xxxxxxxx

        OAM reads are straightforward: the current byte as set in $2102/3 and
        incremented by reads from this register and writes to $2104 will be
        returned. Note that writes to the lower table are not affected so
        logically. See register $2104 and the section "SPRITES" below for
        details.

        Also, note that OAM address invalidation probably affects the address
        read by this register as well.


--------------------------------------------------------------------------------

        rw?fvha
2139    +-l++?- VMDATALREAD* - VRAM Data Read low byte
213a    +-h++?- VMDATAHREAD* - VRAM Data Read high byte
        
        xxxxxxxx xxxxxxxx

        Simply, this reads data from VRAM. The address is incremented when
        either $2139 or $213a is read, depending on the setting of bit 7 of
        $2115.

        Actually, the reading is more complex. When either of these registers
        is read, the appropriate byte from a word-sized buffer is returned. A
        word from VRAM is loaded into this buffer just *before* the VRAM
        address is incremented. The actual data read and the amount of the
        increment depend on the low 4 bits of $2115. The effect of this is
        that a 'dummy read' is required after setting $2116-7 before you start
        getting the actual data.

        The interaction between these registers and $2118/9 is unknown.

        See the sections "BACKGROUNDS" and "SPRITES" below for details.

--------------------------------------------------------------------------------

        rw?fvha
213b    +-w++?- CGDATAREAD* - CGRAM Data read
        -bbbbbgg gggrrrrr

        This reads from CGRAM.

        Accesses to CGRAM are handled just like accesses to the low table of
        OAM, see $2138 for details.

        Note that the color values are stored in BGR order. The '-' bit is PPU2
        Open Bus.

--------------------------------------------------------------------------------

        rw?fvha
213c    +-w++++ OPHCT - Horizontal Scanline Location
213d    +-w++++ OPVCT - Vertical Scanline Location
        -------x xxxxxxxx

        These values are latched by reading $2137 when bit 7 of $4201 is set,
        or by clearing-and-setting bit 7 of $4201 either by writing $4201 or by
        pin 6 of Controller Port 2 (the latch occurs on the 1->0 transition).

        Note that the value read is only 9 bits: bits 1-7 of the high byte are
        PPU2 Open Bus. Each register keeps seperate track of whether to
        return the low or high byte. The high/low selector is reset to 'low'
        when $213f is read (the selector is NOT reset when the counter is
        latched).

        H Counter values range from 0 to 339, with 22-277 being visible on the
        screen. V Counter values range from 0 to 261 in NTSC mode (262 is
        possible every other frame when interlace is active) and 0 to 311 in
        PAL mode (312 in interlace?), with 1-224 (or 1-239(?) if overscan is
        enabled) visible on the screen.

--------------------------------------------------------------------------------

        rw?fvha
213e    +-b++++ STAT77 - PPU Status Flag and Version
        
        trm-vvvv

        t    = Time Over Flag. If more than 34 sprite-tiles (e.g. a 16x16
            sprite has 2 sprite-tiles) were encountered on a single line, this
            flag will be set. The flag is reset at the end of V-Blank. See the
            section "SPRITES" below for details.

        r    = Range Over Flag. If more than 32 sprites were encountered on a
            single line, this flag will be set. The flag is reset at the end of
            V-Blank. See the section "SPRITES" below for details.

            Note that the above two flags are set whether or not OBJ are
            actually enabled at the time.

        m    = "Master/slave mode select". Little is known about this bit.
            Current theory is that it indicates the status of the "MASTER" pin
            on the S-PPU1 chip, which in the normal SNES is always Gnd. We
            always seem to read back 0 here.

        vvvv = 5c77 chip version number. So far, we've only encountered version
            1.

        The '-' bit is PPU1 Open Bus.

--------------------------------------------------------------------------------

        rw?fvha
213f    +-b++++ STAT78 - PPU Status Flag and Version
        
        fl-pvvvv

        f    = Interlace Field. This will toggle every V-Blank.

        l    = External latch flag. When the PPU counters are latched, this
            flag gets set. The flag is reset on read, but only when $4201 bit 7
            is set. 

        p    = NTSC/Pal Mode. If this is a PAL SNES, this bit will be set,
            otherwise it will be clear.

        vvvv = 5C78 chip version number. So far, we've encountered at least 2
            and 3. Possibly 1 as well.

        The '-' bit is PPU2 Open Bus.

        Note: as a side effect of reading this register, the high/low byte
        selector for $213c/d is reset to 'low'.


--------------------------------------------------------------------------------

        rw?fvha
2140    ++b++++ APUIO0 - APU I/O register 0
2141    ++b++++ APUIO1 - APU I/O register 1
2142    ++b++++ APUIO2 - APU I/O register 2
2143    ++b++++ APUIO3 - APU I/O register 3
        
        xxxxxxxx

        These registers are used in communication with the SPC700. Note that
        the value written here is not the value read back. Rather, the value
        written shows up in the SPC700's registers $f4-7, and the values
        written to those registers by the SPC700 are what you read here.

        If the SPC700 writes the register during a read, the value read will
        be the logical OR of the old and new values. The exact cycles during
        which the 'read' actually occurs is not known, although a good guess
        would be some portion of the final 3 master cycles of the 6-cycle
        memory access.
        
        Note that these registers are mirrored throughout the range
        $2140-$217f.

--------------------------------------------------------------------------------

        rw?fvha
2180    ++b++++ WMDATA - WRAM Data read/write
        xxxxxxxx

        This register reads to or writes from the WRAM address set in $2181-3.
        The address is then incremented. The effect of mixed reads and writes
        is unknown, but it is suspected that they are handled logically.

        Note that attempting a DMA from WRAM to this register will not work,
        WRAM will not be written. Attempting a DMA from this register to
        WRAM will similarly not work, the value written is (initially) the Open
        Bus value. In either case, the address in $2181-3 is not incremented.


--------------------------------------------------------------------------------

        rw?fvha
2181    -+l++++ WMADDL - WRAM Address low byte
2182    -+m++++ WMADDM - WRAM Address middle byte
2183    -+h++++ WMADDH - WRAM Address high bit
        
        -------x xxxxxxxx xxxxxxxx
        
        This is the address that will be read or written by accesses to $2180.
        Note that WRAM is also mapped in the SNES memory space from $7E:0000 to
        $7F:FFFF, and from $0000 to $1FFF in banks $00 through $3F and $80
        through $BF.
        
        Verious docs indicate that these registers may be read as well as
        written. However, they are wrong. These registers are open bus.
        
        The internal wram address will wrap back to 0x000000 when incremented
        past 0x01ffff. Other than that special case, the address never decrements
        automatically. The internal address is also not restricted by bank. That is,
        an internal address of 0x00ffff will increment to 0x010000 after a write or
        read of register $2180.
        
        DMA from WRAM to these registers has no effect. Otherwise, however, DMA
        writes them as normal. This means you could use DMA mode 4 to $2180 and
        a table in ROM to write any sequence of RAM addresses.

--------------------------------------------------------------------------------

        rw?fvha
4016    ++b++++ JOYSER0 - NES-style Joypad Access Port 1
4017    +?b++++ JOYSER1 - NES-style Joypad Access Port 2
        
        ------ca [Reading JOYSER0]
        -------l [Writing JOYSER0]
        
        ---111db [JOYSER1]

        These registers basically have a direct connection to the controller
        ports on the front of the SNES. 

        l    = Writing this bit controlls the Latch line of both controller
            ports. When 1 is set, the Latch goes high (or is it low? At any
            rate, whichever one makes the pads latch their state). When
            cleared, the Latch goes the other way.
        
        a/b  = These bits return the state of the Data1 line.
        c/d  = These bits return the state of the Data2 line.
            Reading $4016 drives the Clock line of Controller Port 1 low.
            The SNES then reads the Data1 and Data2 lines, and Clock is set
            back to high. $4017 does the same for Port 2.
        
        Note the 1-bits in $4017: the CPU chip has pins for these bits, but
        these pins are tied to Gnd and thus always 1.

        Data for normal joypads is returned in the order: B, Y, Select,
        Start, Up, Down, Left, Right, A, X, L, R, 0, 0, 0, 0, then ones
        until latched again.

        Note that Auto-Joypad Read (see register $4200) will effectively write
        1 then 0 to bit 'l', then read 16 times from both $4016 and $4017. The
        'a' bits will end up in $4218/9, with the first bit read (e.g. the B
        button) in bit 15 of the word. Similarly, the 'b' bits end up in
        $421a/b, the 'c' bits in $42c/d, and the 'd' bits in $421e/f. Any
        further bits the device may return may be read from $4016/$4017 as
        normal.

        The effect of reading these during auto-joypad read is unknown.

        See the section "CONTROLLERS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
4200    -+b+++? NMITIMEN - Interrupt Enable Flags
        
        n-yx---a

        n    = Enable NMI. If clear, NMI will not occur. If set, NMI will fire
            just after the start of V-Blank.

            NMI fires shortly after the V Counter reaches $E1 (or presumably
            $F0 if overscan is enabled, see register $2133).

        x/y  = IRQ enable.
            0/0 => No IRQ will occur
            0/1 => An IRQ will occur sometime just after the V Counter reaches
                   the value set in $4209/a.
            1/0 => An IRQ will occur sometime just after the H Counter reaches
                   the value set in $4207/8.
            1/1 => An IRQ will occur sometime just after the H Counter reaches
                   the value set in $4207/8 when V Counter equals the value set
                   in $4209/a.

        a    = Auto-Joypad Read Enable. When set, the registers $4218-$421f
            will be updated at about V Counter = $E3 (or presumably $F2).

        Some games try to read this register. However, they work only because
        open bus behavior gives them values they expect.

        This register is initialized to $00 on power on or reset.

--------------------------------------------------------------------------------

        rw?fvha
4201    -+b++++ WRIO - Programmable I/O port (out-port)
        
        abxxxxxx

        This is basically just an 8-bit I/O Port. 'b' is connected to pin 6 of
        Controller Port 1. 'a' is connected to pin 6 of Controller Port 2, and
        to the PPU Latch line. Thus, writing a 0 then a 1 to bit 'a' will latch
        the H and V Counters much like reading $2137 (the latch happens on the
        transition to 0). When bit 'a' is 0, no latching can occur.

        Any other effects of this register are unknown. See $4213 for the
        I half of the I/O Port.

        Note that the IO Port is initialized as if this register were written
        with all 1-bits at power up, unchanged on reset(?).


--------------------------------------------------------------------------------

        rw?fvha
4202    -+b++++ WRMPYA - Multiplicand A
4203    -+b++++ WRMPYB - Multiplicand B
        
        mmmmmmmm

        Write $4202, then $4203. 8 "machine cycles" (probably 48 master cycles)
        after $4203 is set, the product may be read from $4216/7. $4202 will
        not be altered by this process, thus a new value may be written to
        $4203 to perform another multiplication without resetting $4202.

        The multiplication is unsigned.

        $4202 holds the value $ff on power on and is unchanged on reset.


--------------------------------------------------------------------------------

        rw?fvha
4204    -+l++++ WRDIVL - Dividend C low byte
4205    -+h++++ WRDIVH - Dividend C high byte
4206    -+b++++ WRDIVB - Divisor B
        
        [WRDIVH] [WRDIVL]
        dddddddd dddddddd
        
        [WRDIVB]
        bbbbbbbb

        Write $4204/5, then $4206. 16 "machine cycles" (probably 96 master
        cycles) after $4206 is set, the quotient may be read from $4214/5, and
        the remainder from $4216/7. Presumably, $4204/5 are not altered by this
        process, much like $4202.
        
        The division is unsigned. Division by 0 gives a quotient of $FFFF and a
        remainder of C.

        WRDIV holds the value $ffff on power on and is unchanged on reset.

--------------------------------------------------------------------------------

        rw?fvha
4207    -+l++++ HTIMEL - H Timer low byte
4208    -+h++++ HTIMEH - H Timer high byte
        
        -------h hhhhhhhh
        
        If bit 4 of $4200 is set and bit 5 is clear, an IRQ will fire every
        scanline when the H Counter reaches the value set here. If bits 4 and 5
        are both set, the IRQ will fire only when the V Counter equals the
        value set in $4209/a.
        
        Note that the H Counter ranges from 0 to 339, thus greater values will
        result in no IRQ firing.

        HTIME is initialized to $1ff on power on, unchanged on reset.

--------------------------------------------------------------------------------

        rw?fvha
4209    -+l++++ VTIMEL - V Timer low byte
420a    -+h++++ VTIMEH - V Timer high byte
        
        -------v vvvvvvvv

        If bit 5 of $4200 is set and bit 4 is clear, an IRQ will fire just
        after the V Counter reaches the value set here. If bits 4 and 5 are
        both set, the IRQ will fire instead when the V Counter equals the value
        set here and the H Counter reaches the value set in $4207/8.
        
        Note that the V Counter ranges from 0 to 261 in NTSC mode (262 is
        possible every other frame whan interlace is active) and 0 to 311 in
        PAL mode (312 in interlace?), thus greater values will result in no IRQ
        firing.

        VTIME is initialized to $1ff on power on, unchanged on reset.


--------------------------------------------------------------------------------

        rw?fvha
420b    -+b++++ MDMAEN - DMA Enable
        
        76543210

        7/6/5/4/3/2/1/0 = Enable the selected DMA channels. The CPU will be
            paused until all DMAs complete. DMAs will be executed in order from
            0 to 7 (?).

        See registers $43x0-$43xA for more details.

        If HDMA (init or transfer) occurs while a DMA is in progress, the DMA
        will be paused for the duration. If the HDMA happens to involve the
        current DMA channel, the DMA will be immediately terminated and the
        HDMA will progress using the then-current values of the registers.
        Other DMA channels will be unaffected.

        This register is initialized to $00 on power on or reset.

        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
420c    -+b++++ HDMAEN - HDMA Enable
        
        76543210
        
        7/6/5/4/3/2/1/0 = Enable the selected HDMA channels. HDMAs will be
            executed in order from 0 to 7 (?).
        
        See registers $43x0-$43xA for more details.
        
        If HDMA (init or transfer) occurs while a DMA is in progress, the DMA
        will be paused for the duration. If the HDMA happens to involve the
        current DMA channel, the DMA will be immediately terminated and the
        HDMA will progress using the then-current values of the registers.
        Other DMA channels will be unaffected.
        
        Note that enabling a channel mid-frame will begin HDMA at the next HDMA
        point. However, the HDMA register initialization only occurs before the
        HDMA point on scanline 0, so those registers will have to be
        initialized by hand before enabling HDMA. A channel that has already
        terminated for the frame cannot be restarted in this manner.
        
        Writing 0 to a bit will pause an ongoing HDMA; the transfer may be
        continued by writing 1 to the bit.
        
        This register is initialized to $00 on power on or reset.
        
        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
420d    -+b++++ MEMSEL - ROM Access Speed
        
        -------f
        
        f    = FastROM select. The SNES uses a master clock running at
            about 21.477 MHz (current theory is 1.89e9/88 Hz). By default, the
            SNES takes 8 master cycles for each ROM access. If this bit is set
            and ROM is accessed via banks $80-$FF, only 6 master cycles will be
            used.
        
        This register is initialized to $00 on power on (or reset?).
        
        See my memory map and timing doc (memmap.txt) for more details.

--------------------------------------------------------------------------------

        rw?fvha
4210    +-b++++ RDNMI - NMI Flag and 5A22 Version
        
        n---vvvv
        
        n    = NMI Flag. This bit is set at the start of V-Blank (at the
            moment, we suspect when H-Counter is somewhere between $28 and
            $4E), and cleared on read or at the end of V-Blank. Supposedly, it
            is required that this register be read during NMI.
            
            Note that this bit is not affected by bit 7 of $4200.
        
        vvvv = 5A22 chip version number. So far, we've encountered at least 2,
            maybe 1 as well.
        
        NMI is cleared on power on or reset.
        
        The '-' bits are open bus.


--------------------------------------------------------------------------------

        rw?fvha
4211    +-b++++ TIMEUP - IRQ Flag
        
        i-------

        i    = IRQ Flag. This bit is set just after an IRQ fires (at the
            moment, it seems to have the same delay as the NMI Flag of $4210
            has following NMI), and is cleared on read or write. Supposedly, it
            is required that this register be read during the IRQ handler. If
            this really is the case, then I suspect that that read is what
            actually clears the CPU's IRQ line.

        This register is marked read/write in another doc, with no explanation.

        IRQ is cleared on power on or reset.
        
        The '-' bits are open bus.

--------------------------------------------------------------------------------

        rw?fvha
4212    +-b++++ HVBJOY - PPU Status
        
        vh-----a

        v    = V-Blank Flag. If we're currently in V-Blank, this flag is set,
            otherwise it is clear. The setting seems to occur at H Counter
            about $16-$17 when V Counter is $E1, and the clearing at about $1E
            with V Counter 0.

        h    = H-Blank Flag. If we're currently in H-Blank, this flag is set,
            otherwise it is clear. The setting seems to occur at H Counter
            about $121-$122, and the clearing at about $12-$18.

        a    = Auto-Joypad Status. This is set while Auto-Joypad Read is in
            progress, and cleared when complete. It typically turns on at
            the start of V-Blank, and completes 3 scanlines later.

        This register is marked read/write in another doc, with no explanation.

--------------------------------------------------------------------------------

        rw?fvha
4213    +-b++++ RDIO - Programmable I/O port (in-port)
        
        abxxxxxx
        
        Reading this register reads data from the I/O Port. The way the
        I/O Port works, any bit set to 0 in $4201 will be 0 here. Any bit
        set to 1 in $4201 may be 1 or 0 here, depending on whether any other
        device connected to the I/O Port has set a 0 to that bit.
        
        Bit 'b' is connected to pin 6 of Controller Port 1. Bit 'a' is
        connected to pin 6 of Controller Port 2, and to the PPU Latch line.
        
        See register $4201 for the O side of the I/O Port.

--------------------------------------------------------------------------------

        rw?fvha
4214    +-l++++ RDDIVL - Quotient of Divide Result low byte
4215    +-h++++ RDDIVH - Quotient of Divide Result high byte
        
        qqqqqqqq qqqqqqqq

        Write $4204/5, then $4206. 16 "machine cycles" (probably 96 master
        cycles) after $4206 is set, the quotient may be read from these
        registers, and the remainder from $4216/7.
        
        The division is unsigned.


--------------------------------------------------------------------------------

        rw?fvha
4216    +-l++++ RDMPYL - Multiplication Product or Divide Remainder low byte
4217    +-h++++ RDMPYH - Multiplication Product or Divide Remainder high byte
        xxxxxxxx xxxxxxxx

        Write $4202, then $4203. 8 "machine cycles" (probably 48 master cycles)
        after $4203 is set, the product may be read from these registers.

        Write $4204/5, then $4206. 16 "machine cycles" (probably 96 master
        cycles) after $4206 is set, the quotient may be read from $4214/5, and
        the remainder from these registers.

        The multiplication and division are both unsigned.

--------------------------------------------------------------------------------

        rw?fvha
4218    +-l++++ JOY1L - Controller Port 1 Data1 Register low byte
4219    +-h++++ JOY1H - Controller Port 1 Data1 Register high byte
421a    +-l++++ JOY2L - Controller Port 2 Data1 Register low byte
421b    +-h++++ JOY2H - Controller Port 2 Data1 Register high byte
421c    +-l++++ JOY3L - Controller Port 1 Data2 Register low byte
421d    +-h++++ JOY3H - Controller Port 1 Data2 Register high byte
421e    +-l++++ JOY4L - Controller Port 2 Data2 Register low byte
421f    +-h++++ JOY4H - Controller Port 2 Data2 Register high byte
        
        byetUDLR axlr0000

        The bitmap above only applies for joypads, obviously. More
        generically, Auto Joypad Read effectively sets 1 then 0 to $4016,
        then reads $4016/7 16 times to get the bits for these registers.
        
        a/b/x/y/l/r/e/t = A/B/X/Y/L/R/Select/Start button status.

        U/D/L/R = Up/Down/Left/Right control pad status. Note that only one of
            L/R and only one of U/D may be set, due to the pad hardware.

        These registers are only updated when the Auto-Joypad Read bit (bit 0)
        of $4200 is set. They are being updated while the Auto-Joypad Status
        bit (bit 0) of $4212 is set. Reading during this time will return
        incorrect values.

        See the section "CONTROLLERS" below for details.

--------------------------------------------------------------------------------

        rw?fvha
43x0    ++b++++ DMAPx - DMA Control for Channel x (x=0-7)
        
        da-ifttt

        d    = Transfer Direction. When clear, data will be read from the CPU
            memory and written to the PPU register. When set, vice versa.
            
            Contrary to previous belief, this bit DOES affect HDMA! Indirect
            mode is more useful, it will read the table as normal and write
            from Bus B to the Bus A address specified. Direct mode will work as
            expected though, it will read counts from the table and try to
            write the data values into the table.

        a    = HDMA Addressing Mode. When clear, the HDMA table contains the
            data to transfer (Direct HDMA). When set, the HDMA table contains pointers to the
            data (Indirect HDMA). This bit does not affect DMA.

        i    = DMA Address Increment. When clear, the DMA address will be
            incremented for each byte. When set, the DMA address will be
            decremented. This bit does not affect HDMA.

        f    = DMA Fixed Transfer. When set, the DMA address will not be
            adjusted, overriding bit 'i'. When clear, the address will be
            adjusted as specified by bit 'i'. This bit does not affect HDMA.

        ttt  = Transfer Mode.
            000 => 1 register write once             (1 byte:  p               )
            001 => 2 registers write once            (2 bytes: p, p+1          )
            010 => 1 register write twice            (2 bytes: p, p            )
            011 => 2 registers write twice each      (4 bytes: p, p,   p+1, p+1)
            100 => 4 registers write once            (4 bytes: p, p+1, p+2, p+3)
            101 => 2 registers write twice alternate (4 bytes: p, p+1, p,   p+1)
            110 => 1 register write twice            (2 bytes: p, p            )
            111 => 2 registers write twice each      (4 bytes: p, p,   p+1, p+1)

        The effect of writing this register during HDMA to the associated
        channel is unknown. Most likely, the change takes effect for the
        next HDMA transfer.

        This register is set to $ff on power on, and is unchanged on reset.

        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43x1    ++b++++ BBADx - DMA Destination Register for Channel x (x=0-7)
        
        "BBADx" -> "B Bus ADdress x"
        
        pppppppp
        
        This specifies the Bus B address to access. Considering the standard
        CPU memory space, this specifies which address $00:2100-$00:21ff to
        access, with two- and four-register modes wrapping $21ff->$2100, not
        $2200.
        
        The effect of writing this register during HDMA to the associated
        channel is unknown. Most likely, the change takes effect for the
        next transfer.
        
        This register is set to $ff on power on, and is unchanged on reset.
        
        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43x2    ++l++++ A1TxL - DMA Source Address for Channel x low byte (x=0-7)
43x3    ++h++++ A1TxH - DMA Source Address for Channel x high byte (x=0-7)
43x4    ++b++++ A1Bx - DMA Source Address for Channel x bank byte (x=0-7)
        bbbbbbbb hhhhhhhh llllllll

        This specifies the starting Address Bus A address for the DMA transfer,
        or the beginning of the HDMA table for HDMA transfers. Note that Bus A
        does not access the Bus B registers, so pointing this address at say
        $00:2100 results in open bus.

        The effect of writing this register during HDMA to the associated
        channel is unknown. However, current theory is that only $43x4 will
        affect the transfer. The changes will take effect at the next HDMA
        init.

        During DMA, $43x2/3 will be incremented or decremented as specified by
        $43x0. However $43x4 will NOT be adjusted. These registers will not be
        affected by HDMA.

        This register is set to $ff on power on, and is unchanged on reset.
        
        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43x5    ++l++++ DASxL - DMA Size/HDMA Indirect Address low byte (x=0-7)
43x6    ++h++++ DASxH - DMA Size/HDMA Indirect Address high byte (x=0-7)
43x7    ++b++++ DASBx - HDMA Indirect Address bank byte (x=0-7)
        bbbbbbbb hhhhhhhh llllllll

        For DMA, $43x5/6 indicate the number of bytes to transfer. Note that
        this is a strict limit: if this is set to 1 then only 1 byte will be
        written, even if the transfer mode specifies 2 or 4 registers (and if
        this is 5, all 4 registers would be written once, then the first only
        would be written a second time). Note, however, that writing $0000 to
        this register actually results in a transfer of $10000 bytes, not 0.

        $43x5/6 are decremented during DMA, and thus typically end up set to 0
        when DMA is complete.

        For HDMA, $43x7 specifies the bank for indirect addressing mode. The
        indirect address is copied into $43x5/6 and incremented appropriately.
        For direct HDMA, these registers are not used or altered.

        Writes to $43x7 during indirect HDMA will take effect for the next
        transfer. Writes to $43x5/6 during indirect HDMA will also take effect
        for the next HDMA transfer, however this is only noticable during
        repeat mode (for normal mode, a new indirect address will be read from
        the table before the transfer). For a direct transfer, presumably
        nothing will happen.

        This register is set to $ff on power on, and is unchanged on reset.

        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43x8    ++l++++ A2AxL - HDMA Table Address low byte (x=0-7)
43x9    ++h++++ A2AxH - HDMA Table Address high byte (x=0-7)
        aaaaaaaa aaaaaaaa

        At the beginning of the frame $43x2/3 are copied into this register for
        all active HDMA channels, and then this register is updated as the
        table is read. Thus, if a game wishes to start HDMA mid-frame (or
        change tables mid-frame), this register must be written. Writing this
        register mid-frame changes the table address for the next scanline.

        This register is not used for DMA.

        This register is set to $ff on power on, and is unchanged on reset.

        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43xa    ++b++++ NLTRx - HDMA Line Counter (x=0-7)
        rccccccc

        r    = Repeat Select. When set, the HDMA transfer will be performed
            every line, rather than only when this register is loaded from the
            table. However, this byte (and the indirect HDMA address) will only
            be reloaded from the table when the counter reaches 0.

        ccccccc = Line count. This is decremented every scanline. When it
            reaches 0, a byte is read from the HDMA table into this register
            (and the indirect HDMA address is read into $43x5/6 if applicable).

        One oddity: the register is decremeted before being checked for r
        status or c==0. Thus, setting a value of $80 is really "128 lines with
        no repeat" rather than "0 lines with repeat". Similarly, a value of $00
        will be "128 lines with repeat" when it doesn't mean "terminate the
        channel".

        This register is initialized at the end of V-Blank for every active
        HDMA channel. Note that if a game wishes to begin HDMA during the
        frame, it will most likely have to initalize this register. Writing
        this mid-transfer will similarly change the count and repeat to take
        effect next scanline. Remember though that 'repeat' won't take effect
        until after the next transfer period.

        This register is set to $ff on power on, and is unchanged on reset.

        See the section "DMA AND HDMA" below for more information.

--------------------------------------------------------------------------------

        rw?fvha
43xb    ++b++++ ????x - Unknown (x=0-7)
43xf    ++b++++ ????x - Unknown (x=0-7)
        ????????

        The effects of these registers (if any) are unknown. $43xf and $43xb
        are really aliases for the same register.

        This register is set to $ff on power on, and is unchanged on reset.

--------------------------------------------------------------------------------

>SPRITES
=======

The SNES has 128 independent sprites. The sprite definitions are stored in
Object Attribute Memory, or OAM.

>OAM
---

OAM consists of 544 bytes, organized into a low table of 512 bytes and a high
table of 32 bytes. Both tables are made up of 128 records. OAM is accessed by
setting the word address in register $2102, the "table select" in bit 0 of
$2103, then writing to $2104 or reading from $2138. Since the high table is
only 32 bytes long, only the low 4 bits of $2102 are significant for indexing
this table.

The internal OAM address is invalidated during the rendering of a scanline;
this invalidation is deterministic, but we do not know how or when the value is
determined. Current theory is that it is invalidated more-or-less continuously
and has something to do with the current OAM address and possibly which sprites
are on the current scanline. The internal OAM address is reloaded from $2102/3
at the beginning of V-Blank, if this occurs outside of a force-blank period.
The reload also occurs on a 1->0 transition of $2100.7.

Each read/write increments the address by one byte (the internal address has 10
bits, with bit 9 selecting the table and bits 0-8 indexing). Reads simply read
the current byte. Writes to the low table go into a word-sized buffer, which is
written to the appropriate word of OAM when the high byte of the word is
written. Thus, if alternating reads and writes occur such that the high byte of
the word is always read instead of written, none of the writes will actually
affect OAM. If the alternation happens such that the writes always occur to the
high byte, not only the high bytes but whatever garbage is left in the low byte
will be written as well!

Pictorally: Start OAM filled with all zeros. Write 1, read, read, Write 2,
read, write 3 => OAM is 00 00 01 02 01 03, rather than 01 00 00 02 00 03 as
you might expect.

Writes to the high table, on the other hand, work exactly as expected.

The record format for the low table is 4 bytes:
  byte OBJ*4+0: xxxxxxxx
  byte OBJ*4+1: yyyyyyyy
  byte OBJ*4+2: cccccccc
  byte OBJ*4+3: vhoopppN

The record format for the high table is 2 bits:
  bit 0/2/4/6 of byte OBJ/4: X
  bit 1/3/5/7 of byte OBJ/4: s

The values are:
  Xxxxxxxxx = X position of the sprite. Basically, consider this signed but see
      below.
  yyyyyyyy  = Y position of the sprite. Values 0-239 are on-screen. -63 through
      -1 are "off the top", so the bottom part of the sprite comes in at the
      top of the screen. Note that this implies a really big sprite can go off
      the bottom and come back in the top.
  cccccccc  = First tile of the sprite. See below for the calculation of the
      VRAM address. Note that this could also be considered as 'rrrrcccc'
      specifying the row and column of the tile in the 16x16 character table.
  N         = Name table of the sprite. See below for the calculation of the
      VRAM address.
  ppp       = Palette of the sprite. The first palette index is 128+ppp*16.
  oo        = Sprite priority. See below for details.
  h/v       = Horizontal/Veritcal flip flags. Note this flips the whole sprite,
      not just the individual tiles. However, the rectangular sprites are
      flipped vertically as if they were two square sprites (i.e. rows
      "01234567" flip to "32107654", not "76543210").
  s         = Sprite size flag. See below for details.

The sprite size is controlled by bits 5-7 of $2101, and the Size bit of OAM.
$2101 determines the two possible sizes for all sprites. If the OAM Size flag
is 0, the sprite uses the smaller size, otherwise it uses the larger size.


Palettes
--------

There are 8 16-color palettes available to sprites, starting at CGRAM index
128. Thus, the palette number 'ppp' in OAM indicates that colors 128+ppp*16
through 128+ppp*16+15 are available to this sprite. However, the first of these
is always considered transparent, to allow for non-rectangular shaped sprites.

Only sprites with palettes 4-7 participate in color math.


Character table in VRAM
-----------------------

Sprites have two 16x16 tile character tables in VRAM. Wrapping on these works
much like for BG tilemaps: tile 0 is to the right of tile $0F and below tile
$F0, tile $10 is below tile 0 and to the right of tile $1F, tile $FF is to the
left of tile $F0 and above tile $0F, and so on. Which character table a sprite
uses is determined by the N bit in OAM. So if you specify Tile=$ff, your 16x16
sprite is made of tiles $ff, $f0, $0f, and $00.

The first table is at the address specified by the Name Base bits of $2101, and
the offset of the second is determined by the Name bits of $2101. The word
address in VRAM of a sprite's first tile may be calculated as:
  ((Base<<13) + (cccccccc<<4) + (N ? ((Name+1)<<12) : 0)) & 0x7fff

See the section "BACKGROUNDS" below for details on the format of the character
data.


Sprite Priority
---------------

There are two 'priority' concepts applicable to sprites. First, there are
the priority bits in OAM, which control the priority of the sprites relative
to the BGs. See the section "BACKGROUNDS" for more details on this.

The second is the priority with relation to the other sprites. This is
completely controlled by the sprite's index and the priority rotation
setting.

Priority rotation is set by bit 7 of $2103. If the bit is unset, Sprite 0 is
always the first sprite. Otherwise, take the current internal OAM word
address (not affected by OAM Address Invalidation) and give priority to the
sprite number (OAMAddr&0xFE)>>1. So if you set $2102/3 to $104, then write 4
bytes, sprite 3 will have priority for the next frame. However, OAM Address
Reset will reset the internal OAM address to word $104, so sprite 2 will
have priority for subsequent frames.

There is one major oddity: if you set $2102/3=A, then write 4n+2*(A&1)+1
bytes (e.g. so the next byte written would go to the last byte in the 4-byte
sprite record), sprite ((OAMAddr>>1)+Y)&0x7F has priority (where Y is the
current line as addressed by sprites). Thus, if you put all 128 8x8 sprites
at Y=63, write $8000 to $2102/3, then read 3 bytes from $2138, you will see
sprites 63-70 having priority on successive scanlines.

FirstSprite ends up on top of all other sprites, regardless of the priority
bits in OAM. FirstSprite+1 is on top of FirstSprite+2 is on top of
FirstSprite+3 and so on until FirstSprite+127 (wrapping of course from sprite
127 to sprite 0). Note that only the priority of the topmost sprite is
considered relative to the backgrounds. Thus, if FirstSprite+3 and
FirstSprite+4 are identical except FirstSprite+3 has priority 0 and
FirstSprite+4 has priority 3, they will both be hidden by any backgrounds that
hide priority 0 sprites. This may seem counterintuitive, since FirstSprite+4
would normally go in front of these BGs, but many games depend on this
behavior.


Drawing the Sprites
-------------------

As with everything else on the SNES, sprites are drawn per-scanline. The
process is basically as follows:

 0) If any OBJ is at X=256 (or X=-256, same difference), consider it as being
    at X=0 when considering Range and Time. Note that this doesn't mean you
    actually draw it at X=0.

 1) Range: Starting with the FirstSprite, determine the first 32 sprites on
    this scanline. Only those sprites with -size < X < 256 are considered in
    Range. If there are more than 32 sprites on the scanline, set bit 6 of
    register $213e.

 2) Time: Starting with the last sprite in Range, load up to 34 8x8 tiles (from
    left-to-right, after flipping). If there are more than 34 tiles in Range,
    set bit 7 of $213e. Only those tiles with -8 < X < 256 are counted.
 
 3) Associate with each tile in Range and Time its true X position (256/-256
    should not be set to 0), palette, and priority for drawing.

See the section "RENDERING THE SCREEN" below for details.


BACKGROUNDS
===========

BG Modes
--------

The SNES has 7 background modes, two of which have major variations. The modes
are selected by bits 0-2 of register $2105. The variation of Mode 1 is selected
by bit 3 of $2105, and the variation of Mode 7 is selected by bit 6 of $2133.

Mode    # Colors for BG
         1   2   3   4
======---=---=---=---=
0        4   4   4   4
1       16  16   4   -
2       16  16   -   -
3      256  16   -   -
4      256   4   -   -
5       16   4   -   -
6       16   -   -   -
7      256   -   -   -
7EXTBG 256 128   -   -

In all modes and for all BGs, color 0 in any palette is considered transparent.


Tile Maps and Character Maps
----------------------------

    Each BG has two regions of VRAM associated with it: one for the tilemap, and
    one for the character data.
    
    The tilemap address is selected by bits 2-7 of registers $2107-a, and the
    tilemap size is selected by bits 0-1 of that same register. All tilemaps are
    32x32, bits 0-1 simply select the number of 32x32 tilemaps and how they're
    layed out in memory:
      00  32x32   AA
                  AA
      01  64x32   AB
                  AB
      10  32x64   AA
                  BB
      11  64x64   AB
                  CD
    
    Here's a diagram of the memory layout of a 64x64 (X and Y mirrored) tilemap,
    which again consists of 4 individual 32x32 tilemaps. Offsets are relative
    the tilemaps starting position in vram, and are all expressed in 16-bit
    words.
    
    64x64 Tilemap Size
    
    +-------------------+-------------------+
    | 0x0000 ... 0x001f | 0x0400 ... 0x041f |
    | .               . | .               . |
    | .      I        . | .      II       . |
    | .               . | .               . |
    | 0x03e0 ... 0x03ff | 0x07e0 ... 0x07ff |
    +-------------------+-------------------+
    | 0x0800 ... 0x081f | 0x0c00 ... 0x0c1f |
    | .               . | .               . |
    | .      III      . | .      IV       . |
    | .               . | .               . |
    | 0x0be0 ... 0x0bff | 0x0fe0 ... 0x0fff |
    +-------------------+-------------------+

    Using mirroring with tilemaps makes for some tricky coding when it comes
    to updating the screen. Since they are logically separate tilemaps, vram
    address incrementing mechanisms typically cause the next address to remain
    within the same 32x32 tilemap. For example, it is not possible to update a
    vertical line of tiles starting at offset 0x001f and ending at 0x081f with
    only a single DMA transfer. Assuming VMAINC is configured to move
    vertically in the first place, after hitting address 0x3ff the DMA transfer
    will adjust the new address to 0x400, not 0x81f.
    
    The other tilemap size diagrams, for completeness:
    
    32x32 Tilemap Size
    
    +-------------------+
    | 0x0000 ... 0x001f |
    | .               . |
    | .      I        . |
    | .               . |
    | 0x03e0 ... 0x03ff |
    +-------------------+
    
    64x32 Tilemap Size
    
    +-------------------+-------------------+
    | 0x0000 ... 0x001f | 0x0400 ... 0x041f |
    | .               . | .               . |
    | .      I        . | .      II       . |
    | .               . | .               . |
    | 0x03e0 ... 0x03ff | 0x07e0 ... 0x07ff |
    +-------------------+-------------------+
    
    32x64 Tilemap Size 
    
    +-------------------+
    | 0x0000 ... 0x001f |
    | .               . |
    | .      I        . |
    | .               . |
    | 0x03e0 ... 0x03ff |
    +-------------------+
    | 0x0400 ... 0x041f |
    | .               . |
    | .      II       . |
    | .               . |
    | 0x07e0 ... 0x07ff |
    +-------------------+
    
    Starting at the tilemap address, the first $800 bytes are for tilemap A. Then
    come the $800 bytes for B, then C then D. Of course, if only A is required
    something else could be stuck in the empty space.
    
    Each entry in the tilemap is 2 bytes, formatted as (high low):
    
        vhopppcc cccccccc
        
        v/h  = Vertical/Horizontal flip this tile.
        
        o    = Tile priority.
        
        ppp  = Tile palette. The number of entries in the palette depends on the Mode
               and the BG.
        
        cccccccccc = Tile number.
        
    To find the tilemap word address for a particular tile (X and Y), you'd use a
    formula something like this:
        (Addr << 9) + ((Y & 0x1f) << 5) + (X & 0x1f) + 
     (SY ? ((Y&0x20)<<(SX ? 6 : 5)) : 0) + (SX ? ((X&0x20)<<5) : 0)
    
    The tile character data is stored at the address pointed to by registers
    $210b-c, starting at byte address:
      (Base<<13) + (TileNumber * 8*NumBitplanes)
    Each tile is (normally) 8x8 pixels. The data is stored in bitplanes.
    Each row of the tile fills 1 byte, with the leftmost pixel being in bit 7. For
    4-color tiles, bitplanes 0 and 1 are stored in the low and high bytes of a
    word, with 8 words making up the tile. For a 16-color tile, bitplanes 0 and 1
    are stored as for a 4-color tile, followed by bitplanes 2 and 3 in the same
    format. A 256-color tile is stored in the same way as 2 4-color tiles.

    If the appropriate bit of $2105 is set, each "tile" of the tilemap actually
    corresponds to a 16x16 pixel block consisting of Tile, Tile+1, Tile+16, and
    Tile+17. In this case, the 32x32 tile tilemap codes for a 512x512 pixel screen
    rather than a 256x256 pixel screen as normal. Thus, using both 16x16 tiles and
    the 64x64 tilemap each BG can be up to 1024x1024 pixels. There is no wrapping
    like there is for 16x16 sprites: if you specify Tile=$2ff, you'll get $2ff,
    $300, $30f, and $310 (as opposed to $2ff, $2f0, $20f, and $200 you might
    otherwise expect). $3ff goes to $000, of course. Flipping in this mode flips th
    whole 16x16 tile, not just the individual 8x8 tiles.


BG Scrolling
------------

Of course, depending on the BG mode and the interlace setting, Modes 0-6 have
an actual display of 256x224 or 256x239 pixels. The BG scroll registers
$210d-$2114 control the offset of the displayed area within that possible
256x256 to 1024x1024 pixel BG.

The display can never fall outside the BG: if that would seem to be the case,
simply wrap around back to 0 (or 'tile' the BG to fill the full 1024x1024,
however you like to think of it).

The registers $210d-$2114 are all write-twice to set the 16-bit value. The way
this works, the last write to any of these registers is stored in a buffer.
When a new byte is written to any register, the current register value, the
previous byte written to any of the 6 registers, and the new byte written
are combined as follows:
  For BGnHOFS: (NewByte<<8) | (PrevByte&~7) | ((CurrentValue>>8)&7)
  For BGnVOFS: (NewByte<<8) | PrevByte
For the most part, the details don't really matter as most games always write
two bytes to one of these registers. However, some games write only one byte,
or they do other odd things.

Thus, the tilemap entry for a particular X and Y position on the screen may be
calculated as follows:
  Size = 8 or 16 depending on the appropriate bit of $2105
  TileX = (X + BGnHOFS)/Size
  TileY = (Y + BGnVOFS)/Size
  Look up the tile at TileX and TileY as described above.

Note that many games will set their vertical scroll values to -1 rather than 0.
This is bacause the SNES loads OBJ data for each scanline during the previous
scanline. The very first line, though, wouldn't have any OBJ data loaded! So
the SNES doesn't actually output scanline 0, although it does everything to
render it. These games want the first line of their tilemap to be the first
line output, so they set their VOFS registers in this manner. Note that an
interlace screen needs -2 rather than -1 to properly correct for the missing
line 0 (and an emulator would need to add 2 instead of 1 to account for this).


Direct Color Mode
-----------------

For the 256-color BGs of Modes 3, 4, and 7, $2130 bit 0 when set enables direct
color mode. In this mode, instead of ignoring ppp and using the character data
as the palette index, you treat the character data as expressing a color
BBGGGRRR, and use the 3 bits of ppp as bgr to make the color
  Red=RRRr0, Green=GGGg0, Blue=BBb00

In direct color mode you cannot have a black pixel, since any pixel with
character data = 0 is still considered transparent. Use one of the almost-black
colors instead (01, 08 or 09 are good choices).


Mode 0
------

In Mode 0, you have 4 BGs of 4 colors each. To calculate the starting palette
entry for a particular tile, you calculate:
  ppp*4 + (BG#-1)*32

The background priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  BG2 tiles with priority 1
  Sprites with priority 2
  BG1 tiles with priority 0
  BG2 tiles with priority 0
  Sprites with priority 1
  BG3 tiles with priority 1
  BG4 tiles with priority 1
  Sprites with priority 0
  BG3 tiles with priority 0
  BG4 tiles with priority 0


Mode 1
------

In Mode 1, you have 2 BGs of 16 colors and 1 BG of 4 colors. To calculate the
starting palette entry, calculate:
  ppp*ncolors

The background priority varies depending on the setting of bit 3 of $2105.
The priority is (from 'front' to 'back'):
  BG3 tiles with priority 1 if bit 3 of $2105 is set
  Sprites with priority 3
  BG1 tiles with priority 1
  BG2 tiles with priority 1
  Sprites with priority 2
  BG1 tiles with priority 0
  BG2 tiles with priority 0
  Sprites with priority 1
  BG3 tiles with priority 1 if bit 3 of $2105 is clear
  Sprites with priority 0
  BG3 tiles with priority 0


Mode 2
------

In Mode 2, you have 2 BGs of 16 colors each. To calculate the starting palette
index, calculate:
  ppp*16

The priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  Sprites with priority 2
  BG2 tiles with priority 1
  Sprites with priority 1
  BG1 tiles with priority 0
  Sprites with priority 0
  BG2 tiles with priority 0

Note the change from Modes 0 and 1.

Mode 2 is the first of the Offset-Per-Tile Modes. In this mode, the 'tile
data' for BG3 actually encodes a (possible) replacement HOffset and/or
VOffset value for each tile of BG1 and/or BG2.

Consider a visible scanline. Normally, you'd get the pixels something like
this:

    HOFS = X + BGnHOFS
    VOFS = Y + BGnVOFS
    Pixel[X,Y] = GetPixel(GetTile(BGn, HOFS, VOFS), HOFS, VOFS)

With offset-per-tile, the formula is a little more complicated:
  
    HOFS        = X + BGnHOFS
    VOFS        = Y + BGnVOFS
    ValidBit    = 0x2000 for BG1, or 0x4000 for BG2
  
    if(!IsFirst8x8Tile(BGn, HOFS))
    {
        /* Hopefully these calculations are right... */
        Hval = GetTile(BG3, (HOFS & 7) | ( ( (X - 8) & ~7 ) + ( BG3HOFS & ~7 ) ), BG3VOFS )
        Vval = GetTile(BG3, (HOFS & 7) | ( ( (X - 8) & ~7 ) + ( BG3HOFS & ~7 ) ), BG3VOFS + 8 )
        
        if(Hval & ValidBit)
            HOFS = (HOFS & 7) | ((X & ~7) + (Hval & ~7))
        
        if(Vval & ValidBit)
            VOFS = Y + Vval
    }
    
    Pixel[X,Y] = GetPixel(Get8x8Tile(BGn, HOFS, VOFS), HOFS, VOFS)

In other words, number the visible tiles in BGn from 0-32, and the 'visible'
tiles in BG3 the same way. BGn tile 0 is offset as normal, then for 1<=T<33
BGn tile T gets the offset data from BG3 tile T-1. It doesn't matter whether
or not the tiles actually align in any way.

Note that the leftmost visible tile is done as normal in all cases (although
as little as 1 pixel may be visible, and if that still bothers you then use
a clip window to hide it), and the next tile uses the tilemap entry for what
would be BG3's leftmost tile. Note also that the 'new' offset completely
overrides the BGnVOFS register, but the lower 3 bits of the BGnHOFS offset
are still used. And note that the current Y position on the screen does not
affect which row of the BG3 tilemap to reference, it's as if Y were always 0.

On the other hand, note that even if BGn is 16x16 tiles, BG3 can specify the
offset for each 8x8 subtile. And if BG3 is 16x16, the offsets will apply to
all the corresponding 8x8 subtiles on BGn. Also note that if BG3 is 16x16, we
may end up using the same tile for Hval and Vval.


Mode 3
------

In Mode 3, you have one 256-color BG and one 16-color BG. To calculate the
starting palette index, calculate:
  BG1: 0
  BG2: ppp*16

The priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  Sprites with priority 2
  BG2 tiles with priority 1
  Sprites with priority 1
  BG1 tiles with priority 0
  Sprites with priority 0
  BG2 tiles with priority 0

Note that register $2130 may enable Direct Color Mode on BG1.


Mode 4
------

In Mode 4, you have one 256-color BG and one 4-color BG. To calculate the
starting palette index, calculate:
  BG1: 0
  BG2: ppp*4

The priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  Sprites with priority 2
  BG2 tiles with priority 1
  Sprites with priority 1
  BG1 tiles with priority 0
  Sprites with priority 0
  BG2 tiles with priority 0

Note that register $2130 may enable Direct Color Mode on BG1.

Mode 4 is the second of the Offset-Per-Tile Modes. It operates much like
Mode 2, however the SNES doesn't have time to load two offset values.
Instead, it does this:
    Val = GetTile(BG3, ...)
    if (Val&0x8000) {
      Hval = 0
      Vval = Val
    } else {
      Hval = Val
      Vval = 0
    }


Mode 5
------

In Mode 5, you have one 16-color BG and one 4-color BG. To calculate the
starting palette index, calculate:
  ppp*ncolors

The priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  Sprites with priority 2
  BG2 tiles with priority 1
  Sprites with priority 1
  BG1 tiles with priority 0
  Sprites with priority 0
  BG2 tiles with priority 0

Mode 5 is rather different from the previous modes. Instead of using an 8/16
pixel wide tile as normal, it always takes a 16 pixel wide tile (the height
may still be 8 or 16) and only uses half the pixels (zero-based, the even
pixels for subscreen tiles and the odd pixels for mainscreen tiles). Then it
forces pseudo-hires on to render a 512-pixel wide scanline. Also, if
Interlace mode is on (see bit 0 of $2133), the screen is 448 or 478
half-lines high instead of 224 or 239. Either the odd half-lines or the even
half-lines are drawn each frame, as indicated by bit 7 of $213f.

Note that this means you must set $212c and $212d to the same value to get the
'expected' display.


Mode 6
------

In Mode 6, you have only one 16-color BG. To calculate the starting palette
index, calculate:
  ppp*ncolors

The priority is (from 'front' to 'back'):
  Sprites with priority 3
  BG1 tiles with priority 1
  Sprites with priority 2
  Sprites with priority 1
  BG1 tiles with priority 0
  Sprites with priority 0

Mode 6 has the same oddities as Mode 5. In addition, it is an offset per tile
mode! That part works just like as Mode 2. However, remember that Mode 6 always
uses 8 pixel (16 half-pixel) wide tiles, this applies to BG3 as well as BG1.
You can't apply the offset to an 8-half-pixel tile nor to a 16-pixel wide area
(except by using two offset values for the two 8-pixel areas).


Mode 7
------

Mode 7 is extremely different from all the modes before. You have one BG of 256
colors. However, the tilemap and character map are laid out completely
differently.

The tilemap and charactermap are interleaved, with the character data being in
the high byte of each word and the tilemap data being in the low byte (note
that in hardware, VRAM is set up such that odd bytes are in one RAM chip and
even in another, and each RAM chip has a separate address bus. The Mode 7
renderer probably accesses the two chips independently). The tilemap is 128x128
entries of one byte each, with that one byte being simply a character map
index. The character data is stored packed pixel rather than bitplaned, with
one pixel per byte. Thus, to calculate the tilemap entry byte address for an X
and Y position in the playing field, you'd calculate: (((Y&~7)<<4) + (X>>3))<<1

To find the byte address of the pixel, you'd calculate:
  ( ( (TileData << 6 ) + ( (Y & 7) << 3) + (X & 7) ) << 1) + 1
 
Note that bits 4-7 of $2105 are ignored, as are $2107-$210c. They can be
considered to be always 0.

The next odd thing about Mode 7 is that you have full matrix transformation
abilities. With creative use of HDMA, you can even change the matrix per
scanline. See registers $211b-$2120 for details on the matrix transformation
formula. The entire screen can be flipped with bits 0-1 of $211a.

And finally, the playing field can actually be made larger than the tilemap. If
bit 7 of $211a is set, bit 6 of $211a controls what is seen filling the space
surrounding the map.

The background priorities are:
  Sprites with priority 3
  Sprites with priority 2
  Sprites with priority 1
  BG1
  Sprites with priority 0

When bit 6 of $2133 is set, you get a related mode known as Mode 7 EXTBG. In
this mode, you get a BG2 with 128 colors, which uses the same tilemap and
character data as BG1 but interprets the high bit of the pixel as a priority
bit. The priority map is:
  Sprites with priority 3
  Sprites with priority 2
  BG2 pixels with priority 1
  Sprites with priority 1
  BG1
  Sprites with priority 0
  BG2 pixels with priority 0

Note that the BG1 pixels (if BG1 is enabled) will usually completely obscure
the low-priority BG2 pixels.

BG2 uses the Mode 7 scrolling registers ($210d-e) rather than the 'normal' BG2
ones ($210f-10). Subscreen, pseudo-hires, math, and clip windows work as
normal; keep in mind OBJ and that you can do things like enable BG1 on main and
BG2 on sub if you so desire. Mosaic is somewhat weird, see the section on
Mosaic below.

Note that BG1, being a 256-color BG, can do Direct Color mode (in this case, of
course, there is no palette value so you're limited to 256 colors instead of
2048). BG2 does not do direct color mode, since it is only 7-bit.


Rendering the BGs
-----------------

Rendering a BG is simple.

1) Get your H and V offsets (either by reading the appropriate registers or by
   doing the offset-per-tile calculation).
2) Use those to translate the screen X and Y into playing field X and Y
   - Note this is rather complicated for Mode 7
3) Look up the tilemap for those coordinates
4) Use that to find the character data
5) If necessary, de-bitplane it and stick it in a buffer.

See the section "RENDERING THE SCREEN" below for more details.

Unresolved Issues
-----------------

1) What happens to the very first pixel on the scanline in Hires Math?
2) Various registers still need to know when writing to them is effective.


WINDOWS
=======

The masking windows are pretty simple. The windows can be used to mask off a
portion of any BG on the scanline. With HDMA, they can be adjusted per
scanline. They can be combined in various ways, per BG. Each can be used to
select either the region of the BG to keep, or the region of the BG to hide,
per BG. All that's left is to see the registers above and the section
"RENDERING THE SCREEN" below for details.

The Color Window
----------------

The color window is rather different. The color window itself can be set
to clip the colors of pixels to black (before math, so it's almost the same
effect you'd get by setting all entries in the palette to black, then fixing
them before you do subscreen addition--the only difference is that half math
will not occur), and to prevent all color math effects from occurring. These
can be applied never, always, inside the "clip" windows specified for the color
window, or outside the "clip" window.

Bits 6-7 of register $2130 controls whether the pixel colors (and half-math)
will be clipped inside the window, outside the window, never, or always. Bits
4-5 do the same for preventing color math.

Consider the main screen set up so BGs 1 and 2 are visible in an 8x8
checkerboard pattern, with all the BG1 pixels red and all the BG2 pixels blue.
The subscreen is filled with a green BG, and color math is enabled on BG 1
only. You'll end up with a yellow and blue checkerboard. Turn on the color
window to clip colors, and you'll get a green and black checkerboard since
the subscreen is only added (to a black pixel) where BG1 would be visible. If
you clip math instead, you'll get the same display you'd get with color math
disabled on all BGs.

In hires modes, we use the previous main-screen pixel to determine whether the
color window effect should be applied to a subscreen pixel. See "Color Math"
below for details.


RENDERING THE SCREEN
====================

Mosaic
------

The mosaic filter is applied after the BG is rendered and scrolled but before
it is clipped, combined with other BGs, pseudo-hiresed, or mathed. Each XxX
block of pixels is replaced with the upper-leftmost pixel of the block. The
'blocks' are such that the upper-leftmost block is at the left edge of the
screen at the scanline where $2106 was written (or the first visible scanline
if it was not written this frame).

Modes 5/6 Hires work slightly differently: they use a 2XxX block of
half-pixels. Similarly, Modes 5/6 interlaced use a 2Xx2X block of half-pixels.
So if you set $2106 to $0F ("1x1" blocks), the even half-pixels will be
expanded to cover the odd half-pixels. $1F would cover the next even-and-odd
pixel over as well. An example: put a single red pixel at line #1 pixel #0 of
Mode 5 BG1, and a single blue pixel in the same place on BG2. Enable BG1 on
main and BG2 on sub, you'll see the blue pixel only. Set $2106=$03, and you'll
suddenly see both the blue and red pixels. Set $2106=$13, and you'll see
"BRBR" on two lines.

Mode 7's matrix transformations do not affect the mosaic block positions, so
BG1 can be mosaiced about as normal. BG2 in EXTBG mode is weird, though: it
uses bit 0 of $2106 to control "vertical mosaic" and bit 1 to control
"horizontal mosaic". So if $2106 is $F1, BG2 will expand with 1x16 blocks. $F2
will give 16x1 blocks, and only $F3 will give the expected 16x16 blocks. Note
that BG1 still uses bit 0 as usual, so you can have BG1 expanded with 16x16
blocks and the high-priority BG2 pixels expanded with 1x16 blocks on top of it.
Or you could have BG1 rendered as normal, but with the high-priority pixels
from BG2 expanded 16x1 on top of it.


Color Math
----------

Each main-screen BG (and the color-0 backdrop, and the sprites (although
sprites with palettes 0-3 never participate)) may be marked in register $2131
to participate in color math. If the visible pixel is from a layer/OBJ
participating in color math, we perform one of 8 operations on the pixel,
depending on $2130 bit 1 and $2131 bits 6-7.

  0 00: Add the fixed color. R, G, and B are added separately, and clipped to
        the max.
  0 01: Add the fixed color, and divide the result by 2 before clipping (unless
        the Color Window is clipping colors here).
  0 10: Subtract the fixed color from the pixel. For example, if the pixel is
        (31,31,0) and the fixed color is (0,16,16), the result is (31,15,0).
  0 11: Subtract the fixed color, and divide the result by 2 (unless CW etc).
  1 00: Add the corresopnding subscreen pixel, or the fixed color if it's the
        subscreen backdrop.
  1 01: Add the subscreen pixel and divide by 2 (unless CW etc), or add the
        fixed color with no division.
  1 10: Subtract the subscreen pixel/fixed color.
  1 11: Subtract the subscreen pixel and divide by 2 (unless CW etc), or sub
        the fixed color with no division.

In hires modes, color math is applied to the visible subscreen pixels as well.
Choosing the math operation is simple: look at the previous main-screen pixel
(i.e. if we're at pixel #6 on the 512-pixel screen (which is taken from pixel
#4 on the subscreen), we look at pixel #5 (#3 on the main screen)). If no math
was applied to that pixel, don't math this subscreen pixel either. If the
fixed color was added/subtracted, add/subtract the fixed color. And if a pixel
from the subscreen was added/subtracted, add/subtract that main-screen pixel
(the original value before math). What happens to the subscreen pixel at the
left edge of the screen is unknown.

This is really important with color subtraction: normally, if you have
a block of cyan (#00ffff) on main and a block of magenta (#ff00ff) on sub,
subtraction would give a block of green. Hires math will give you a block of
alternating green and red, which will probably appear yellow on your TV. If
you've set $2131 bit 6 and this block is sitting alone in the middle of the
backdrop, you'll have a bright line at the left edge where the fixed color was
subtracted from the subscreen pixel and no 1/2 was applied (because the
previous main pixel had the fixed color subtracted and no 1/2 applied).


Rendering the Screen
--------------------

Note that this may be inaccurate.

 1) Go down the priority list to find the first BG/OBJ layer that is enabled on
    main, not clipped, and has a non-transparent pixel here. You'll always
    bottom out on the backdrop (color 0) if not before.
 2) If the color window clips colors here, set the color of that pixel to 0.
 3) If color math is applicable and the color window doesn't clip math here, do
    math.

Hires modes (BG modes 5 and 6 or any mode 0-4 with bit 3 of $2133 set) should
process the visible subscreen pixels as described above.



CONTROLLERS
===========

The SNES has 2 controller ports on the front of the unit, and an "expansion
port" on the bottom (which AFAIK was only used by a few things released only
in Japan). Little is known about the expansion port.

A number of peripherals could be plugged into the controller ports:
 * Joypads
 * The Multitap (aka MP5), into which up to 4 joypads may be plugged.
 * A Mouse, with 2 buttons.
 * The SuperScope, a bazooka-like light gun.
 * The Konami Justifiers, a normal style gun into which a second gun could
   be plugged.

There are probably others, these are just the ones I know anything about.


Generic
-------

The controller ports of the SNES has 7 pins, laid out something like this:
   _________________ ____________
  |                 |            \
  | (1) (2) (3) (4) | (5) (6) (7) |
  |_________________|____________/

The pins are:
 1: +5v (power)
 2: Clock
 3: Latch
 4: Data1
 5: Data2
 6: IOBit
 7: Ground

Latch is written trhough bit 0 of register $4016. Writing 1 to this bit
results in Latch going to whatever state means 'latch' to a joypad.

Clock of Port 1 is connected to the 'read' signal of $4016, in that reading
$4016 causes Clock to transition. Data1 and Data2 are then read, and Clock
transitions back (at this point, the pad is expected to stick its next bits
of data on Data1 and Data2). Clock of Port 2 is connected to $4017.

Data1 and Data2 are read through bits 0 and 1 (respectively) of $4016 and
$4017 (for Ports 1 and 2, respectively). Thus, you must read both bits at
once, you can't choose to read only Data1 and leave Data2 for later.

IOBit is connected to the I/O Port (which is accessed through registers
$4201 and $4213). Port 1's IOBit is connected to bit 6 of the I/O Port, and
Port 2's IOBit is connected to bit 7. Note that, since bit 7 of the I/O Port
is connected to the PPU Counter Latch, anything plugged into Port 2 may
latch the H and V Counters by setting IOBit to 0.

Auto Joypad Read, when enabled by bit 0 of $4200, effectively does the
following (in pseudo-ASM):
  LDA $4212
  ORA #$01
  STA $4212  ; pretend it's writable
  
  LDA #$01
  STA $4016
  ; There may be a delay here
  STZ $4016
  
  LDX #$0010
  loop:
      LDA $4016
      REP #$20
      LSR
      ROL $4218
      LSR
      ROL $421C
      SEP #$20

      LDA $4017
      REP #$20
      LSR
      ROL $421A
      LSR
      ROL $421E
      SEP #$20
      
      DEX
  BNE loop
  
  LDA $4212
  AND #$7E
  STA $4212  ; pretend it's writable again


"Open Port"
-----------

If nothing is plugged into a port (or the thing plugged in doesn't connect to
the pin), the SNES will read zeros from Data1 and Data2.


Joypads
-------

The joypads return 16 bits of data out Data1, then one bits until
latched again. The data is:
  byetUDLRaxlr0000

b/y/a/x/l/r are the similarly named buttons. 'e' is select. 't' is start.
U/D/L/R are the pad directions. Note that the standard joypad can only
return either U or D set, and either L or R set. Some games will crash or
exhibit other odd behavior if both U and D and/or both L and R are set.

Data2 is not even connected, nor is IOBit.


Mouse
-----

The mouse returns 32 bits of data out Data1, and 1 bits thereafter. The data
is:
  00000000rlss0001 YyyyyyyyXxxxxxxx

l/r are the two mouse buttons. 'ss' are the "speed bits", which are
incremented mod 3 if Clock cycles while Latch is active. Y/X are the
direction bits (set is up/left), and yyyyyyy/xxxxxxx are the distance
traveled in the appropriate direction.

Supposedly, the 'speed bits' may not match the internal speed setting when
the mouse first receives power. The speed setting controls the delta curve
of the mouse, with 0 giving a flat curve and 2 giving the greatest delta
response.

Data2 and IOBit are presumably not connected, but this is not known for
sure.


SuperScope
----------

The SuperScope returns 8 bits of data out Data1, and 1 bits thereafter. The
data is:
  fctp00on

'f' is Fire, 'c' is Cursor, 't' is Turbo, 'p' is Pause, 'o' is Offscreen,
and 'n' is Noise.

The SuperScope has two modes of operation: normal mode and turbo mode. The
current mode is controlled by a switch on the unit, and is indicated by the
't' bit. Note however that the 't' bit is only updated when the Fire button
is pressed (i.e. the 'f' bit is set). Thus, when you turn turbo on the 't'
bit remains clear until you shoot, and similarly when turbo is deactivated
the bit remains set until you fire.

In either mode, the Pause bit will be set for the first strobe after the
pause button is pressed, and then will be clear for subsequent strobes until
the button is pressed again. However, the pause button is ignored if either
cursor or fire are down(?).

In either mode, the Cursor bit will be set while the Cursor button is pressed.

In normal mode, the Fire bit operates like Pause: it is on for only one strobe.
In turbo mode, it remains set as long as the button is held down.

When Fire/Cursor are set, Offscreen will be set if the gun did not latch during
the previous strobe and cleared otherwise (Offscreen is not altered when
Fire/Cursor are both clear).

Noise is set if there is interference in the infrared transmission from the
Scope to the receiver.

If the Fire button is being held when turbo mode is activated, the gun sets the
Fire bit and begins latching. If the Fire button is being held when turbo mode
is deactivated, the next poll will have Fire clear but the Turbo bit will not
be updated until the next fire (i.e. FcTp => turbo off => fcTp, not fctp).

The PPU latch operates as follows: When Fire or Cursor is set, IOBit is set
to 0 when the gun sees the TV's electron gun, and left a 1 otherwise. Thus,
if the SNES also leaves it one (bit 7 of $4201), the PPU Counters will be
latched at that point. This would also imply that bit 7 of $4213 will be 0
at the moment the SuperScope sees the electron gun.

Since the gun depends on the latching behavior of IOBit, it will only
function properly when plugged into Port 2. If plugged into Port 1 instead,
everything will work except that there will be no way to tell where on the
screen the gun is pointing.

When creating graphics for the SuperScope, note that the color red is not
detected. For best results, use colors with the blue component over 75% and/or
the green component over 50%.

Data2 is presumably not connected, but this is not known for sure.


Justifiers
----------

The Justifier returns 48 bits of data out Data1. Presumably it returns
one bits after (if so, it really only returns 32 bits), but this is not
known. The data is:
  0000000000001110 01010101TtSsl000 1111111111111111

T/t are the trigger states for guns 1 and 2. S/s are the start button states
for guns 1 and 2. 'l' indicates which gun was connected to IOBit: 1 means
gun 1, 0 means gun 2. Note that 'l' toggles even when gun 2 is not connected.

IOBit is used just like for the SuperScope. However, since two guns may be
plugged into one port, which gun is actually connected to IOBit changes each
time Latch cycles. Also note, the Justifier does not wait for the trigger to
be pulled before attempting to latch, it will latch every time it sees the
electron gun. Bit 6 of $213F may be used to determine if the Justifier was
pointed at the screen or not.

Data2 is presumably not connected, but this is not known for sure.


MP5
---

The MP5 plugs into one Controller Port on the SNES (typically Port 2), and
has 4 ports for controllers to be plugged into it (labeled 2 through 5). It
also has an override switch which makes it pass through Pad 2 and ignore
everything else.

If IOBit is 1, Clock is passed through to Pad 2 and Pad 3, Data1 is
connected to Data1 on Pad 2, and Data2 is connected to Data1 on Pad 3. If
IOBit is 0, Pads 4 and 5 are used instead of 2 and 3, respectively. In
either case, Latch is passed through to all pads, and IOBit is presumably
not passed through at all.

Note that Clock is only passed through to the pads that are actually being
passed through. Thus, you can read the first two pads (or let Auto-Joypad
Read do it), then toggle IOBit and read the other two pads manually. Most
games requiring more than 3 players do exactly this.

Also note that there is nothing preventing the MP5 from functioning
perfectly when plugged in to Port 1, except that the game must use bit 6 of
$4201 instead of bit 7 to set IOBit and must use the Port 1 registers
instead of the Port 2 registers. With 2 MP5 units, one could actually create
an 8-player game!

When Latch is active, 1s will be read from Data2 and 0s from Data1. This is
sometmies used to detect the presence of an MP5 unit. The override switch
disables this behavior.

There are reports that the MP5 does not react immediately when IOBit is
transitioned from 0 to 1. Thus, reading 2&3 then 4&5 will probably work
better than vice versa.


DMA AND HDMA
============

DMA, or "direct memory access" is found in a number of computer systems, not
just the Super Nintendo. It's basically a way for a peripheral or
coprocessor to read data directly from memory, instead of requiring the main
CPU to do a number of reads and writes. This is typically faster, if only
because it lets the system skip the opcode fetch-and-decode. In the SNES, the
CPU is paused during DMA since the address busses are in use for the transfer.

HDMA is similar in concept, though rather different in execution: instead of
transferring a block of memory all at once, it transfers a few bytes during
the H-Blank period of each scanline. This is extremely helpful, as most PPU
registers may only be changed during a frame (at least without glitching)
during this narrow window.

The SNES has 8 channels (numbered 0-7) that can be used for either DMA or HDMA.
HDMA takes priority over DMA if both are to occur at once, pausing all DMA and
terminating a conflicting DMA immediately. Lower-numbered channels take
priority over higher-numbered channels.


DMA
---

A DMA transfer has three main variables, and a number of setting bits. These
are: (those marked '*' must be set up before starting DMA)
* Direction (bit 7 of $43x0): Read from PPU or write to PPU?
* Fixed (bit 3 of $43x0): Adjust Address?
* Increment (bit 4 of $43x0): Direction to adjust Address?
* Mode (bits 0-2 of $43x0): See below...
* Port (register $43x1): If this is 'xx', the register accessed will be $21xx.
* AAddress (registers $43x2-4): Any CPU address, just like you'd use with
                                the Absolute Long addressing mode.
* Count (registers $43x5-6): The number of bytes to transfer.

See register $43x0 for the correspondance between the Mode bits and the
transfer mode. Note that One Register Write Once and One Register Write
Twice end up being the exact same thing, and Two Registers Write Once
and Two Registers Write Twice Alternale are the same, but that Two Registers
Write Once and Two Registers Write Twice Each are different.

DMA transfers take 8 master cycles per byte transferred, no matter the
FastROM setting. There is also an overhead of 8 master cycles per channel, and
an overhead of 12-24 cycles for the whole transfer.

The basic process seems to be:
 1. Get byte and write it to the destination.
    - The DMA seems to take advantage of the SNES's two address busses with one
      shared data bus. AAddress is pushed out Bus A, Port is pushed out bus B,
      and the read/write signals are sent according to Direction. The bus
      marked read obligingly put data on the bus, while the bus marked write
      obligingly writes that value.
    - Thus, since the PPU/APU/WRAM registers are only accessible via Bus B,
      attempts to access them via AAddress will result in Open Bus accesses.
    - Attempts to access WRAM via both Bus A and Bus B (registers 2180-3) will
      fail, with the 2180-3 access being Open Bussed.
    - Also, DMA cannot access the $4300-$437f registers nor $420b nor $420c.
      Writes will have no effect, and reads will return Open Bus.
 2. Adjust AAddress.
    - If Fixed is set, do nothing. Else if Increment is set, subtract one,
      else add one.
    - Note that the bank byte is not modified.
 3. Decrement Count. If count is not zero, then go to step 1.
    - Thus, if Count is initially zero, it wraps to 65535 before being
      tested. So you end up transferring 65536 bytes.

Note that Count ($43x5-6) ends up always 0, unless a conflicting HDMA
terminates the transfer early.


HDMA
----

HDMA has 4 flags and 5 variables. Again, those marked '*' are required
before starting HDMA. In addition, those marked '+' are required if HDMA is
to be started mid-frame.
* Addressing Mode (bit 6 of $43x0): If clear, Direct, else Indirect.
* Transfer Mode (bits 0-2 of $43x0): See below...
* Port ($43x1): As for DMA.
* AAddress ($43x2-4): Pointer to the HDMA Table. Not really 'required' for
  starting mid-frame, but unless you're going to stop it before the next
  init...
- Indirect Address ($43x5-6): Used with Indirect Bank. See below...
* Indirect Bank ($43x7): Used with Indirect Address. See below...
+ Address ($43x8-9): See below...
+ Repeat (bit 7 of $43xA): Whether to write every scanline or not
+ Line Counter (bits 0-6 of $43xA): See below...
- DoTransfer: Used internally.

Modes are the same as for DMA. However, note that only one cycle through the
mode is done per scanline, so One Register Write Once will write 1 byte per
scanline, while One Register Write Twice will write two.

For each scanline during which HDMA is active (i.e. at least one channel is not
paused and has not terminated yet for the frame), there are ~18 master cycles
overhead. Each active channel incurs another 8 master cycles overhead (during
which time $42xA is presumably loaded if necessary) for every scanline, whether
or not a transfer actually occurs. If a new indirect address is required, 16
master cycles are taken to load it. Then 8 cycles per byte transferred are
used. Thus, HDMA takes a maximum of 466 master cycles per scanline (if all 8
channels are active, require an indirect address load, and transfer 4 bytes).

The basic process has two sections. First, at the beginning of the frame (V=0
H=approx 6), for all active HDMA channels (see register $420c):
 1. Copy AAddress into Address.
 2. Load $43xA (Line Counter and Repeat) from the table. I believe $00 will
    terminate this channel immediately.
 3. Load Indirect Address, if necessary.
 4. Set DoTransfer to true.

The CPU is paused during this time. Overhead is ~18 master cycles, plus 8
master cycles for each channel set for direct HDMA and 24 master cycles for
each channel set for indirect HDMA.

If you are starting HDMA mid-frame, you must basically do the init process
manually by setting $43x8-A, and $43x5-6 for indirect channels. Note though
that there is no way to perform step 4, so no transfer will be done the first
transfer period. Also, note that a channel that has already terminated for the
frame cannot be restarted.
XXX: Or does it automatically do Step 4 when you enable the channel?

Then, for each scanline from V=0 to V=$e0 (or V=$ef is overscan is enabled) at
about H=$116:
 1. If DoTransfer is false, skip to step 3.
 2. For the number of bytes (1, 2, or 4) required for this Transfer Mode...
    a. Read a byte from Address or Indirect Address, and increment.
    b. Write the byte to Port, Port+1, Port+2, or Port+3, depending on the
       Transfer Mode and which byte we're on.
    - The same notes regarding DMA from PPU to PPU or RAM to RAM via $2180
      apply here as well.
 3. Decrement $43xA.
 4. Set DoTransfer to the value of Repeat.
 5. If Line Counter is zero...
    a. Read the next byte from Address into $43xA (thus, into both Line
       Counter and Repeat).
    b. If Addressing Mode is Indirect, read two bytes from Address into
       Indirect Address (and increment Address by two bytes).
       - One oddity: if $43xA is 0 and this is the last active HDMA channel for
         this scanline, only load one byte for Address, and use the
         $00 for the low byte. So Address ends up incremented one less than
         otherwise expected, and one less CPU Cycle is used.
    c. If $43xA is zero, terminate this HDMA channel for this frame. The bit in
       $420c is not cleared, though, so it may be automatically restarted next
       frame.
    d. Set DoTransfer to true.
 6. Continue with Step 1 next scanline.

HDMA does not occur during V-Blank, as any writes it might perform are
likely have no visible effect anyway. The start-of-frame processing then resets
all active channels at the end of V-Blank. This allows updating of the HDMA
registers during V-Blank without worrying about the transfer beginning
immediately and scribbling on the PPU state.

Note how the above implicitly defines the format of the HDMA table.
Explicitly, the format is a series of entries. Each entry begins with a line
count and repeat flag. If repeat is false, there is one scanline worth of
data following and the count is the number of scanlines to wait before
processing the next entry. If it's true, the line count is the number of
scanlines worth of data following. The data following is either a pointer to
the data (for Indirect HDMA), or the data itself (for Direct HDMA).

Looking at the above, it's clear why Address, and Repeat/Line Counter must
be initialized by hand when starting HDMA mid-frame: they're only
automatically initialized at the start of the frame. Note how AAddress is
not affected by HDMA, though Address and Repeat/Line Counter are.


HISTORY
=======

In the beginning... Well, ok, somewhere in the middle is where I came in. In
my beginning, there was Yoshi's register doc (the one with bananas) and
snesmap.txt (the one missing all those appendices). Both good register docs,
complete as far as bits go, but sorely lacking in the explanations. And there
was the snes9x source, with more clear semantics but many errors. I began
writing test ROMs for others to run, and discover the real behavior of the
SNES. Soon, someone lent me a device to test the ROMs myself.

I discovered many things, and lamented the errors in the documentation
available. Finally one day I decided to sit down and write out everything I
had discovered. An early version of this was the result. Along the way, and
continuing since, I've revised this document with new findings. I believe this
is the most accurate SNES PPU/graphics document available today. Enjoy!