| |
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
|
|
| |
Perff
Administrator
Posts: 1679 |
I know it's not in the 'hardcore' coding-spirit, but isn't it easier just to ask the system?
One thing you could do is check the IRQ-timer which is different for PAL & NTSC even though I can't remember the values.
This ofcourse only work is you come straight from basic, and/or nothing has tampered with the IRQ-timing.
Another thing is to check the PAL/NTSC variable.
The address $02A6 is 0 for NTSC and 1 for PAL set by the ROM but this again could be overwritten by something.
But the ROM can't. In the ROM somwhere I think it says something like:
lda #$01
sta $02A6
for PAL and lda #$00 for NTSC. Why not just check that? (yes. It might not be at the same location in each ROM-version)
I'm not 100% sure of this information though. Just something I think I remember. Please correct me if I'm wrong. :)
/Perff |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Perff: There is no PAL or NTSC-specific ROM. So any ROM checks for PAL/NTSC (counting rasterlines, see $FF5E...) and sets $02A6 depending on the result. And while we are just at it: Checking $02A6 is a poor way of detecting IMHO, because this location can easily be messed up. Those few bytes for a true PAL/NTSC-detection do not hurt, I think.
Dr Jay: What about this?
...
bne synch1
lda $d011
cli
rts
Bit 7 is set when PAL and cleared when NTSC. And I guess the LDY #$00 can be removed, too. |
| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
LOL. I saw the LDY after I posted it ... artifact from an earlier attempt. Yes, I like the LDA $D011 ... much more elegant. And as for the ROM issue ... everything I've come to understand says that checking the $02a6 etc is unreliable as different versions, mods, carts, etc. may change this ... but I'm stuck in NTSC-land with a 64C so I haven't had the opportunity to try this on many other stock machines.
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
I think the main problem with $02A6 is, that it is set after a reset only. So, load some scene-production which doesn't care about KERNAL-variables and maybe exits with a plain RTS, and $02A6 is as reliable as your house-number :)
Also, the KERNAL-method does not work with accelerators.
False detections because of $02A6 are really annoying; especially as PAL/NTSC-checks are public and easy to implement.
So much for the preaching... ;) |
| |
Perff
Administrator
Posts: 1679 |
ninjadrm: Ok sorry for my "lame" idea. I just thought I remembered that somewhere in the ROM it said lda #$X sta $02A6 and thought of that as a 100% way to determin PAL/NTSC
Well.. I was wrong. You're right. Sorry. :) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Perff: No need to be sorry or to excuse for a "lame" idea; it was just meant to be constructive criticism :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
do NOT use the pal/ntsc flag since it is unreliable, even without any kind of extensions. the best way is really to check if certain rasterlines exist or not.
|
| |
AlexC
Registered: Jan 2008
Posts: 298 |
Quote: do NOT use the pal/ntsc flag since it is unreliable, even without any kind of extensions. the best way is really to check if certain rasterlines exist or not.
Does it mean that original ROM can set this flag wrongly? Haven't studied this part of ROM but I remember that the detection routine used is quite short. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
yes, the rom routine has a flaw that sometimes makes it report ntsc when the machine is infact pal. (atleast thats how i remember it =D) |
| |
AlexC
Registered: Jan 2008
Posts: 298 |
Quote: yes, the rom routine has a flaw that sometimes makes it report ntsc when the machine is infact pal. (atleast thats how i remember it =D)
Thanks for clearing it up for me. I need to get NTSC machine to experiment a bit. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
So the shortest/fastes routine for reliable detection would be something like:
PALNTSC
sei
lda $01
pha
lda #<INT_NMI
sta $fffa
lda #>INT_NMI
sta $fffb
lda #$35
sta $01
;---important stuff start
: bit $d011
bpl :-
: lda $d012
cmp #<263
bcs :+ ;Result >= 0 then PAL
bit $d011
bmi :-
clc ;NTSC
:
;---important stuff end
pla
sta $01
rts
INT_NMI
rti
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
I came to basically the same conclusion:
http://codebase64.org/doku.php?id=bae:dtv_detect (scroll down) |
| |
Devia
Registered: Oct 2004
Posts: 401 |
ahh... The first lda $d011, bmi *-3 seems obsolete, though - unless I'm missing something?
Is there any particular reason for waiting for line 288?
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quote: ahh... The first lda $d011, bmi *-3 seems obsolete, though - unless I'm missing something?
Is there any particular reason for waiting for line 288?
|
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
Just wanted to say that TLR missed one letter in his link to codebase... the link is:
http://codebase64.org/doku.php?id=base:dtv_detect
Also, don't hesitate to update the current NTSC/PAL detection routine if you come up something better:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: ahh... The first lda $d011, bmi *-3 seems obsolete, though - unless I'm missing something?
Is there any particular reason for waiting for line 288?
So what happens if your version starts within 6 cycles of the raster counter wrapping to 0? ;)
288 is just about halfway between the max number of raster lines on PAL and NTSC respectively.
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
Quote: So what happens if your version starts within 6 cycles of the raster counter wrapping to 0? ;)
288 is just about halfway between the max number of raster lines on PAL and NTSC respectively.
Well in that case it's apparently an NTSC machine ;-)
So, yes..
: bit $d011
bmi :-
: bit $d011
bpl :-
: lda $d012
cmp #<263
bcs :+ ;Result >= 0 then PAL
bit $d011
bmi :-
clc ;NTSC
:
Any more pitfalls then?
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
WTF happened to my post above? Well, tlr pointed out the need for extra check.
Can anyone find something wrong with this approach:
.w ldx $d012
cpx $d012
beq *-3
lda $d012
bne .w
inx
beq .w
cpx #20
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: WTF happened to my post above? Well, tlr pointed out the need for extra check.
Can anyone find something wrong with this approach:
.w ldx $d012
cpx $d012
beq *-3
lda $d012
bne .w
inx
beq .w
cpx #20
Nice approach using just $d012 to avoid the race condition!
I think that will work. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
l1 lda $d012
l2 cmp $d012
beq l2
bmi l1
cmp #$20
bcc ntsc
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote:
l1 lda $d012
l2 cmp $d012
beq l2
bmi l1
cmp #$20
bcc ntsc
12 bytes. Very impressive!
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
Quote:
l1 lda $d012
l2 cmp $d012
beq l2
bmi l1
cmp #$20
bcc ntsc
That's brilliant.
|
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
I put it on codebase:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc
I also wonder... does Ninja's older routine have any benefits over and above this short 12 byte routine? (Didn't have any time/energy to look into it myself now, sorry.) If not, I guess it could just as well be removed.
//FTC |
| |
Devia
Registered: Oct 2004
Posts: 401 |
You still need to catch NMI and disable IRQ for it to be completely reliable - and the 12 bytes is without the bcc in the end, which may be obsolete depending on how you implement it.
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Frantic:
Technically, my routine does not have an advantage. From an educational point of view, it has (it was supplement code to an article after all) :) If you don't know the topic, then it surely helps to read my routine first, before you use the other (probably with disabling interrupts there, too). |
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
Okok... Thanks for the information. In fact, I added the whole article to the page, since I guess it might add something of value to someone out there. (Just tell me if you mind...) |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Actually this helps me BIGTIME. Because I always thought that the PAL/NTSC register was the way to go.
Thanks guys for the information, helps me with NTSc/PAL intros ;-)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
Quote:PAL/NTSC register
hu? there is no such thing :) the kernal uses a similar (but buggy) routine to detect pal/ntsc =) |
| |
Mix256
Account closed
Registered: Dec 2008
Posts: 26 |
But...but, there're two ntsc.
Any smart solution to this as well?
Or do I just wait for line 262, if the next is 263 strike old_ntsc. If the one after that one is 264, we got pal otherwise it's new_ntsc.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
dont bother about the 64 cycle vic. they are very rare, and nothing works right on them anyway. noone gives a damn really =) |
| |
Mix256
Account closed
Registered: Dec 2008
Posts: 26 |
Great! Thanks a lot! |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Warning! This message contains just for fun material. Don't take my comments too seriously.
I always thought 64 cycles per line is the most suitable number of cycles for c64. It's a pity that only very rare NTSC machines used it in the past.
1) 64 cycles covers all 512 pixels. Some of them are not visible pixels maybe but no 8 pixels gap is the best alternative for me. Actually more than 64 cycles is ok too.
2) Second reason is simple. It's a Commodore "64" god dammit! Why would it have 63 or 65 cycles per line? :D
In PAL mode, I could live with loosing 5 raster lines or so. Just a thought...
Let's get back to the topic. A funny (just for fun) alternative way of detecting PAL/NTSC would be to show two different stabilized rasterbar blocks using 63 and 65 cycles per line. User could select the correct looking block before the demo starts ;) Showing raster splits would be even nicer.
Yeah yeah, complete comment is pointless I know :) |
| |
enthusi
Registered: May 2004
Posts: 677 |
Quote: Warning! This message contains just for fun material. Don't take my comments too seriously.
I always thought 64 cycles per line is the most suitable number of cycles for c64. It's a pity that only very rare NTSC machines used it in the past.
1) 64 cycles covers all 512 pixels. Some of them are not visible pixels maybe but no 8 pixels gap is the best alternative for me. Actually more than 64 cycles is ok too.
2) Second reason is simple. It's a Commodore "64" god dammit! Why would it have 63 or 65 cycles per line? :D
In PAL mode, I could live with loosing 5 raster lines or so. Just a thought...
Let's get back to the topic. A funny (just for fun) alternative way of detecting PAL/NTSC would be to show two different stabilized rasterbar blocks using 63 and 65 cycles per line. User could select the correct looking block before the demo starts ;) Showing raster splits would be even nicer.
Yeah yeah, complete comment is pointless I know :)
hehe, nice "detection".
What about input"PAL? (YES/NO)";TV$
|
| |
Mix256
Account closed
Registered: Dec 2008
Posts: 26 |
Maybe a small game that is too hard on ntsc machines due to speed. So if the player completes the game it's a PAL one and if he dies it's a ntsc one. |
| |
enthusi
Registered: May 2004
Posts: 677 |
or you could use drive composer to align the sound of the drive to a single speed tune.
If it matches its 60Hz, otherwise 50 :) |
| |
Spinball
Registered: Sep 2002
Posts: 88 |
Quote: hehe, nice "detection".
What about input"PAL? (YES/NO)";TV$
just like this crack? Grand Prix Circuit +F |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
Using this method, there should be a way to distinguish NTSC from Old NTSC-M. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
A quick way to determine the number of cycles per line is to start a timer at raster line 0 then wait until raster line 256 and check the MSB of the timer.
Correctly done (just some inversion) you'll now have the number of cycles directly.
I do this here: http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/testprogs/V..
modesplit.asm, line 194, function check_time. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The easiest way to determine cycles/rasterline is to count the rasterlines:
312 rasterlines -> 63 cycles per line
263 rasterlines -> 65 cycles per line
262 rasterlines -> 64 cycles per line
Counting the lines:
w0 LDA $D012
w1 CMP $D012
BEQ w1
BCC w0
Result in Akku (low byte of rasterlinecount-1):
#$37 -> 312 rasterlines
#$06 -> 263 rasterlines
#$05 -> 262 rasterlines
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
It should be pointed out that my routine is designed for the purpose of hardware analysis and emulator evaluation.
I therefor require the number of cycles per line to be measured directly, not relying on the number of raster lines.
That routine should work with any timing encountered as long as there are more than 256 raster lines on the system.
There are no known hardware with timings different from those listed by Graham so normally you can use his method.
It will for almost all intents and purposes be equally accurate and shorter.
EDIT: nojoopa points out that the Drean PAL-N machine has 65 cycles per line and 312 raster lines so my statement about the known machines was wrong. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
BCC should have been BMI
|
| |
Frantic
Registered: Mar 2003
Posts: 1647 |
I added TLR's and Graham's routines to codebase (the PAL/NTSC detect page) (and changed bcc to bmi).
//FTC |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Slight improvement would be:
w0 LDA $D012
w1 CMP $D012
BEQ w1
BMI w0
AND #$03
#$03 -> 312 rasterlines
#$02 -> 263 rasterlines
#$01 -> 262 rasterlines
|
| |
Moloch
Registered: Jan 2002
Posts: 2925 |
Ancient thread brought back to life, but certainly some excellent examples recently posted. Will work nicely for my NTSC/PAL detection needs, thanks!
|
| |
Sokrates
Registered: Jun 2014
Posts: 7 |
Enhanced version to differ between PAL and PAL-N. First count rasterlines, then count cycles.
LDX #$00
w0 LDA $D012
w1 CMP $D012
BEQ w1
BMI w0
AND #$03
CMP #$03
BNE detectionDone ; done for NTSC
TAY
countCycles
INX
LDA $D012
BPL countCycles
CPX #$5E ; VICE values: PAL-N=$6C PAL=$50
; so choose middle value $5E for check
BCC isPAL
INY ; is PAL-N
isPAL
TYA
detectionDone
...
Results in the accumulator:
#$01: 262 rasterlines and 64 cycles per line [NTSC: 6567R56A VIC] (OLD NTSC)
#$02: 263 rasterlines and 65 cycles per line [NTSC: 6567R8 VIC]
#$03: 312 rasterlines and 63 cycles per line [PAL: 6569 VIC]
#$04: 312 rasterlines and 65 cycles per line [Drean PAL-N: 6572 VIC] |
| |
Count Zero
Registered: Jan 2003
Posts: 1927 |
Saw your edit on codebase - thanks for that!
Wonder whenever some special fix becomes drean-only or such. Those few more cycles likely only add advantage on calculations for some games, hm? |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Another version:
.pseudocommand VSync {
bit $d011
bpl *-3
bit $d011
bmi *-3
}
lda #$ff
sta $dc04
sta $dc05 // Latch #$ffff to Timer A
:VSync
ldx #%00011001
stx $dc0e // Start Timer A (One shot mode (Timer stops automatically when underflow))
:VSync
sec
sbc $dc05 // Hibyte number of counter
and #%00000011
A now contains the video system as follows:
#0 - NTSC1
#1 - DREAN
#2 - PAL
#3 - NTSC2
Edit: Rectified bug. |
| |
Sokrates
Registered: Jun 2014
Posts: 7 |
Quote: Saw your edit on codebase - thanks for that!
Wonder whenever some special fix becomes drean-only or such. Those few more cycles likely only add advantage on calculations for some games, hm?
Does anyone know about games/demos using the extra cycles of the drean?
My interest was only to have stable rasterlines for all VIC types. Just to be complete.
@TWW: I found your webpage about this topic after you post :-) |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
The module version of Spike+Minestorm have a drean detection and support it, also Jars Revenge ... |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
already discussed here a couple years ago detecting pal, drean, ntsc or old ntsc |
| |
Sokrates
Registered: Jun 2014
Posts: 7 |
Quote: The module version of Spike+Minestorm have a drean detection and support it, also Jars Revenge ...
Could you elaborate on that please? Maybe in a new thread "extra features in games/demos for drean" or so? |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
"support" only means that my (typical) CIA timers are adjusted if the different machines are detected, so the games will work. No more, no less. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
FYI - added a different approach to codebase64 a few days ago. Can save some bytes in specific situations.
http://codebase64.org/doku.php?id=base:efficient_tod_initialisa.. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Interesting.
This is the way I detect the frequency (after determining the model):
// Detect AC Frequency
// ===================
// PAL TEST 50Hz: #$7f
// PAL TEST 60Hz: #$32
// NTSC TEST 50Hz: #$b3
// NTSC TEST 60Hz: #$70
// NTSC2 TEST 50Hz: #$b3
// NTSC2 TEST 60Hz: #$70
// DREAN TEST 50Hz: #$70
// DREAN TEST 60Hz: #$20
DetectACFrequency:
lda #$ff
sta $dc04
sta $dc05 // CIA #1 Timer A = #$ffff
sta $dc06
sta $dc07 // CIA #1 Timer B = #$ffff
lda #$00
sta $dc0b
sta $dc0a
sta $dc09
sta $dc08 // CIA #1 TOD set to 00:00:00:00
ldx #%10000001 // CIA #1 Timer A Start + TOD = 50 Hz
lda VideoSystem
beq !+ // Branch if PAL (use 50Hz)
cmp #$03
beq !+ // Branch if DREAN (use 50Hz)
ldx #%00000001 // CIA #1 Timer A Start + TOD = 60 Hz (NTSC/NTSC2)
!: ldy #%01000001 // CIA #1 Timer B Start + Sync with Timer A
lda $dc08
!: cmp $dc08
beq !- // Wait untill TOD changes with 1/10 second
stx $dc0e // CIA #1 Timer A Start
sty $dc0f // CIA #1 Timer B Start
lda $dc08
!: cmp $dc08
beq !- // Wait untill TOD changes with 1/10 second
lda $dc05
ldx VideoSystem
beq PALorDREAN
cpx #$03
beq PALorDREAN
NTSCorNTSC2:
cmp Table50Hz,x
bne TOD50Hz
jmp TOD60Hz
PALorDREAN:
cmp Table50Hz,x
bne TOD60Hz
TOD50Hz:
lda #$81
ldx #$80
ldy #50
jmp !+
TOD60Hz:
lda #$01
ldx #$00
ldy #60
!: sta $dc0e
stx $dd0e // Set correct frequency on TOD Clocks and initialize CIA #1 & #2 Control Register A
sty ACMains
rts
//---------------------------------------------------------------------
// DATA: 50/60 Hz Detection Table
//
// PAL/50 - #$fffe 7f 28 - 98.519 cycles => MPU Clock = 0,985 MHz
// PAL/60 - #$fffe 32 24 - 118.235 cycles
//
// NTSC/50 - #$fffe b3 0f - 85.232 cycles
// NTSC/60 - #$fffe 70 7d - 102.274 cycles => MPU Clock = 1,023 MHz
//
// NTSC2/50 - #$fffe b3 12 - 85.229 cycles
// NTSC2/60 - #$fffe 70 6b - 102.292 cycles => MPU Clock = 1,023 MHz
//
// DREAN/50 - #$fffe 70 23 - 102.326 cycles => MPU Clock = 1,023 MHz
// DREAN/60 - #$fffe 20 32 - 122.829 cycles
Table50Hz: // Values to detect that
.byte $7f // PAL
.byte $70 // NTSC_OLD
.byte $70 // NTSC
.byte $70 // DREAN
Works in all configs of vice using a regular C64 but that 'could' be missguiding ,-) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
I basically needed simple way to properly initialise TOD. Being lazy I had a look at what was available on codebase but found only something I wouldn't want to use for a few reasons. Therefore I fired up a spreadsheet, calculated what was needed and wrote my own. Once done, adding only two CMPs looked like a no-brainer. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Do please share 8-) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
I'm not sure i understand. The aim is to detect the mains frequency regardless of the computer's native video mode? E.g.., be able to detect a PAL C-64 running in NTSC land and vice versa, for some reason? Why? :) |
| |
soci
Registered: Sep 2003
Posts: 479 |
Put there a large tolerance (like 4Hz) if it's used for anything important.
It's not like the mains frequency is always the same. The machine could run off generator/ups or some refurbished AT/ATX supply with a 12V inverter. Or someone just stuck in a 555 internally instead of bothering to build that inverter and set the trimmer so that the TOD speed "feels about right". |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting KrillI'm not sure i understand. The aim is to detect the mains frequency regardless of the computer's native video mode? E.g.., be able to detect a PAL C-64 running in NTSC land and vice versa, for some reason? Why? :)
The aim was neither to detect mains frequency (mains frequency is not necessarily the same as TOD ticks) nor the video norm. It was to detect TOD ticks frequency so that TOD can be set correctly up before being used. An old problem, to which I felt like better approach was needed. Only as a side-effect it can also detect the video norm. Therefore – if your PRG needs both TOD and PAL/NTSC – it's probably the most time/byte efficient approach. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting sociPut there a large tolerance (like 4Hz) if it's used for anything important.
It's not like the mains frequency is always the same. The machine could run off generator/ups or some refurbished AT/ATX supply with a 12V inverter. Or someone just stuck in a 555 internally instead of bothering to build that inverter and set the trimmer so that the TOD speed "feels about right".
Mains frequency is expected to be long-term stable. So yes, you are generally right. For something short-term important TOD's neither really accurate nor granular enough. As for what it runs off is a different thing. Surely you can't account for all possible modifications/deviations when you have only binary choice between expected 50 and 60Hz in the chip. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting Silver Dream !It was to detect TOD ticks frequency so that TOD can be set correctly up before being used. [...]Only as a side-effect it can also detect the video norm. Therefore – if your PRG needs both TOD and PAL/NTSC – it's probably the most time/byte efficient approach. I see. Not that it matters much, but i guess with the large tolerances for the mains frequency, your approach would likely misdetect a Drean C-64 as an NTSC machine (see also TWW's implementation). And of course a PAL SX-64 as well.
But i know now that i need to change my TOD setup code to not use the result of the video mode detection. :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting Krill[...] i guess with the large tolerances for the mains frequency, your approach would likely misdetect a Drean C-64 as an NTSC machine (see also TWW's implementation). And of course a PAL SX-64 as well.
I currently don't account for Drean so that's something to verify. Unfortunately I don't have any to test on real h/w. Why OTOH do you think would I misdetect PAL SX-64 (which I tested not to be the case)? The test PRG is here:
https://dl.dropboxusercontent.com/s/6wwli9ghhqvtjqh/test.c64
If somebody wants to take it for a spin then please run it for a prolonged period of time and see if only one line changes. I ran it on all tested machines for many hours (overnight the shortest). If someone has SCPU - please test it there too :-) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
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: 2969 |
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: 2969 |
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: 479 |
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: 5086 |
thats interesting so you can basicly measure the AC freq with the help of the TOD clock ? |
| |
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. |
