| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Raster sync question.
i'm writing a -reverse timer- raster sync routine.
In my routine the kernal is switched off and i use $fffe/f as irq vector.
Also all cia irq are switched off.
The main loop is an endless self jmp to avoid opcode cycles problem.
All routines work 'in irq' so i can omit the registers saving part. Every routine start just after the irq trigger.
The cia timer setup is in the initial sei/cli routine but the timer is started using a first raster irq call where the first 2 instructions are lda/sta $d019.
Timer is set up to cycle counter with $07 as value.
The stable irq part is stabilized with $dc04 eor #$07 and the result used to branch into a lda #$a9 part as in most stable irq routines.
To test i use an inc $d021 just to see where/if stable code work.
And it work... But not always at same point!
Sometimes the inc start under border and some others start after it!
The position change if routine is restarted. When run, the position never change.
How can i fix this making inc been executed always at same position?
|
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Not sure if I got this right, but I hope you are starting the timers AFTER stabilizing the timing? If not, then the whole routine may be shifted back/forth in time the way you describe, so that it is stable each time the routine is started, but that the stabilized point is different each time the routine is started over. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
the timer is setted before first 'stabilized' irq, using another 'normal' raster irq trigger. In my theory this mean at the start of raster line 'x'. This irq start when the endless jmp is running. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
The raster needs to be stable when you start the counter. Also some code would help. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@Flavioweb: Ok, that wont work. As I said, you need to stabilize first (triggering an interrupt when running an endless loop like "label: JMP label" does not mean you get stable timing) before you start the timer. Otherwise you don't know exactly when you started the timer and as a consequence the whole routine may start a little earlier or a little later, depending on the jitter you get because you haven't first stabilized.
Think of it. What you do is:
1. Start timer at unknown point in time
2. Sync interrupt to the timer.
Result: the routine is indeed stable relative to the counter (because of step 2), but since the point where you started the counter varies depending on when the timer was initially started you get the results you describe.
So.. you must fix step 1 so you start the timer at a stabilized point in time, in order to get the same results every time you start the routine.
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
ok.
But what is a 'precise source of time'?
Also if i use a cia irq, when this will be triggered related to raster?
I need to be + or - on same position when start sync counter...
how can i compensate this initial difference? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
> But what is a 'precise source of time'?
You could use the double interrupt method or any other available method for achieving stability in code relative to the raster beam. Read up on stable rasters on codebase64 or so:
http://codebase64.org/doku.php?id=base:interrupts#stable_timing
>Also if i use a cia irq, when this will be triggered related to raster?
That depends entirely on when you start the timer. If you start it at the start of a rasterline (step 1 above), and if we pretend for a moment that you have a timer that counts 63 cycles, then the timer will follow the rasterlines exactly since each rasterline is exactly 63 cycles long. However, this doesn't mean the interrupt will trig nicely exactly on the same point each time, due to cycle jitter, but that is where your $dc04 eor #$07 stuff comes in (step 2 above). (...but you could also use a raster irq of course and still stabilize using the timer, as long as the timer is started at a deterministic rather than unknown point in time.)
Hope I was very clear now. :) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
This might be useful:
shortest CIA-stable raster |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Hey, you could always force a character DMA (bad line) from partway across the screen, let VIC eat the remaining cycles. The instruction after your STA $d011 should be at a constant time.
I'm kind of surprised to not see that in the round up of stabilising methods at codebase64 TBH, it always seemed the simplest method to me, especially for routines at the top of the screen where you could do it just before the border runs out, so you don't even have to hide the three $ff characters fetched at DMA start.
(I know, "bring code!" etc etc) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: Hey, you could always force a character DMA (bad line) from partway across the screen, let VIC eat the remaining cycles. The instruction after your STA $d011 should be at a constant time.
I'm kind of surprised to not see that in the round up of stabilising methods at codebase64 TBH, it always seemed the simplest method to me, especially for routines at the top of the screen where you could do it just before the border runs out, so you don't even have to hide the three $ff characters fetched at DMA start.
(I know, "bring code!" etc etc)
What you mean exactly?
Some like lda $d012 and #$07 ora #$1b sta $d011 then code to stabilize? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yes, something like that. You also need to make sure your within the range of lines DMA is enabled for, of course. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
@Flavioweb, this doesn't directly answer your question, but you should be able to adapt it to your needs; I've just done a post on Stablising raster IRQ with DMA |
