| |
Copyfault
Registered: Dec 2001
Posts: 475 |
Stable Raster via Timer
Maybe some of you advanced coders can help me with the following oddity. I'll keep out the basic routine for stabilizing rasters with the timer method, as it is presumably known to everyone!
If we ignore Illegal Ops for the moment, the max. number of cycles occuring in the main prog is 7 (when executing an indexed RMW). When it comes to the different values the variance can take, there should also be 7 (0 to 6 cycles). I wrote some (working!) routines, but I always end up having 8 different variance values. Of course one can live with it, but I wonder where this 8th state comes from!
If necessary, I'll deliver more details. I'd be really happy to understand this behaviour!
Yours, Copyfault |
|
... 65 posts hidden. Click here to view all posts....
|
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
@JackAsser: Never really tried to understand that method. Maybe I will when I decide to code a Viccy demo. ;)
> It's still a 6-cycle pattern when 5 is loaded,
> so there should be no difference. I don't read
> the timer value at all. I'll check that article
> out, though.
I wasn't talking about your code. It was an idea, which crossed my mind that maybe the chip's designers have had their trouble here, which lead to incompatibility. But that's pretty much irrelevant.
Tested both routines on 6526A - PAL.
Cycles per Frame:
19655
Timing test:
63 cycles per line
19656 cycles per frame
312 lines
CIA #2 timer delays by 0 cycles
Haven't tested with an old CIA, but I'm pretty sure that the values would be the same as in Vice. And strange enough, they are the same as on 6526A. Is the timer on continuous or one-shot mode?
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
The timer is in continuous mode. The number reported in "cyclesperframe.prg" just gives the timer value that syncs to the screen. "timingtest.prg" adds 1 to the value, because then it actually reflects the number of clocks per countdown cycle.
It shouldn't be too difficult for me to measure the "phase offset" effect of the old timer, if that's what it does. However, if somebody could run that program on a machine with old 6526's and verify that it still reports a timer delay of 0 cycles, that'd be awesome. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I'm getting a little bit paranoid about all these timing differences on different CIAs. If I've undestood everything correct is that if you are using the timer approach (either signel or double) to gain stable rasters you have to be aware if you have an old or new CIA, right? So, usually I only care about if it's PAL or NTSC and in most cases I actually simply drop the NTSC support, so what about the CIA chip? Is one chip version more common than another? Are the any unwritten rules what chip the compo machine have, etc..? Or do I simply have to detect and support both inorder to not get flamed by various people? =) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Graham, please don't scare people so much =) In reality, the different CIA delays won't be any problem. Graham said there are different timings of CIA interrupts on different machines. Well, so what?
The most common implementation of a CIA-timed raster stabilizer (on the C64) would be to set up _one_ timer (to repeatedly count 63 cycles on PAL) in the main loop under sterile circumstances (in the border without sprites and no other possible delay factors), using the half-variance method.
Then you set up a _VIC_ raster interrupt which should have the same timing on every machine. In the irq handler, you can read out the CIA timer register and delay accordingly to get to always the same cycle and have a stable timing. The value the CIA gives is the same on every machine.
Et voilà, stable raster position on every machine. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@krill:
i had a pure timer based 4x4 routine in oneder and there were visible bugs on some machines due to irqs being 1 cycle too late. since the discussion is about "stable raster via timer" it is a problem. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Yup! As I mentioned above, this has happened to me too! |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
that's why the method i described is the best one with timers, no cia detection needed, working same on every machine. |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
This topic seems to get outta control... at the very beginning I only had the version with _one_ timer in my mind (like Krill) !
Up to now I haven't used the double_timer method. The _only_ advantage is that you can save some cycles on IRQ_entry - or is there even more? If we are at it at the moment:
i) what is the shortest possible way to sync the "1st" timer...
ii) ...and how do we test the CIA-Versions reliably?
...there _are_ solutions to this prob, aren't there?
One last question in my head: why do people always use two timers? Ok, it says "double timer method", but it should be possible to sync one timer (usually called the "1st" in the double_timer method), and use exactly the same one as "2nd" timer to kill the variance cycles - or do I miss something?
Later
/Copyfault |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Well, I pulled apart my 128, and lo and behold there are a pair of non-A 6526's staring up at me. :-P So, can I get a few testers for yet another version of http://www.white-flame.com/timingtest.prg ? This one *should* detect between a 6526 and 6526A. I'll yank apart some non-working C64s from home and see if I can get some 6526A's.
(I also was curious as to whether or not sprite DMA still happened when you turned the screen off... it does)
Here's the relevant code:
;---------
; 6526 vs 6526A
;
; Set off a single-shot NMI to interrupt
; immediately before an INC statement. The
; older 6526 triggers one cycle later, so it
; will run the INC while the newer one won't.
testCIAVersion:
; Set NMI vector
lda #<continue
sta $fffa
lda #>continue
sta $fffb
; Set timer to 5 cycles
lda #4
sta $dd04
lda #0
sta $dd05
; Clear the detection flag
sta oldCIA
; Fire a 1-shot timer
lda #%10011001
sta $dd0e
; This should be interrupted before the INC
; only if it's a newer chip.
lda $dd0d
lda $dd0d
inc oldCIA
jmp * ; just in case
continue:
lda $dd0d
pla
pla
pla
rts
oldCIA:
.res 1
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
So glad I found this topic! :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
