 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : CMM2: GetScanLine during Vertical Blanking
| Author | Message | ||||
vegipete Guru  Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Does the function GETSCANLINE return a particular value during vertical blanking? ======== I just figured out a way to test: define an interrupt when setting the mode, and print the value of GETSCANLINE in the interrupt. It returns a value greater the screen vertical resolution. The exact value seems to depend on how far into the VBL interval the software is when GETSCANLINE is processed. The minimum value I've seen is 625 for mode 1. Would the test "DO : LOOP UNTIL GETSCANLINE > MM.VRES" always work reliably to wait until the vertical blanking interval? Visit Vegipete's *Mite Library for cool programs. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
see here for VGA timings for the various modes. Look at 800x600@60Hz and you will see where 625 comes from. I think the way it works is that the count starts at vertical synch. Then there is back porch, then the valid lines, then front porch to give the total number of lines I'm not sure if the vertical synch lines are at the beginning or end of the count. For modes like 640x400 I share the 80 unused lines between front porch and back porch. |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
What does GETSCANLINE actually return? "DO : LOOP UNTIL GETSCANLINE > MM.VRES" does NOT work perfectly in mode 1. Using this before a SPRITE SHOW results in no part of a sprite showing on the bottom (20 lines?) of the screen. Instead, "MM.VRES + 20" to "MM.VRES + 26" appears to work cleanly, but this smacks of magic numbers that depend on the particular mode. Perhaps I must use the vertical blanking interrupt... Ah, courtesy of a typo in testing, "DO : LOOP UNTIL GETSCANLINE < 5" gives the result I desire, cleanly drawing a sprite anywhere legal with no tearing. ========== For anyone wondering, I do not use "=" in these tests for two reasons. The first is because number representation can be inexact, meaning for example that 0.1 may not equal 1/10. The second and more important reason is that the variable being checked (GETSCANLINE in this case) is asynchronous, meaning that there is no guarantee that a running program will see a particular value. The program can only check something at discrete time intervals, and that something could pass right through a particular value between those checks. The CMM2 is fast, real fast, but some signals are faster. From Peter's link above, vertical scan lines in mode 1 are 0.0264ms each, which should be slow enough that the CMM2 will catch them, but why temp fate? Edited 2020-09-21 03:53 by vegipete Visit Vegipete's *Mite Library for cool programs. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Just a note that integers will be exact, within their range. It's when floating point is used (or required due to range) that the problems start. (Your code using < makes sense here, of course.) John |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
