Frame length

TRAC · Post by **TRAC** » Mon Nov 15, 2004 4:48 am

byuusan wrote:Compared to what I've seen for the Genesis, Gameboy, and Wonderswan Color, yes. I admit I haven't really looked at any other systems in much detail...
The Genesis, for example, has one 68k official PDF, and two or three snippets of info from various hackers, which are pasted together in different orders, which make up about nearly all 10 different 'Genesis hardware' documents.

I'll admit I don't know much about Genesis documentation, and that Wonderswan family documentation is even worse than SNES/SFC, but Gameboy family did seem a good deal more complete and more organized, overall.

byuusan wrote:The main part I'm not clear on is the horizontal line refresh.
You say that it takes 341 dots except scanline 240:

If interlace is off (default), scanline 240 on 'odd' frames is 1 dot short (0-339, not 0-340).

byuusan wrote: I was under the impression the screen was always 0-339, or 340 total dots. And as such, one scanline was always 1,360 master cycles.
I take it that you mean only when interlace is enabled, the screen is 341 total dots, and when it is disabled, it is 340 dots? I don't think I have this right...

No, I meant exactly what I described. 341 dots per line on nearly all scanlines. The only scanline that is 1 dot short is line 240, and it is only short when interlace is disabled, and then on 'odd' frames.

To be clear, the 10-dot-per-scanline dead period (RAM refresh, probably) around dot ~128 is part of that 340/341 dots, and all frames appear to be one of those 3 lengths in dots (341x262-1, 341x262, and 341x263), and respectively in master cycles.

-TRAC

byuu · Post by **byuu** » Mon Nov 15, 2004 5:29 am

That... is... really, really weird.
I hope no games break without implementing that, as I'm going to be really hard pressed to add all that code for a one dot exception every two frames. v_v'
I'll give it time, though, and see what happens. As they say, Rome wasn't built in a day. Thanks for clarifying.

TRAC · Post by **TRAC** » Mon Nov 15, 2004 5:28 pm

