Visual S-PPU1/2 transistor simulation

[paulb-nl]

There are transistor simulations of both PPU chips:
PPU1
https://www.qmtpro.com/~nes/chipimages/visual5c77/

Nodenames: https://www.qmtpro.com/~nes/chipimages/visual5c77/nodenames.js

PPU2
https://www.qmtpro.com/~nes/chipimages/visual5c78/

Nodenames: https://www.qmtpro.com/~nes/chipimages/visual5c78/nodenames.js

Not everything works correctly but we can find out a lot of the low level behavior of the chips.

Nodes that seems to be wrongly named or broken:

PPU1

• _last_on_screen_line, _last_on_screen_line_not_fblanking These seem to be first line of VBlank
• _spr_vpos_adder_sum This adder seems to be _/oam_vpos + _opvct but should be _/oam_vpos + _opvct + 1 aka opvct - oam_vpos
• _spr_tile_vofs This V offset is inverted
• Sprite tile fetching always reads OAM sprite 127

[paulb-nl]

Sprite findings:

blank = vblank | force_blank

OAM latching

OAM is read in 16 bit words and during In-Range evaluation it only reads from word addresses 0, 2, 4 ,6 etc because it only needs X/Y.

OAM values (X/Y) are latched into registers every 2 pixel cycles if blank = 0 or internal OAM address bit 8 = 0 (_oam_address8). So in VBlank or Force blank the X/Y registers are still latched from OAM but only if _oam_address8 = 0.

Sprite In-Range evaluation continues in Force Blank but it uses the old latched X/Y values.

Sprite tile fetching:

For the sprite tile fetching Time period the sprite size does not matter, even with 8x8 size. It always just calculates the vertical tile offset (0-7) by OPVCT - OAM_Y and then bit 5 to 3 is the offset. The Horizontal offset can also be 0-7 with any sprite size.

Tile vertical offset calculation:

v = OPVCT - OAM_Y

if (obj_interlace) 
    v = { v[4:0], field }


if (!vflip | spr_8px)
    v_invert = 3'b000
else if (spr_16px)
    v_invert = 3'b001
else if (spr_32px)
    v_invert = 3'b011
else // spr_64px
    v_invert = 3'b111

v_tile = v[5:3] xor v_invert

if (vflip) 
    v_row = ~v[2:0] 
else 
    v_row = v[2:0] 

Undocumented sprite sizes

With the undocumented sizes 16x32 and 32x64 two of the obj size signals are active simultaneously. _obj_size_16px & _obj_size_32px or _obj_size_32px & _obj_size_64px. It seems that the Range and Time periods use a mix of the two sizes for different checks.

Sprite size	16x32	32x64
H/V In-Range	32x32	64x64
V Range interlace	32x(16/2)	64x(64/2)
Time fetch	16x16	32x32

Example: With a sprite size of 16x32 the sprite is still in range when the H position is set to -16. Time treats the sprite as 16x16 but with H position -16 it displays the tiles with horizontal offset 2 & 3 instead of 0 & 1.

Normally with sprite interlace enabled, the sprite height is halved but with a sprite size of 16x32 (32x32) it is treated as 32x8 instead of 32x16.

OAM address

oam_a: address out to OAM [7:0]
oam_address: internal address [8:0]
oamaddr: address in $2102/2103 [8:0]

All are word addresses.

Sprite Range only modifies oam_address[8:1]. Sprite Time does not modify oam_address.

If OAM priority rotation is disabled then bits 8:1 of oam_address are reset to 0 at the beginning of the line, otherwise it leaves the address the same. This is the only thing OAM prio does. It just continues every line at whatever oam_address is set to at the beginning of the line.

if (!oam_prio) begin
    oam_address[8:1] <= 0;
end

oam_address is reloaded with byte bit=0 at the rising edge of (first_line_vblank_not_force_blank) or write to $2102/2103.

oam_address <= oamaddr
oam_byte_sel <= 0

Address out to OAM

wire [7:0] oam_a

if (blank) 
    oam_a = oam_address[7:0]
else if (range)
    oam_a = { oam_address[7:1], 1'b0 }
else // time
    oam_a = { time_sprite, ophct[0] }

[paulb-nl]

_/clear_over_flags for clearing the Time and Range overflow flags is active after blank goes low. So the flags get cleared either at the end of Vblank or when disabling Force Blank.

old blank <= vblank | fblank
if (old blank & ~(vblank | fblank)) 
     clear_flags <= 1