 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
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
I have been investigating GETSCANLINE GETSCANLINE zero is always the start of the vertical sync pulse. First, I found the maximum value returned for each mode. It is of note that for some modes the maximum is half that of similar modes. mode 3.8 maximum is 499 while mode 3.12 is 249 That will make life interesting if you want to cater for more than one mode. Next, I measured the time from the start of the sync pulse to the start of video appearing. This was done visually on the CRO so not very precise. I converted this into lines. Next was the time between the end of video to the start of the sync pulse. This is also listed in uS and lines. In both cases, if the maximum scan line for a particular mode is half it's neighbours, you have to halve the line number. Most mode take between 20 and 30 uS per line so something like IF GETSCANLINE = 0 is not going to work reliably. You need to allow a range of values to be sure that your code will see the value. IF GETSCANLINE < 5 is a safe way to initialise an action and will work for all modes. Alternatively, you can sit in a tight loop waiting for your chosen line to arrive. That could be a full vertical trace period. If you really need the maximum time to setup the display, using IF GETSCANLINE > 460 AND GETSCANLINE < 470 will give you ~2.5mS to do your thing in mode 2.8 maximum getscanline display start display end 8 12 16 uS lines uS lines 1 627 627 627 700 26 50 626 2 499 499 499 1600 60 1100 460 3 499 249 499 1600 60 1100 460 4 499 499 499 1150 43 700 475 5 499 249 499 1150 43 700 475 6 499 249 499 500 18 0 498 7 499 249 499 500 18 0 498 8 499 499 499 500 18 0 498 9 805 805 700 33 100 801 10 516 516 516 1000 30 200 510 11 749 749 500 25 100 745 12 1124 562 550 36 50 1116 13 627 313 627 700 26 50 626 Jim VK7JH MMedit |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
This is because you had write page set to a page other than 0 (probably 1). I'll make it consistent in the next beta so it will always be like 12-bit colour. To get the best out of this you need also to know the front and back porch info for each mode. In particular for modes 2,3,4,5 there is lots more time available. I'll post something later in the day on this thread that perhaps can be included in the graphics manual |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
I hadn't thought about different pages having any effect. Now I think about it, I think I see why. I will do it again sticking to page 0 Jim VK7JH MMedit |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
Wait for the next beta as it will change to be the smaller value for all colour modes as was the case in 5.05 (I think?) Edited 2020-11-28 21:42 by matherp |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
Recent updates have changed GETSCANLINE a bit (for the better) GETSCANLINE zero is always the start of the first visible linee. The maximum value returned for each mode varies depending on the mode.. The table below contains the maximum value returned by GETSCANLINE for each mode. Finally it lists the time in microseconds for the time between the end of the last line and the start of the first line. Most mode take between 20 and 30 uS per line so something like IF GETSCANLINE = MM.VRES might take a few video frames before triggering. You need to allow a range of values to be sure that your code will see the value at the earliest opportunity.. IF GETSCANLINE > MM.VRES and GETSCANLINE < (MM.VRES+5) is a safer way to initialise an action and will work for all modes. GETSCANLINES mode display maximum uS of lines scan lines blanking 1 600 627 750 2 400 499 2690 3 200 249 2690 4 432 499 1800 5 216 249 1800 6 240 249 540 7 240 249 540 8 480 499 540 9 768 805 800 10 480 516 1190 11 720 749 670 12 540 562 670 13 300 313 750 All colour depths now report the same number of scan lines again and starting with zero equal to line zero makes a lot of sense. Jim VK7JH MMedit |
||||
| George H Newbie  Joined: 03/07/2020 Location: United StatesPosts: 31 |
Timely post! I was just wondering about this. So easy to make things work on this thing! |
||||
| George H Newbie Joined: 03/07/2020 Location: United StatesPosts: 31 |
So to make sure I'm understanding the chart above: mode 1 do ... loop while getscanline > mm.vres and getscanline < mm.vres+5 Should run the code in the do/loop in the blanking interval, provided it doesn't exceed 750 uS to execute? (27 scan lines) Or is a do/loop not the best construct for this. Goal is smooth screen drawing in the interval. Thanks! George |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
Most of the time, you can write to a page other than zero and use PAGE COPY x TO 0 ,B and let MMBasic do the timing. If you can't use that, how you wait until GETSCANLINE is greater than MM.VRES depends on you program flow. The sooner you do the write after the scan line reaches the start of the blanking period, the more time you have available. If your code takes longer than the blanking period, there 'may' be some visible artifacts. It depends on too many tings to know if that is a problem. Jim VK7JH MMedit |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1122 |
There are 3 versions of "PAGE COPY n,0[,B/D]" (Note "," seems to work the same as "TO") 1) PAGE COPY n,0 => copy the page now, pause the program until done, 2) PAGE COPY n,0,B => pause the program, wait for the next vertical blanking, then copy, then program continues, 3) PAGE COPY n,0,D => program continues execution, copy happens in the background at next vertical blanking. #1 is likely to get tearing. #2 is the safest visually. #3 is great if you have much computation to do before you start redrawing the image on page n. Method 3 would be safer to use if there were a way to test when the copy has finished. Visit Vegipete's *Mite Library for cool programs. |
||||
| George H Newbie Joined: 03/07/2020 Location: United StatesPosts: 31 |
Thanks for the info, 'D' seems to work the best in my case, it's smooth and the program is much quicker. I'm using mode 1 here, just messing around. I'm guessing the other modes (2-5, 10) should be quicker with I or B, because of more blanking time? I'll give them a try. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
