| |
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: 2969 |
Yes, you determine TOD update rate using the system's crystal clock frequency as reference. |
| |
soci
Registered: Sep 2003
Posts: 479 |
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: 479 |
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: 2969 |
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: 479 |
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. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Gents - the main point is that unless I write h/w diagnostic software, I basically initialise TOD because I need it for the PRG to serve its purpose. Otherwise I wouldn't waste bits for checking the frequency, would I? Of course if I have a very good day and mem to spare I might do a more graceful exit and maybe even tell the user "Hey - your TOD is broken. I quit." In generic case though I hardly see a point in accounting for broken hardware. TOD that does not count what it should is of no use, even if everything else works correctly. Drean is a different thing because it has a different characteristics even if working 100%. As much as I understand it (never had one in hands) it doesn't change much in terms of TOD initialisation, which should still work as expected also on Drean. It does change in terms of the video norm though, because if the CIA clock is the same as on NTSC machines then it will recognise it as NTSC. This might be worth researching and eventually accounting for (if possible) but only if we talk about the side-effect of recognising video norm next to TOD ticks freq. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting Krill[..](And a system with unreliable timers is not what i'd like to code for or consider for compatibility.)
Precisely that. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting KrillEdit: Groepaz told me of this TDC-L (D1) 2/4Mhz C64 Accelerator which does indeed change CIA clocking, and not consistently depending on mode. In a C64 CIA is clocked off PHI2. Since Kisiel clocks CPU at variable rate there, that will affect. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting Silver Dream !Quoting KrillEdit: Groepaz told me of this TDC-L (D1) 2/4Mhz C64 Accelerator which does indeed change CIA clocking, and not consistently depending on mode. In a C64 CIA is clocked off PHI2. Since Kisiel clocks CPU at variable rate there, that will affect. I know. I just wasn't aware that there are accelerators which do not come with an own external faster CPU but do the ballsy thing of speeding up operation of parts of the C-64 itself, including overclocking the CPU. Thought there were a few good reasons why Commodore didn't do this in the first place. :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting KrillI just wasn't aware that there are accelerators which do not come with an own external faster CPU but do the ballsy thing of speeding up operation of parts of the C-64 itself, including overclocking the CPU. Thought there were a few good reasons why Commodore didn't do this in the first place. :)
I recall there was a quasi-2MHz accelerator for the 64 once published in 64'er but AFAIR it used properly rated CPU for that. I don't recall ever seeing ICs rated higher than 2MHz in a 64. Most are 1MHz rated in fact. It doesn't mean they won't run but it means that if they do, they run (partially way) out of specs. IOW, while I truly appreciate Kisiel's ideas, I wouldn't bet on full reliability of this approach in *every* machine. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
