Setting the VSCL register
RogerB
Posts: 2
This is the first time I've ever posted anything on any forum.....here goes. I have been deciphering (or trying to decipher) Eric Balls' NTSC Colorbar Generator Object - and I think I am nearly there in terms of understanding NTSC and video generation. However, there is one thing that puzzles me. In the code the VSCL register is frequently changed shortly before a WAITTVID instruction, and in some cases this changes both the pixel count and the frame count in the VSCL. Here's an example (I have added the line numbers for reference):1 MOV VSCL, vscls2cb ' 5.3us 0H to burst
2 WAITVID sync, blank
3 MOV VSCL, vsclbrst ' 9 cycles of colorburst
4 WAITVID sync, burstSo this is what I understand to be going on. Once, the WAITVID in line 2 is complete the video generator starts processing video using 'sync' and 'blank' for colours and pixels, and the pixel/frame clocks from VSCL as set in line 1 ('vscls2cb' - very catchy name). However, just as this video is being shifted out, along comes line 3 and changes the contents of VSCL with new pixel/frame clock information. So, how does the generator cope with this? All the code is written in such a way that it seems the "MOV VSCL,xxxxx" prior to the WAITVID instruction sets the pixel/frame clock for the transmission of the data in the WAITVID instruction, but this must mean that the change in VSCL does not take place until the WAITVID instruction is complete. However, I cannot find anything in the documentation that confirms that this is the case. Any help welcome.
2 WAITVID sync, blank
3 MOV VSCL, vsclbrst ' 9 cycles of colorburst
4 WAITVID sync, burstSo this is what I understand to be going on. Once, the WAITVID in line 2 is complete the video generator starts processing video using 'sync' and 'blank' for colours and pixels, and the pixel/frame clocks from VSCL as set in line 1 ('vscls2cb' - very catchy name). However, just as this video is being shifted out, along comes line 3 and changes the contents of VSCL with new pixel/frame clock information. So, how does the generator cope with this? All the code is written in such a way that it seems the "MOV VSCL,xxxxx" prior to the WAITVID instruction sets the pixel/frame clock for the transmission of the data in the WAITVID instruction, but this must mean that the change in VSCL does not take place until the WAITVID instruction is complete. However, I cannot find anything in the documentation that confirms that this is the case. Any help welcome.
Comments
While one is running, you have the time to get pixels, colors and modify VSCL ahead of when the next one needs that data. Without this, changing VSCL would have painful timing requirements. It's good practice to get it set nice and early. For drivers that are pushing the limits, setting VSCL too late may result in the subsequent and intended WAITVID not operating with the right data.
Now that's the expected use of it, and on TV displays there is usually plenty of time to write a driver that way. You jump from WAITVID to WAITVID, working through the display a piece at a time.
At any given time then, your code is prepping the NEXT WAITVID, and it's happening during the current WAITVID.
Kurenko identified the WHOP (waitvid hand off point), and has pushed what is possible by insuring the data is available right when the WAITVID needs it. You should go look at his drivers where this hand-off behavior can be seen precisely. The advantage to how he does it boils down to maximizing code time between WAITVIDS, and that results in higher pixel counts and or color options. Search on WHOP and or read the comments in some of his early VGA character drivers to get the info. He really did a fine job analyzing the more subtle details of WAITVID. I would consider his code and comments the authoritative reference.
The VCTL (I may have spelled that wrong and mean video control register) is not latched! That one takes immediate effect, FYI.