Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums

Forums > C64 Coding > More stable raster problems
2017-04-01 17:16

Registered: Oct 2014
Posts: 174
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....
2017-04-02 13:02

Registered: Oct 2014
Posts: 174
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
2017-04-02 14:15

Registered: Aug 2004
Posts: 792
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.
2017-04-03 09:29
Monte Carlos

Registered: Jun 2004
Posts: 258
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).
2017-04-03 14:28

Registered: Dec 2001
Posts: 238
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??
2017-04-03 14:49

Registered: Jul 2007
Posts: 353
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).
2017-04-03 15:54

Registered: Aug 2004
Posts: 792
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 :)
2017-04-03 17:07

Registered: Oct 2014
Posts: 174
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
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.
2017-04-03 17:12

Registered: Jul 2007
Posts: 353
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.
2017-04-03 18:52

Registered: Jun 2002
Posts: 1316
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. :)
2017-04-03 22:21

Registered: Dec 2001
Posts: 238
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
JackAsser/Booze Design
Alias Medron/Padua
Harry Potthead
Guests online: 27
Top Demos
1 Uncensored  (9.7)
2 Comaland 100%  (9.7)
3 Edge of Disgrace  (9.7)
4 Coma Light 13  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 We Come in Peace  (9.6)
8 Lunatico  (9.6)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.5)
2 Pandemoniac Part 2 o..  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Dawnfall V1.1  (9.5)
5 Treu Love [reu]  (9.5)
6 In Memoriam BHF  (9.5)
7 Merry Xmas 2017  (9.4)
8 Dawnfall  (9.4)
9 SWiRL  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Splatterhead  (9.8)
3 Zyron  (9.8)
4 Acidchild  (9.8)
5 Walker  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.058 sec.