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 Productions > PAL/NTSC detect
2003-01-29 18:35
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....
 
2019-05-18 13:30
Krill

Registered: Apr 2002
Posts: 1410
Yes, you determine TOD update rate using the system's crystal clock frequency as reference.
2019-05-18 22:18
soci

Registered: Sep 2003
Posts: 442
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
2019-05-19 08:13
soci

Registered: Sep 2003
Posts: 442
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
2019-05-19 20:44
Krill

Registered: Apr 2002
Posts: 1410
Quoting Krill
Yes, you determine TOD update rate using the system's crystal clock frequency as reference.
Quoting soci
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 [...]
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.)
2019-05-19 22:11
soci

Registered: Sep 2003
Posts: 442
Quoting Krill
Quoting Krill
Yes, you determine TOD update rate using the system's crystal clock frequency as reference.
Quoting soci
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 [...]
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.
2019-05-20 10:12
Silver Dream !

Registered: Nov 2005
Posts: 21
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.
2019-05-20 10:14
Silver Dream !

Registered: Nov 2005
Posts: 21
Quoting Krill
[..](And a system with unreliable timers is not what i'd like to code for or consider for compatibility.)

Precisely that.
2019-05-20 10:32
Silver Dream !

Registered: Nov 2005
Posts: 21
Quoting Krill
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.
In a C64 CIA is clocked off PHI2. Since Kisiel clocks CPU at variable rate there, that will affect.
2019-05-20 11:00
Krill

Registered: Apr 2002
Posts: 1410
Quoting Silver Dream !
Quoting Krill
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.
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. :)
2019-05-20 11:34
Silver Dream !

Registered: Nov 2005
Posts: 21
Quoting Krill
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. :)

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
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
Advanced
Users Online
Naufr4g0
Didi/Laxity
Twoflower/ΤRIΛD
hedning/G★P
Fred/Channel 4
ZeSmasher/F4CG
Perff/No Name
Guests online: 43
Top Demos
1 Uncensored  (9.7)
2 Coma Light 13  (9.7)
3 Edge of Disgrace  (9.7)
4 Comaland 100%  (9.6)
5 Unboxed  (9.6)
6 The Shores of Reflec..  (9.6)
7 Remains  (9.5)
8 Lunatico  (9.5)
9 C=Bit 18  (9.5)
10 Rivalry  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.6)
2 Crystal Gazer  (9.6)
3 Space Demo  (9.5)
4 Field Sort  (9.5)
5 Instinct  (9.5)
6 The Tuneful Eight [u..  (9.5)
7 Smile to the Sky  (9.5)
8 Rewind  (9.5)
9 Onef1ler  (9.5)
10 Bad Boy  (9.5)
Top Groups
1 Performers  (9.6)
2 Oxyron  (9.4)
3 PriorArt  (9.4)
4 Booze Design  (9.4)
5 Censor Design  (9.4)
Top Mega Swappers
1 Aslive  (9.4)
2 Calypso  (9.3)
3 Dishy  (9.2)
4 Nightshade  (9.2)
5 R.C.S.  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.041 sec.