| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
PAL/NTSC detect
Just wanted to share a quick routine that detects PAL/NTSC WITHOUT using interrupts or latches.
;pal/NTSC detect - 0 = PAL, non-zero = NTSC
palntsc
sei ; disable interrupts
wait
lda $d012
bne wait ; wait for rasterline 0 or 256
wait1
lda $d011 ; Is rasterbeam in the area
bpl wait1 ; 0-255? if yes, wait
wait2
ldy #$00
synch1 lda $d012
cmp #$37 ; top PAL rasterline
bne synch1
lda $d012 ; if next is 0, then PAL
synch2 cmp $d012
beq synch2
lda $d012
cli ; enable interrupts
rts ; return
|
|
... 67 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Sorry, brainfart, scratch the "of course". But i'm still not so sure about PAL SX-64, as$7f4a for 60Hz TOD clock and 985248.444 CPU/CIA clock
$70a6 for 60Hz TOD clock and 1022727.14 CPU/CIA clock the two values are pretty close. What are the cycle count ranges assuming a mains frequency tolerance of 4 Hz, i.e., with 56-64 Hz? Too lazy to do the maths now. :) |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Okay, 4 Hz is way too much. Usual deviations in Europe are 0.2 Hz, i guess it's similar in NTSC land. I haven't found any number yet regarding the March 2018 low point in Europe due to some conflict in the Balkans, though. :) |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Quoting Silver Dream !I currently don't account for Drean so that's something to verify. Maybe, you should also account for no AC at all. AFAIK, that's a thing with broken or otherwise weird PSUs. TOD is frozen but C-64 runs normally otherwise. Your current implementation would block and never return. |
| |
soci
Registered: Sep 2003
Posts: 474 |
That routine is not safe, as Krill mentioned.
I've already encountered such "lockups" with some productions which prompted for the 555 installations in my C64/C128s. But at least I bothered to measure and set them close to 50 Hz ;)
So to set up the TOD 50/60 Hz prescaler I'd do the following instead:
tod_calibrate php
sei
lda $dc0e
ora #$80 ; set 50 Hz
sta $dc0e
lda $dc08 ; start TOD
sta $dc08
jsr measure
jsr measure
cpy #211 ; decision value
bcs pal
lda $dc0e
eor #$80 ; change to 60Hz
sta $dc0e
pal plp
rts
.page ; must not cross page
measure ldy #0
lda $dc08
lp2 ldx #37
lp cmp $dc08
bne done
dex
bne lp
iny
bne lp2
done rts
.endp
This works both in case the screen is off without sprites (best case) and with screen on 8 y expanded sprites (worst case).
Video system detection is out of scope, there's too much noise.
This works by measuring cycle counts between TOD ticks. The calibration exits even if no ticks are present.
Best case estimated cycle numbers:
82104 cycle - PAL/60
85227 cycle - NTSC/60
85286 cycle - DREAN/60
98524 cycle - PAL/50
102273 cycle - NTSC/50
102344 cycle - DREAN/50
Worst case estimated cycle numbers (effective):
74280 PAL/60
75707 NTSC2/60
75889 NTSC/60
77409 DREAN/60
89136 PAL/50
90849 NTSC2/50
91067 NTSC/50
92891 DREAN/50
The decision point was chosen to be 87211 (between DREAN/60 and PAL/50), which is 211 after division.
It is assumed that the TOD frequency is within 1 Hz of 50/60 Hz for this to work.
The frequency margin can be widened if it's ensured that the measurement is always done in the best case scenario (screen and sprites off). Then 222 can be used as a decision point which allows for a 3 Hz frequency deviation. |
| |
Oswald
Registered: Apr 2002
Posts: 5020 |
thats interesting so you can basicly measure the AC freq with the help of the TOD clock ? |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Yes, you determine TOD update rate using the system's crystal clock frequency as reference. |
| |
soci
Registered: Sep 2003
Posts: 474 |
It's better to use the horizontal retrace frequency as reference clock as it's more consistent than cycle counts.
This has the advantage that it works on SuperCPU and that it can handle a 3 Hz frequency deviation even with screen on.
tod_calibrate php
sei
lda $dc0e
ora #$80 ; set 50 Hz
sta $dc0e
lda $dc08 ; start TOD
sta $dc08
jsr measure
jsr measure
cpy #204 ; decision value
bcs pal
lda $dc0e
eor #$80 ; change to 60Hz
sta $dc0e
pal plp
rts
measure ldy #0
lda $dc08
lp2 pha
lda #64
lp cpx $d012
beq lp
ldx $d012
lsr a
bne lp
pla
cmp $dc08
bne done
iny
bne lp2
done rts
|
| |
soci
Registered: Sep 2003
Posts: 474 |
Shortened version:
http://codebase64.org/doku.php?id=base:tod_calibration
The other 2 solutions on codebase hang on DC only, but whatever.
Btw. this is one of the releases which fails to start without TOD ticks:
VSP Lab V1.1 |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Quoting KrillYes, you determine TOD update rate using the system's crystal clock frequency as reference. Quoting sociIt's better to use the horizontal retrace frequency as reference clock as it's more consistent than cycle counts.
This has the advantage that it works on SuperCPU [...] Pretty sure the CIA timers run at ~1 MHz regardless of any accelerator cartridge. I wasn't suggesting to count CPU cycles. =)
Edit: Groepaz told me of this TDC-L (D1) 2/4Mhz C64 Accelerator which does indeed change CIA clocking, and not consistently depending on mode. (And a system with unreliable timers is not what i'd like to code for or consider for compatibility.) |
| |
soci
Registered: Sep 2003
Posts: 474 |
Quoting KrillQuoting KrillYes, you determine TOD update rate using the system's crystal clock frequency as reference. Quoting sociIt's better to use the horizontal retrace frequency as reference clock as it's more consistent than cycle counts.
This has the advantage that it works on SuperCPU [...] Pretty sure the CIA timers run at ~1 MHz regardless of any accelerator cartridge. I wasn't suggesting to count CPU cycles. =)
That's a reference to Devia's CPU cycle counting version.
My first attempt had the same problem as well and that was meant in the first sentence.
CIA timers are ok but if they are not changed then that's one potentially unwanted side effect is eliminated. Such a calibration routine should preferably only change the TOD pre-scaler and nothing else. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
