Exact timing with RTCC
Hi,
I need to time a section of code on an SX52 exactly. I currently have something along the lines of :
clr·RTCC
variable length code runs here
cjb·RTCC,·#159,·$··· want this to equal exactly 20320 cycles
I have the prescaler set at 1:256 so that there is no RTCC wrap around.
The problem with this is that because the timer is low res, I can't get the exact count and the cycles can fluctuate 256·up and down.
I was thinking of turning off the prescaler and triggerring an interrupt to increment a 16bit counter on the RTCC wrap around and then checking this.
Is this possible or is there a more elegant solution ?
·
I need to time a section of code on an SX52 exactly. I currently have something along the lines of :
clr·RTCC
variable length code runs here
cjb·RTCC,·#159,·$··· want this to equal exactly 20320 cycles
I have the prescaler set at 1:256 so that there is no RTCC wrap around.
The problem with this is that because the timer is low res, I can't get the exact count and the cycles can fluctuate 256·up and down.
I was thinking of turning off the prescaler and triggerring an interrupt to increment a 16bit counter on the RTCC wrap around and then checking this.
Is this possible or is there a more elegant solution ?
·
Comments
If the code IS exactly 20320 cycles then RTCC should be 79 during the 1:256 run, and RTCC should be 96 during the 1:1 run.
Another way would be to use one of the hardware timers.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·
cjb·RTCC,·#79,·$···· could continue with anything from 20224 to 20479(20224 + 255) cycles depending on the code preceding it.
Okay, I misunderstood what you wanted.
Since each cjb RTCC,#79,$ loop takes 6 cycles. I don't see how your going to get it to end on EXACTLY 20320.
Can you post your code ? What is the mimimum and maximum cycles used by your "variable length code" ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·
Even if I can't get exactly 20320 cycles, if I could get an exact figure below this then I could pad it out with a few nops after to get the delay I want. The problem is that depending on the amount of cycles the variable code (ie game logic) takes then I get a different delay (the range of the prescaler).
I've attached a simple example showing this.
I can't make the variable code a deterministic number of cycles as at some points in the game there could be say 10 sprites on screen, at other times only 5.
I would therefore like to have this 20000 or so cycles to play around with knowing that the overall delay would be exactly the same no matter how much of it I used.
Okay now I understand. For my video modules the video generation is done completely by interrupts. So the "main" code doesn't have to worry about finishing in a certain amount of time.
Andre' does something similar to what you need with the "XGameStation ME". The video code IS the main code and it calls a subroutine that does the "action", and when the subroutine returns, it waits for the next video frame time.
If you goto www.xgamestation.com and download the video engine you should be able to see how he does it.
Again, I much prefer to have the game code be the "main" and have the video generated completely by interrupts. But that's just me.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·
I guess the trick is to make sure that RTCC is less than 159 before you start looping. Then as soon as it hits 159 the loop will end.
The clock count could be off my as much as 6 cycles since that's how many cycles the loop takes.
Are you writing a game for the xgamestation ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·
I'll see if I can figure something out to make this more solid. It's a very minor change in the video picture but it's just annoying when you know it's there [noparse]:)[/noparse]
Set the RTCC prescaler to divide by 32, set up to interrupt on RTCC rollover, and in the ISR, preset a 2-byte counter to 635, then decrement it each ISR.
When it hits zero, you've reached exactly 20320 counts. Reset the countdown counter to 635 then do your action.
This seems like it should repeat on an exact 20320 count interval.
David
Maybe like this:
TEST counter
JNZ $-1
Okay so let's say the counter is 1, and the interrupt occurs right after the TEST instruction. It's going to be another 7 cycles until you get out of the loop.
Now let's say the counter is 1 and the interrupt occurs right before the TEST instruction. It's going to be another 3 cycles until your out of the loop. So there will still be 4 cycles of "play". Plus you have to figure in the cycles used for the interrupt call and return.
The problem is NOT setting a variable at the proper time. The problem is in the looping to wait for that variable.
You could just use RTCC and set it for -159 and wait for RTCC to reach zero the same way as your interrupt routine.
There may be a way around this, but I think an interrupt driven video generation method is best.
Interrupts are completely deterministic on the SX.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·
I don't know what action must be done every 20320 counts, but my idea was to do that action in the ISR. That way you would be repeating it exactly on the right count, not in user code where it would be subject to the variations of a test loop.
But of course, not knowing what that action is, I don't know if it can be done in the ISR.
Please don't take my comments as critizism of your method.
If I understand he is using basically the code for the XGS ME tile engine, and that code doesn't use interrupt to generate the video.
I think you and I are on the same page [noparse];)[/noparse] using interrupts to generate the video.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Never under estimate the importance of being nice when you don't have to be."
·