| |
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....
|
| |
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 ? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
