long dots

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
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

long dots

Post by jeffythedragonslayer »

I found this note in fullsnes:
fullsnes wrote: Notes: The Dot Clock has some slight stuttering on long dots during hblank (but doesn't disturb the baudrate too much). The PAL baudrate doesn't match too well, however, it is the divisor setting closest to 9600 baud.
What exactly is a long dot? Is it generated by the pixel clock having a longer cycle occasionally, so the PPU keeps generating the same color? Is it a hardware bug? Are there any games where I can witness some long dots? This is sadly the closet thing I have found to a definition:
Near wrote: Mon Jun 27, 2016 12:38 pm The long-dots are what the PPU does, and you see it with the PPU's counter latches.
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: long dots

Post by Joe »

The PPU generates 341 pixels per scanline (most of the time), but during some part of hblank it slows down the pixel clock so it only counts 340 pixels per scanline.

The occasional use of lines that are one pixel shorter (or longer) than normal controls the chroma subcarrier alignment and the resulting NTSC (or PAL) artifacts. The only connection to long dots is that a one-pixel-shorter scanline doesn't slow down the pixel clock, so the PPU renders and counts 340 pixels instead of rendering 341 and counting 340.

It seems to be an intentional design choice, not a bug, but I couldn't tell you exactly why.

Since the long dots happen during hblank, they aren't directly visible.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: long dots

Post by jeffythedragonslayer »

Thanks; I've been digesting these replies for awhile and think I understand enough to paraphrase:

The pixel clock is always ticking, even during hblank.

Most dots are 4 master clock cycles long, but long dots are 5 cycles long. This is what is meant by "slowing down the pixel clock." When long dots appear in groups of 4 of them adjacent, that eats up a total of 4 extra cycles whenever they do, so after those 4 long dots have been drawn the PPU has effectively drawn one fewer dot than normal during that time.
regiscaelus
Posts: 32
Joined: Thu Jan 24, 2019 1:35 am

Re: long dots

Post by regiscaelus »

Unzip the attached file and use Logic 2 from Saleae to view the data. It'll show you the long dots during hblank and the absence of long dots on line 240 (15th line after the start of vblank). This was taken from a super famicom in non-interlaced mode.
Attachments
HBLANK_VBLANK_DOTCLK.zip
SALEAE Logic Analyser Traces
(168.6 KiB) Downloaded 22 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: long dots

Post by lidnariq »

For the sake of this being searchable... Quickly checking a few random points, the time from HBLANK starting to the first "long dot" is 8655ns, or 46.5 dots. The four long dots appear to be reliably every second dot. Given that the rising clock of DOTCLK and HBLANK, and DOTCLK and VBLANK are coincident, this means it stretches the "right half dot" one main clock.

HBLANK is 12664ns long, or 68 dots.

My old logic analyzer traces ( viewtopic.php?p=173441#p173441 and viewtopic.php?t=14467 ) provide some much lower resolution (24MSa/sec or 12MSa/sec not 500MSa/sec) of the same, but now that I know what the higher-resolution one looks like it's easier to piece this together.

HSYNC is 4540ns long, or 24.5 dots. Time from end of HSYNC to first background fetch is 3500ns, or 19 dots. Specific sprite pattern slivers are thus stretched. Unfortunately, I do not quite have enough resolution to figure out which of the 68 sprite sliver fetches are the stretched ones, or how those map relative to the left edge of the visible pixels.
Post Reply