Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user hllerena78 ! (Registered 2019-08-20) 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: 1241
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: 434
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: 434
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: 1241
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: 434
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: 1241
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
Dymo/G★P
youtH/Heatwave
Francesco Sblendorio
Pantaloon/Fairlight
Snabel
Thunder.Bird/HF/MYD!..
ThunderBlade/BLiSS
Didi/Laxity
xIII/ATL/WOW
Viza/Hokuto Force
Guests online: 35
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.5)
9 C=Bit 18  (9.5)
10 Old Men in Used Cars  (9.5)
Top onefile Demos
1 Smile to the Sky  (9.5)
2 Dawnfall V1.1  (9.5)
3 Crystal Gazer  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Rewind  (9.5)
6 Instinct  (9.5)
7 Pandemoniac Part 5 o..  (9.5)
8 Innervasion  (9.4)
9 Bad Boy  (9.4)
10 Ghost in the Sydney  (9.4)
Top Groups
1 Fossil  (9.8)
2 PriorArt  (9.7)
3 Performers  (9.6)
4 Oxyron  (9.4)
5 Censor Design  (9.4)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.9)
3 Irata  (9.8)
4 hedning  (9.8)
5 Taper  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.052 sec.