It's not that weird, check out some of the later NES timing docs and you'll find it has the same quirk (except it always acts like interlace is off - because it doesn't support interlace, of course).

-TRAC

anomie · Post by **anomie** » Mon Dec 13, 2004 4:41 am

Hrm, let's see how well I understand this.

On an NTSC SNES, we normally have scanlines 0-261, each with 340 dots but dots $143 and $147 are 1.5 times as long as the rest, for a total of 1364 (341 'dots') per scanline. Except line 240 ($f0) every other SNES-frame, which has $143 and $147 the normal length. Does this have any relation to $213f bit 7? I'm not sure how this fits with NTSC's 525 scanlines per NTSC-frame, since this only adds up to 524.

In interlace mode, we instead have 262 scanlines in half the frames and 263 in the rest. I've confirmed this, if interlace (bits 0 or 1 in $2133) is set then you can even latch and set IRQs for this scanline. It latches about half as often as the rest, obviously. I haven't rigorously tested it, but so far this seems to be that V=262 is latched only when $213f.7 is 0.

No one knows about PAL, but since the spec says 625 scanlines where NTSC says 525 we should have exactly the same situation as long as we replace 261 with 311 and 262 with 312.

byuu · Post by **byuu** » Mon Dec 13, 2004 5:19 am

PAL mode has more scanlines?! I thought it just reduced the vertical blanking period to compensate for the increased resolution...
e.g. 256x224 has 38 offscreen lines, and 256x239 has 23...

I've also read that the 525-line mode was actually split into two scanlines. The reasoning being that the beam cannon on a TV writes left-to-right, but at the same time, is slightly slanted, and goes down towards the right near the other side of the screen. So to compensate, half a scanline is drawn at the bottom left to bottom middle, and half from the top middle to the top right.
From an emulation standpoint, I doubt this matters any, as the last line doesn't render anything anyway.

By the way, do you have a dot count for when V=262? I would assume 340, like the rest.

TRAC · Post by **TRAC** » Tue Dec 14, 2004 5:33 am

anomie wrote:On an NTSC SNES, we normally have scanlines 0-261, each with 340 dots but dots $143 and $147 are 1.5 times as long as the rest, for a total of 1364 (341 'dots') per scanline. Except line 240 ($f0) every other SNES-frame, which has $143 and $147 the normal length. Does this have any relation to $213f bit 7? I'm not sure how this fits with NTSC's 525 scanlines per NTSC-frame, since this only adds up to 524.

I just checked my unit, and while the time period of 341 dots exists (at least on scanline 1, the one I just checked) the highest value I was able to latch WAS 339. I've yet to try to check which dots aren't the same length. So far, I'm guessing you have it right, anomie. When I go and check the dot lengths, I'll try to get a measurement for when the 'refresh' period starts.

-TRAC

Post by **grinvader** » Tue Dec 14, 2004 12:30 pm

byuusan wrote:PAL mode has more scanlines?! I thought it just reduced the vertical blanking period to compensate for the increased resolution...
e.g. 256x224 has 38 offscreen lines, and 256x239 has 23...

If it did that, PAL wouldn't be slower than NTSC... since VBlank would be much shorter.

evilant · Post by **evilant** » Tue Dec 14, 2004 8:16 pm

grinvader wrote:
byuusan wrote:PAL mode has more scanlines?! I thought it just reduced the vertical blanking period to compensate for the increased resolution...
e.g. 256x224 has 38 offscreen lines, and 256x239 has 23...
If it did that, PAL wouldn't be slower than NTSC... since VBlank would be much shorter.

There's some good info about PAL and NTSC at this page: http://www.videointerchange.com/pal_sec ... rsions.htm

To add to Grinvader's comment, notice that the horizontal frequency of PAL (15.625 or 15.750 kHz) and of NTSC (15.734 kHz) are basically the same...

illegal eagle · Post by **illegal eagle** » Tue Dec 14, 2004 8:35 pm

The comments to SECAM are funny.

Post by **grinvader** » Tue Dec 14, 2004 8:54 pm

illegal eagle wrote:The comments to SECAM are funny.

Please note that france, like Greece, uses PAL too. At least, that's what I heard.

illegal eagle · Post by **illegal eagle** » Tue Dec 14, 2004 9:40 pm

A quick search showed that TVs and other equipment support PAL. Dunno know about broadcasted signals...

Post by **grinvader** » Tue Dec 14, 2004 9:51 pm

illegal eagle wrote:A quick search showed that TVs and other equipment support PAL. Dunno know about broadcasted signals...

Ah, yeah, hertzian broadcasts still are in SECAM afaik... but 98.65% of the population uses satellite and/or cable for TV inputs now. Since there's no wave interference problem with those, I bet it's PAL. Even more since the same satellites output the same signal all over europe.

kieran_ · Post by **kieran_** » Wed Dec 15, 2004 11:08 am

Who is Byuusan anyway? Is he an emu author? He really seems to know his stuff!

byuu · Post by **byuu** » Wed Dec 15, 2004 12:22 pm

Stomping Nitrofish wrote:Who is Byuusan anyway? Is he an emu author? He really seems to know his stuff!

Hardly

I've just been lucky in that everyone's been tolerating all of my questions to get up to speed.

Post by **Nach** » Wed Dec 15, 2004 12:52 pm

byuusan wrote:
Stomping Nitrofish wrote:Who is Byuusan anyway? Is he an emu author? He really seems to know his stuff!
Hardly
I've just been lucky in that everyone's been tolerating all of my questions to get up to speed.

The dev forum has been dead for a while. I wouldn't say tolerate, I'd say thanks for bringing it back to life!

TRAC · Post by **TRAC** » Thu Dec 16, 2004 3:29 pm

Nach wrote:The dev forum has been dead for a while. I wouldn't say tolerate, I'd say thanks for bringing it back to life!

Indeed, Nach. Hurrah for byuusan, who is willing to ask questions, accept new information, and provide excuses for much info to be gathered and verified. Now if only I'd get around to verifying which 'dots' were longer...

-TRAC