PPU bus activity traces

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

PPU bus activity traces

Post by lidnariq »

Tried to get all of AWJ's requests.

Rather than a separate trace for each PPU mode, I used HDMA to switch to the next mode every 32 scanlines. Layer 1 is using 16x16 tiles, layers 2-4 are using 8x8 tiles. Sprites #0-95 are 16x16, sprites #96-127 are 8x8.

Every sixteenth word of the nametable for layer 1 has the "flipped horizontally" bit set.

Sample rate is now 12MHz, so the aliasing will be a bit more annoying (alternating between 167ns and 250ns instead of the true value of 186ns)

I couldn't get all the logic analyzer clips on one RAM, so this is a random mixture of lines on U5 and U4.

Pertinent details: BGnSC of $70, $74, $78, $7C; BGnNBA of 0, 3, 5, 6; OBSEL=$0A. HDMA changes BGMODE from $10...$16, each value lasting for 32 scanlines. HDMA changes BG3VOFS to get offset-per-tile to be visible.
Attachments
ppubusactivity_rev2_csv.7z
9MB uncompressed, 1million lines; first column is CSYNC, other column is PPU bus address in hexadecimal.
(272.23 KiB) Downloaded 419 times
ppubusactivity_rev2_sfc.7z
just for reference
(12.36 KiB) Downloaded 853 times
ppubusactivity_rev2.sr.zip
rename without .zip; open with sigrok pulseview
(506.43 KiB) Downloaded 390 times
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PPU bus activity traces

Post by lidnariq »

Well, let's try to recapitulate (edit: add link) AWJ's previous analysis, with the extra data:

Mode 0: no new insights.
Modes 1 & 3: Lower-addressed bitplane is fetched first
Mode 2: Also lower-addressed OPT row is fetched first
Mode 5: Fetch cadence appears to be completely identical to mode 3. Horizontal flip flag does reverse left-right fetch order.
Modes 4,6: No new insights beyond above.

Sprites: Lower-addressed bitplane is fetched first. Horizontally flipped sprites reverse sliver fetch order.

Each scanline fetches 33 slivers for tiles (taking 8 cycles per tile, for 264 total cycles), followed by 8 idle cycles (bus unchanging), followed by 34 slivers for sprites (taking 2 cycles per sliver, 68 total cycles).
That's only 340 cycles, but there's 341 usually; two extra half-cycles appear to be be inserted during hsync and immediately after it ends.

Hsync timing is not obviously aligned to sprite fetch cycles. It's hard to tell anything more precise with the comparatively low sample rate.
Last edited by lidnariq on Fri Jan 12, 2018 7:57 pm, edited 1 time in total.
creaothceann
Posts: 610
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: PPU bus activity traces

Post by creaothceann »

My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
whicker
Posts: 228
Joined: Sun Dec 13, 2009 11:37 am
Location: Wisconsin

Re: PPU bus activity traces

Post by whicker »

creaothceann wrote:somewhat relevant?
Damn cool seeing the triple 15-bit DAC of PPU2 in the upper left corner, and the 15-bit palette RAM in the bottom left corner.

As personally expected, the All-in-one chip is a lump of logic sausage squeezed around the earlier-tested handmade RAM blocks.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: PPU bus activity traces

Post by psycopathicteen »

lidnariq wrote:Well, let's try to recapitulate AWJ's previous analysis, with the extra data:

Mode 0: no new insights.
Modes 1 & 3: Lower-addressed bitplane is fetched first
Mode 2: Also lower-addressed OPT row is fetched first
Mode 5: Fetch cadence appears to be completely identical to mode 3. Horizontal flip flag does reverse left-right fetch order.
Modes 4,6: No new insights beyond above.

Sprites: Lower-addressed bitplane is fetched first. Horizontally flipped sprites reverse sliver fetch order.

Each scanline fetches 33 slivers for tiles (taking 8 cycles per tile, for 264 total cycles), followed by 8 idle cycles (bus unchanging), followed by 34 slivers for sprites (taking 2 cycles per sliver, 68 total cycles).
That's only 340 cycles, but there's 341 usually; two extra half-cycles appear to be be inserted during hsync and immediately after it ends.

Hsync timing is not obviously aligned to sprite fetch cycles. It's hard to tell anything more precise with the comparatively low sample rate.
What happens when you write to $2118 and $2119 during those 8 idle cycles?
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: PPU bus activity traces

Post by Señor Ventura »

lidnariq wrote:Well, let's try to recapitulate AWJ's previous analysis, with the extra data:

Mode 0: no new insights.
Modes 1 & 3: Lower-addressed bitplane is fetched first
Mode 2: Also lower-addressed OPT row is fetched first
Mode 5: Fetch cadence appears to be completely identical to mode 3. Horizontal flip flag does reverse left-right fetch order.
Modes 4,6: No new insights beyond above.

Sprites: Lower-addressed bitplane is fetched first. Horizontally flipped sprites reverse sliver fetch order.

Each scanline fetches 33 slivers for tiles (taking 8 cycles per tile, for 264 total cycles), followed by 8 idle cycles (bus unchanging), followed by 34 slivers for sprites (taking 2 cycles per sliver, 68 total cycles).
That's only 340 cycles, but there's 341 usually; two extra half-cycles appear to be be inserted during hsync and immediately after it ends.

Hsync timing is not obviously aligned to sprite fetch cycles. It's hard to tell anything more precise with the comparatively low sample rate.
But it only draws 256 sprite pixels, right?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PPU bus activity traces

Post by tepples »

Up to 272 sprite pixels are rendered into the line buffer. Some of them are transparent, and some are occluded by other sprite pixels, giving 256 pixels of output from the sprite layer.

Sprites aren't hi-res. Only one sprite pixel color can enter the compositor per pixel, unlike backgrounds where two different layers or two different pixels of a mode 5/6 layer can be displayed as half-pixels.
Post Reply