Questions about the VGA video hardware
canadajones
Posts: 25
in Propeller 1
Okay, so I've been poring over the P1 manual, datasheet and counter addendum, in addition to reading and annotating 2 assembly language VGA drivers, and this is what I've found out.
1. The video generator (in VGA mode) is basically just a CTRA-driven thing that takes exactly what you give in a waitvid and writes it to outa (with the number of clocks needed to change
data set by vscl). This means that the generator can write potentially anything at any rate supported by the PLLA (it has to operate in a PLL mode).
2. Selecting the correct pixel clock and timing the sync lines falls to me, the programmer.
3. The counters are set by selecting the correct mode, FRQx and (optionally) PHSx. To operate as a normal oscillator (like a 555 or something), it must be set to either the PLL or the NCO
modes. To get the formula for the NCO mode, dig through the application note on the counters (for reference, the equation is: frequency in hertz = system frequency in hertz * FRQx /
2^32)
Now, I know all that is old news to most of you (like, the absolute basics.), but as a newcomer to the Propeller, I had to spend time finding this info, and I just want it here for posterity for the next poor sod googling this.
After reading some documentation on VGA (timing tables) and the assembly drivers (the bitmap one included with the prop tool, which uses the video hardware, and a barebones one doing everything manually), I'm left with a few questions.
1. Are there predefined "modes" for VGA, or can I just pump pixels at my chosen resolution?
2. How do I pick a good pixel clock?
3. How do I know how much back/front porch and hblank and vblank to have? Do I need to translate the timings to cycles of the CTRA clock?
4. Which timings are important to get tight, and which can be more loose?
5. How do I set VSCL properly when doing h/vblank and porches? Looking through Chip's code, he does some fancy things with the VSCL register, and I'm very confused.
My goal is to be able to kind of make a driver for each of my projects' needs and resources. I know the premade ones are way better, but I still want to have the option in case I need to squeeze things. I'd appreciate any help on these topics, I've kind of hit a dead end on my understanding, and any pointers would be very welcome.
1. The video generator (in VGA mode) is basically just a CTRA-driven thing that takes exactly what you give in a waitvid and writes it to outa (with the number of clocks needed to change
data set by vscl). This means that the generator can write potentially anything at any rate supported by the PLLA (it has to operate in a PLL mode).
2. Selecting the correct pixel clock and timing the sync lines falls to me, the programmer.
3. The counters are set by selecting the correct mode, FRQx and (optionally) PHSx. To operate as a normal oscillator (like a 555 or something), it must be set to either the PLL or the NCO
modes. To get the formula for the NCO mode, dig through the application note on the counters (for reference, the equation is: frequency in hertz = system frequency in hertz * FRQx /
2^32)
Now, I know all that is old news to most of you (like, the absolute basics.), but as a newcomer to the Propeller, I had to spend time finding this info, and I just want it here for posterity for the next poor sod googling this.
After reading some documentation on VGA (timing tables) and the assembly drivers (the bitmap one included with the prop tool, which uses the video hardware, and a barebones one doing everything manually), I'm left with a few questions.
1. Are there predefined "modes" for VGA, or can I just pump pixels at my chosen resolution?
2. How do I pick a good pixel clock?
3. How do I know how much back/front porch and hblank and vblank to have? Do I need to translate the timings to cycles of the CTRA clock?
4. Which timings are important to get tight, and which can be more loose?
5. How do I set VSCL properly when doing h/vblank and porches? Looking through Chip's code, he does some fancy things with the VSCL register, and I'm very confused.
My goal is to be able to kind of make a driver for each of my projects' needs and resources. I know the premade ones are way better, but I still want to have the option in case I need to squeeze things. I'd appreciate any help on these topics, I've kind of hit a dead end on my understanding, and any pointers would be very welcome.
Comments
with some rather tightly defined timing.
you know when you get it wrong, as the monitor cannot sync and parts of the picture are cutoff.
This seems to be somebody else playing around with VGA timing:
http://martin.hinner.info/vga/timing.html
http://tinyvga.com/vga-timing
Modern LCD's use the H and V sync rates to determine what the resolution is. You can adjust the dot clock outside of typical quite a ways. Vertical sync can sometimes be moved a long way off but some modes are more touchy than others.
Best to use porch (blanking) lengths that suit the target frequencies rather than the other way round.
Rule of thumb is place the sync pulses in the first half of the blanking times. Some are very early while others are more central. It doesn't seem to be that important in practice. Nor does the length of the sync pulse have much importance.
The scan converter issue is not a rescaling issue but an incoming pixel sampling issue at the monitor/TV (display).
The display will have info to say what its guess is. If it's an LCD and it hasn't guessed the resolution correctly then the pixel sampling will be out and you'll get uneven pixel sizes in the display's scan buffer - Which produces regular corrugations in the displayed image on the LCD.
It can't be made to look good while the resolution is guessed wrongly.
PS: DVI/HDMI/Displayport probably have an advantage over VGA on this point. I haven't done enough testing to know for sure, but I did notice a difference with the limited prop2 testing I've already done with the HDMI accessory board.
I'm still a bit confused though. When looking through Chip's 512x384 bitmap driver, I notice he does a fair bit of VSCL trickery around the blanking periods. Is this necessary? Or can I just tack on extra blank lines and run them with the same VSCL settings?
Theoretically yes, but in practice you will want to do some housekeeping during blanking to prepare the next line/frame, which would be difficult to do while feeding enough pixels to the video generator
So it's used kind of a "you just do this while I go do some chores" command? Sorry if my questions seem kind of dumb, but it's hard to understand the context around assembly code and why things are done a certain way.
yes
Yes, that's how it works
Alternatively, if you have an oscilloscope, use that to look at the sync signals.
mov vscl, hres waitvid synch_active, #0I don't that should be an immediate:
should be
And the value you put in FRQA evaluates to 48, which is waaay too low - Counter NCO frequency in HZ is actually ((FRQA/2³²)*CLKFREQ). For more info, read the counter appnote
It's slightly misaligned, but that's just the drivers talking, I think
The yellow is the visible lines. It appears like it's only doing one line of visible lines before immediately not doing something for a while. Is this normal? It's still connected with the 2 drivers.
In other news, it's not caused by vsynch. I added a plain jmp instead of the djnz after the hsynch, and the effect persists (though, the nop effect doesn't, for obvious reasons).