| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
C64 Clock/Time routine
Houston we have a problem!
About all clocks i have seen on C64, run too slow.
More specificly i am annoyed with SDI music tracker, and PSID64 clocks.
They run too slow!
If they play music for 4 minutes, they will claim they only played like 3:41 or so.
So my question is:
Are the coders on the wrong path, or is the C64 ? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
easy: rambones' clock runs too fast :=) |
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
I didn't code the clock routine in SDI, but as I'm concerned when using the correct routine, it should work. Try out some old Moz(Ic)art or MON screens, see if those clock works ? They should use a timer and decimal additions. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Okay i ran astro marine core by MON, the clock is correct over 4 mins.
So SDI and PSID64 both are bugged...
About SDI, i have a suspicion that it simply runs the clock at NTSC speed... lets hammer Glenn on the head for that :) |
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
Let's write that down on the list with the other new hot fixes... :-) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
it afffected me in real life, because on the MO and X2006 party, they played my tune too short, because the on screen time was wrong!
i dont use SDI default player, but i had blindly written on screen that time was xx:xx, but in reality it was 20 secs longer, so they didnt hear my ending.. (i dont loop on compo) |
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
Quote: it afffected me in real life, because on the MO and X2006 party, they played my tune too short, because the on screen time was wrong!
i dont use SDI default player, but i had blindly written on screen that time was xx:xx, but in reality it was 20 secs longer, so they didnt hear my ending.. (i dont loop on compo)
Rambones. This is not real life. This is just a fantasy, a jolly playground for nostalgic freaks. :-) |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
The issue is most likely because the timers assume PAL frame rate is exactly 50 Hz. It makes it easier to calculate fast forwards etc. When using CIA TOD it gets a bit messier. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Quote: The issue is most likely because the timers assume PAL frame rate is exactly 50 Hz. It makes it easier to calculate fast forwards etc. When using CIA TOD it gets a bit messier.
Wouldn't that mean less than one second error in the aforementioned four minutes? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Feel very free to post a clock routine on http://codebase64.org
The world needs you! |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Wouldn't that mean less than one second error in the aforementioned four minutes?
During X we've seen a lot of players showing the time wrong, and most of them by about the same amount.. way more than just 1 second..
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Well, Charles Deenen coded it correct...
so rip his! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
there is no need to rip a clock routine really, just code it right =D |
| |
6R6
Registered: Feb 2002
Posts: 245 |
The current SDI 2.0beta use the Time-Of-Day clock
to display the time. And the current settings for $dc0e look like this:
(50hz for pal)
lda #$81
sta $dc0e
(60hz for ntsc)
lda #$01
sta $dc0e
I'm not doing a proper system check, i'm only checking the value of $02a6 to determine wheter the machine is pal or ntsc. This will be fixed for the next release. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
No need to post a clock routine. PRG explains it well enough. What matters is the read and write orders. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Quote: The current SDI 2.0beta use the Time-Of-Day clock
to display the time. And the current settings for $dc0e look like this:
(50hz for pal)
lda #$81
sta $dc0e
(60hz for ntsc)
lda #$01
sta $dc0e
I'm not doing a proper system check, i'm only checking the value of $02a6 to determine wheter the machine is pal or ntsc. This will be fixed for the next release.
But you're not setting $dc0e in the player-demo code thingie, so if people use that, they'll get wrong time as default value is #$01
|
| |
yago
Registered: May 2002
Posts: 333 |
GRG: I also used TOD once, and believe me, there _are_ c64s (well, its more the power-structure itself in certain areas) which totally run TOD wrong.
Better rely on timer or frames.
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Yes... TOD is unreliable. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
TOD is more than good enough to measure 4 minutes accuratly |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I usually do a phase accumulator approach like this:
seg code
org $1000
start:
sei
; setup zeroes
ldx #4
lp1:
lda #"0"
sta $0400,x
lda 646
sta $d800,x
dex
bpl lp1
; wait for frame
lp2:
jsr clock
lp3:
lda $d011
bpl lp3
lp4:
lda $d011
bmi lp4
bpl lp2
; ( 2^24 / CPU_FREQ ) * CYCLES_PER_FRAME
; PAL: ( 2^24 / 985248 ) * 19656 = ~334711
; NTSC: ( 2^24 / 1022727 ) * 17095 = ~280433
FRAME_ADD equ 334711
frame_add:
dc.b FRAME_ADD >> 16
dc.b [FRAME_ADD >> 8] & $ff
dc.b FRAME_ADD & $ff
doffs:
dc.b 0,1,3,4
limit:
dc.b $30+10,$30+10,$30+6,$30+10
time_acc:
dc.b 0,0,0
clock:
; phase accumulator
clc
ldx #2
clk_lp1:
lda time_acc,x
adc frame_add,x
sta time_acc,x
dex
bpl clk_lp1
bcc clk_skp1 ; didn't wrap, skip increment
; increment time
ldy #4-1
clk_lp2:
ldx doffs,y
inc $0400,x
lda $0400,x
cmp limit,y
bne clk_skp1
lda #$30
sta $0400,x
dey
bpl clk_lp2
clk_skp1:
; flash ":" according to MSB in time_acc
lda #":"
bit time_acc
bpl clk_skp2
lda #" "
clk_skp2:
sta $0402
rts |
| |
6R6
Registered: Feb 2002
Posts: 245 |
Quote: But you're not setting $dc0e in the player-demo code thingie, so if people use that, they'll get wrong time as default value is #$01
Aha... Will fix that aswell. |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Quoting GRGThis will be fixed for the next release.
Did i hear "next release" ? <3<3<3
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
oh noes.. I just remembered that the SX-64 has 60Hz TOD ONLY!
This means that even if you detect a PAL SX-64 correctly as PAL, you still end up gaining roughtly 10 seconds every minute if you set $DC0E bit 7 to 1 (50Hz)
So how does one properly detect an SX-64 if its KERNAL got replaced?
Seems to me like you have to "measure" the time of the TOD to be sure if its 50 or 60Hz clocked :(
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: oh noes.. I just remembered that the SX-64 has 60Hz TOD ONLY!
This means that even if you detect a PAL SX-64 correctly as PAL, you still end up gaining roughtly 10 seconds every minute if you set $DC0E bit 7 to 1 (50Hz)
So how does one properly detect an SX-64 if its KERNAL got replaced?
Seems to me like you have to "measure" the time of the TOD to be sure if its 50 or 60Hz clocked :(
To detect PAL or NTSC couldn't one simply just poll $d011&$d012. PAL machines will be able to reach higher values than NTSC.
From the top of my head completely untested:
sei
bit $d011
bmi *-3
bit $d011
bpl *-3
; we're now on line 256.
; Check if we ever reach line 311 before VBL
ldx #0
lda #<311
:
cmp $d012
bne :+
inx
jmp :++
:
bit $d011
bmi :--
:
cli
txa
beq :+
; PAL
jmp :++
:
; NTSC
:
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: oh noes.. I just remembered that the SX-64 has 60Hz TOD ONLY!
This means that even if you detect a PAL SX-64 correctly as PAL, you still end up gaining roughtly 10 seconds every minute if you set $DC0E bit 7 to 1 (50Hz)
So how does one properly detect an SX-64 if its KERNAL got replaced?
Seems to me like you have to "measure" the time of the TOD to be sure if its 50 or 60Hz clocked :(
Not that my detection routine solves that issue... :) |
| |
Devia
Registered: Oct 2004
Posts: 401 |
heh.. appreciate your efforts, but no, that doesn't really solve the problem ;-)
|
| |
yago
Registered: May 2002
Posts: 333 |
Quote: TOD is more than good enough to measure 4 minutes accuratly
Unfortunately, no.
While playing around with TOD, i sent my testprg around the world, and in some places,where power-frequency ought to be 50Hz, it was 60Hz.
(On many places, the difference was smaller, but on many the clock will go wrong after 4 minutes)
With other Words: Its 2009, Power Companies deliver worse Quality then ever.
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
Hmm.. yeah.. so unless you have a xtal generating the TOD clk, like in the SX-64, you're at the mercy of your local power company in regards to TOD precision.
So the conlusion must be that TOD is reliable only under controlled circumstances and is definately not to be relied on in all cases.
That sux.
|
| |
yago
Registered: May 2002
Posts: 333 |
Dont be so negative!
TOD can be used to measure quality of power!
;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:and in some places,where power-frequency ought to be 50Hz, it was 60Hz.
seriously, if that is the case you have a much bigger problem than a clock that doesnt work right :)
you can be pretty sure that there is no problem all over europe, and all over the usa (both unified power nets, which makes it kinda impossible that frequencies are not what you expect).
also i kinda doubt it, a broken pal/ntsc detection is much more likely :) what country would that be that has "wrong" power frequency? (and after reading devias post: were sx-64s involved?).
seriously, the power frequency beeing wrong is... something you might experience in a handful 3rd world countries that dont have unified power nets. anywhere else.... no. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
ha HA!
I found a solution..
To properly initialize the TOD on any platform(*) do this:
1. Detect PAL/NTSC
2. If PAL, set 60Hz, else set 50Hz TOD
3. Wait for more than 5 and less than 6 frames
4. If $DC08 == 1, set 60Hz, else set 50Hz TOD
This method should work on PAL and NTSC with both 50Hz and 60Hz clocked TODs.
(*) - Well.. any platform but Vice apparently. Vice seems to ignore bit 7 of $DC0E, so it will always be correct ;)
I don't have any NTSC machines, so if there's someone out there with an NTSC c64 who wants to test this, please PM me. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
uh oh.. In regards to Step 3 above, you'd of course have to first synchronize the raster to the Power Plant's net frequency or you'd have a slack factor of up to almost 1 frame +/-... this is of course also easily achieved by doing a simple lda $dc08, cmp #nextval, bne *-5 or similar..
yes.. a code example of all this will be published at codebase64.or once it's done and verified.. but I need an NTSC tester!!!
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quote: uh oh.. In regards to Step 3 above, you'd of course have to first synchronize the raster to the Power Plant's net frequency or you'd have a slack factor of up to almost 1 frame +/-... this is of course also easily achieved by doing a simple lda $dc08, cmp #nextval, bne *-5 or similar..
yes.. a code example of all this will be published at codebase64.or once it's done and verified.. but I need an NTSC tester!!!
@Devia: Good boy! ;) |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Ok, I found another solution which was way easier to implement and added some info on it here: http://codebase64.org/doku.php?id=base:initialize_tod_clock_on_..
You'll also find a link to a binary there, which you can test your REAL c64s with. I still would like just a single report on the behaviour on NTSC machines.
|
