| |
oziphantom
Registered: Oct 2014
Posts: 478 |
More stable raster problems
Ok so getting super stable interupts issues ;)
First I did the standard inverted cycle counter 0-8 jitter as on Codebase, but it has a jitter of 0-3 clocks still, which makes it hard to chain the NMIs as each one will jitter and then after 4 of them you are looking at a jitter of 4 - 12 clocks per frame which will then just compound.
So Ninja method to the rescue, super stable to the clock, nice ;) However its uses the following
CIA #1 A
CIA #1 B
CIA #2 A
Which leaves me CIA #2 B, which is annoying. I need an NMI and an IRQ source. The NMI needs to be stable as I need to chain them, but the IRQ just needs to be about every 80 or so clocks, but the NMI needs to "win".
There was a look up opcodes and dynamically make some code to eat clocks, but that needs to trash places spread across the memory map and not really something I can work around I feel.
Any trick I'm missing, some other way to get an IRQ ever so many clocks? Or another way to mitigate the 1-3 jitter on the normal method? |
|
... 10 posts hidden. Click here to view all posts....
|
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
This doesn't give me arbitary stablisation does it? It only gets me it stable from a fixed X location on the screen. So if I want to have something that is on the sample X spot but 8 lines down for example, then its if fine, as I tune the 0 of the CIA timer such that it hits 0 when the VIC hits the X I want, and then make sure that the gap between the points I want to be stable on, are perfect multiples of 8 away from said point as the counter counts in 8s.
So if I want the "delta" to be (63*8)-1 then it works, and is easy to tune with a nop here and a bit ea there and I will get perfect stable lines all the way down the screen. But if I want 63*8 i.e each line there after should be 1 clock over
------
-------
-------
it will fail, as being one over will push the adjust into 1-8 not 0-7 then the next one over will make it 2,3,4,5,6,7,8,8 then the next one will be 3,4,5,6,7,8,8,0 and so it doesn't work |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Set the timer to count on a 63 cycle loop. Most of the line will be avoiding the 2,1,62,62,61 section. Put the dc04 value through a lookup table, or subtract from a magic number. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
As the shortest opcode has 2 cycles, it's impossible to use timer timer delay with 0-7 cycles.
But you can of course time 2-9 cycles and correct for the two cycles at another place (f.e removing a nop there). |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting JackAsser[...]
EOR #$07 is just an optimized 7-x that's independant of carry state. But since u get 8 also u can't use that optimization and must resort to carry-dependant subtraction.
With a suitable timer alignment one could also optimize the case with delay states 0,...,8 by using EOR #$0F, no?? |
| |
lft
Registered: Jul 2007
Posts: 369 |
Yes. A similar approach is to set the timer to 63 cycles, and then eor #63. This will give you a positive value that you can write into a branch instruction, and jump into a clockslide. It won't be zero-based, so you have to pad with dummy bytes after the branch. It can be combined with my penalty cycle trick (Improved clock-slide). |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Hang on a minute - if your interrupt source is a CIA timer running in continuous mode, you should be able to use that very same timer to tell you just how late you are running. The timer will be one of eight values a little below 312*63-1 (or whatever your limit is), so you should be able to just subtract the low byte from a magic number to tell you the required branch into the clock slide :) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Yes, you can. It was more just me understanding how the trick works, when you get part of a trick that is the super optimal version with only half the code and none of the caveats, you kind of have to go off the title and then flail around when things don't work. At one point I got it to work but couldn't get it to work again... it just so happened that the amount of code I had before the setting up of the 2nd timer was a right multiple to get the 0-7 range ;) but I didn't know at the time that was what I needed it to be.
The other aspect is I need to enter the routine, stabilise, set the timer and set a vic register in 40 clocks, so its tight, doing a 63 clock slide is not going to work ;) But I now need to work out the points I can hit, and the points that lead to death. I could be every 8,9 or 10, not sure at the moment, the CIAs are kooky and not well documented. and there is the A to consider as well. Then there is making a PAL version and a NTSC version which slides everything again ;)
I working on modifying VICE so the VIC will render the background colours to show if the CPU is executing
Normal
VIC IRQ
CIA IRA
CIA NMI
VIC DMA steal
so I can see when the various things fire, and to make sure my IRQS don't get to close to the NMIs as to block the NMIS as per Soci's post. |
| |
lft
Registered: Jul 2007
Posts: 369 |
ChristopherJam: Indeed, but a subtraction is four cycles whereas eor is two.
oziphantom: The overhead from the clockslide depends on the amount of jitter you need to support. Extra dummy-bytes that you always skip don't add to the overhead. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Yes. A similar approach is to set the timer to 63 cycles, and then eor #63. This will give you a positive value that you can write into a branch instruction, and jump into a clockslide. It won't be zero-based, so you have to pad with dummy bytes after the branch. It can be combined with my penalty cycle trick (Improved clock-slide).
Nice how 63 cycles on a line happens to be a power of two minus one, making the eor to behave as a subtraction. :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Setting up the timer to give $F,$E,...,$7 upon reading in the irq dejitter routine an EOR#$0F will produce fine branch-compatible bytes while being zero-based.
Ofcourse this also works with EOR#$3F, but you have to take care of the misalignment between the no.of timer values (there are 64 values with the 0) and the no.of cycles per line(one less)... plus the necessity to avoid the "wrong" $3F-byte when reading the timer value(as 0 is never read back but the starting value instead).
Therefore I proposed to use EOR#$0F to be on the save side;) |
| Previous - 1 | 2 - Next |
