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