6 replies to this topic

[JAC!]

Hi,

Given the timings below I'd expect 228 scalines for the playfield in a 312 scanlines PAL frame.

; Type NTSC PAL/SECAM
; V-Sync 3 3 scanlines
; V-Blank 37 45 scanlines (upper border)
; Picture 192 228 scanlines
; Overscan 30 36 scanlines (lower border)
; Frame Rate 60 50 Hz
; Frame Time 262 312 scanlines

But when I try, I get 312 scanlines per frame already with 192 scanlines of playfield.
What am I doing wrong? Here's screenshot and the binary.



 PAL.bin   4K   25 downloads

[RevEng]

Stepping through it in Stella, it looks like your binary has 56 lines of overscan instead of 36 lines.

[JAC!]

Thanks. I found I had reused the code which was adapted from NTSC to PAL in order to keep the playfield height.

One more question regarding the height: Is is OK to preset TIA registers (player positioning, playfield, colors) in the VBLANK phase? Player/missle positioning always takes at least 1 scanline per object, so they would be lost for the playfield. Therefore I'd like to do that stuff before. Will that work?

[RevEng]

Yup. Those registers persist from line to line, so you can set them anywhere in the kernel.

[JAC!]

So what is the purpose of the VBLANK area then technically? Just having the playfield centered on the screen?

[RevEng]

The primary purpose of it is to produce an NTSC/PAL compliant signal. The way I understand it, the standards require it because the old CRTs couldn't instantly change the vertical position of the electron beam, so the beam gets hidden while it quickly sweeps to the top and settles back into the downward motion.

But yes, shortening or lengthening VBLANK will have the effect of moving the playfield up or down.

[JAC!]

Thanks! I reposition my objects during VBLANK now and have not black lines on the playfield