Hi! On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote: > > > > > Vertically, it's simpler, as the number of lines is discrete. > > > > > You do have to take into account interlace and doublescan, and > > > > > progressive modes with 262/312 lines. > > > > > > > > So we only have to deal with 525 and 625 lines total (without taking > > > > interlace and doublescan into account), right? > > > > > > Yes. > > > > > > > I guess we still have the same question, we probably want to center it, > > > > so top == bottom, but what about the vsync length? > > > > > > Unfortunately that table does not mention top and bottom margins. > > > But according to drivers/video/fbdev/amifb.c (see the "Broadcast > > > video timings" comment block and the definitions of the "ntsc-lace" > > > and "pal-lace" video modes), they are asymmetrical, too. > > > > > > Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't > > > have that info when I wrote amifb, as I used 4 lines there). > > > > Thanks, that's some great info already. > > > > It's mentioned though that the settings for NTSC are "straightforward", > > but it's definitely not for me :) > > As in NTSC just uses different pixel clock and horizontal/vertical sync > rate values... Oh, so the constants differ but the calculation is the same, ack. > > I've looked around and it looks like the entire blanking area is > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how > > 625 lines - 575[*] visible lines = 50 lines. > > [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting > a frame in two fields of equal size. > > "visible" is relative, as it includes the overscan region. > Some PAL monitors used with computers had knobs to control width/height > and position of the screen, so you could make use of most or all of > the overscan region It brings back some memories :) > but on a real TV you're limited to ca. 640x512 (on PAL) which is what > an Amiga used by default (with a 14 MHz pixclock). > > it's supposed to be split between the upper and lower margins and the > > sync period. > > "Field Synchronization of PAL System" on > http://martin.hinner.info/vga/pal.html shows the split. Thanks, that's excellent as well. I'm mostly done with a function that creates a PAL mode, but I still have one question. If I understand well, the blanking period is made up (interlace) of 16 pulses for the first field, 14 for the second, each pulse taking half a line. That amount to 30 pulses, so 15 lines. I first assumed that the pre-equalizing pulses would be the back porch, the long sync pulses the vsync, and the post-equalizing pulses the front porch. But... we're still missing 35 lines to amount to 625 lines, that seems to be counted in the field itself (305 lines == (575 + 35) / 2) So I guess my assumption was wrong to begin with. You seem to have used a fixed vsync in amifb to 4 lines, and I don't understand how you come up with the upper and lower margins (or rather, how they are linked to what's described in that page) Maxime
Attachment:
signature.asc
Description: PGP signature
