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: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.
long dots
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
long dots
I found this note in fullsnes:
Re: long dots
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.
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.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: long dots
https://problemkaputt.de/fullsnes.htm#s ... hvcounters
https://problemkaputt.de/fullsnes.htm#s ... nghvevents
https://raw.githubusercontent.com/gilli ... timing.txt
viewtopic.php?p=90550#p90550
viewtopic.php?p=90552#p90552
viewtopic.php?p=182400#p182400
viewtopic.php?p=199952#p199952
viewtopic.php?p=236890#p236890
https://problemkaputt.de/fullsnes.htm#s ... nghvevents
https://raw.githubusercontent.com/gilli ... timing.txt
viewtopic.php?p=90550#p90550
viewtopic.php?p=90552#p90552
viewtopic.php?p=182400#p182400
viewtopic.php?p=199952#p199952
viewtopic.php?p=236890#p236890
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: long dots
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.
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.
-
- Posts: 32
- Joined: Thu Jan 24, 2019 1:35 am
Re: long dots
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
Re: long dots
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.
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.