| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
detecting pal, drean, ntsc or old ntsc
Hello,
I want to know if a test like this is reliable for the four different machine types PAL, NTSC, NTSC(old) and DREAN (ACME source code):
OLD_NTSC = 1
NTSC = 0
PAL = 2
DREAN = 3
!to "detect.prg",cbm
!cpu 6510
* = $0801
!by $0b,$08,$00,$00,$9e,$32,$30,$36,$31,$00,$00,$00
detect: sei
w0: lda $d012
w1: cmp $d012
beq w1
bmi w0
and #$03
cmp #$01
bne w2
lda #OLD_NTSC
bne detected ; unconditional
w2: cmp #$03
lda #$00
rol
beq detected ;ntsc
;check for drean or pal
ldx #$00
lda #$10
l inx
cmp $d012
bne l
lda #PAL
cpx #$70
bcc detected
;is a drean
lda #DREAN
detected:
tay
lax offset,y
l2: lda base_text,x
beq end
jsr $ffd2
inx
bne l2
end: lda #$0d
jmp $ffd2
base_text:
old_ntsc_text: !text "OLD "
ntsc_text: !text "NTSC",0
pal_text: !text "PAL",0
drean_text: !text "DREAN",0
offset:
!byte ntsc_text-base_text
!byte old_ntsc_text-base_text
!byte pal_text-base_text
!byte drean_text-base_text
|
|
... 63 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Groepazok so that improved since last time i checked (which was the first and last time i ever run a supposedly drean specific program =P)
then instead everyone bug tlr about fixing that damned sprite x stretch bug =D
Please do... ;)
For the record: what's holding me back is that my win32 dev environment no longer builds the trunk since some automake updates were committed a long while ago.
(that and the fact that I am a bit too lazy :) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
I'm still willing to test stuff on my Drean if people need it for working on better emulation. Just PM me.
I also have a NTSC 1983 250407 and a NTSC 1987 250466 hooked up in the lab. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
I may have overlooked something, but it seems most (all?) previously mentioned approaches check the line counter wrap to determine the video system.
Seems like this approach hasn't been mentioned yet (executed with SEI and screen on), taken from some soon-to-be-released real-world code of mine, obviously still has some opportunities to save bytes: ldx #$fc
- bit $d011
bmi -
- bit $d011
bpl -
- pha
pla
dex
txa
bne -
ldx $d012
cpx #$32
rol
cpx #$18
rol
eor #1After execution, accu contains 0 for NTSC, 1 for PAL, 2 for PAL-N.
The technique is to wait a fixed number of cycles starting from line 256 (in the lower border), then read the current raster line counter. The delay must be long enough such that a new video frame is guaranteed to be reached (and should be short enough to stay in borderland and not bump into any badlines).
Since all four C-64 video systems differ in number of cycles per rasterline AND number of rasterlines per frame, each of them comes out on a different rasterline.
Could be enhanced for NTSC-new vs NTSC-old detection, but i don't need that for my purposes, and i'm lazy now. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Did not check all former proposals, but tinkering around with NTSC lately, I used this for telling PAL&NTSC apart:
chk_ntsc: ldx #TAX
lda $d012
bne chk_ntsc+1
txa
bmi chk_ntsc
This always ends on rasterline $000 with X(=A)-values
$05: NTSC (64 cycles)
$06: NTSC (65 cycles)
$37: PAL
Unfortunately, it's not possible to distinguish between EU-PAL and PAL-N, but it was the shortest one I could come up with and that suited my needs. Maybe of interest for someone... |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Did not check all former proposals, but tinkering around with NTSC lately, I used this for telling PAL&NTSC apart:
chk_ntsc: ldx #TAX
lda $d012
bne chk_ntsc+1
txa
bmi chk_ntsc
This always ends on rasterline $000 with X(=A)-values
$05: NTSC (64 cycles)
$06: NTSC (65 cycles)
$37: PAL
Unfortunately, it's not possible to distinguish between EU-PAL and PAL-N, but it was the shortest one I could come up with and that suited my needs. Maybe of interest for someone...
Nice!!! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting CopyfaultUnfortunately, it's not possible to distinguish between EU-PAL and PAL-N Aw. Nice routine, but i need PAL-N detection. =) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quote: Did not check all former proposals, but tinkering around with NTSC lately, I used this for telling PAL&NTSC apart:
chk_ntsc: ldx #TAX
lda $d012
bne chk_ntsc+1
txa
bmi chk_ntsc
This always ends on rasterline $000 with X(=A)-values
$05: NTSC (64 cycles)
$06: NTSC (65 cycles)
$37: PAL
Unfortunately, it's not possible to distinguish between EU-PAL and PAL-N, but it was the shortest one I could come up with and that suited my needs. Maybe of interest for someone...
Freakin' C007!!
I often use videonorm detection along with TOD initialisation so my goto method is
https://codebase64.org/doku.php?id=base:efficient_tod_initialis..
which detects videonorm at almost zero extra cost but for standalone PAL/NTSC this is impressive :-) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting KrillQuoting CopyfaultUnfortunately, it's not possible to distinguish between EU-PAL and PAL-N Aw. Nice routine, but i need PAL-N detection. =) That can be helped ;)chk_ntsc: ldx #TAX
lda $d012
bne chk_ntsc+1
txa
bmi chk_ntsc
wait10lines: cmp #$37
bne end_chk
dex
cpx $0a
cpx #$0a
bne wait10lines
cpx $d012
bne end_chk
lda #00
end_chk: and #$03
rts
Ends with A (now != X)
$00: EU-PAL (63 cycles per line)
$01: old NTSC (64 cycles per line)
$02: standard NTSC (65 cycles per line)
$03: PAL-N (Dreany 65-cycles per one of the 312 lines)
Did not test thoroughly, but the waitloop should suffice to shift the cycle-pos to line $09 in case of a 65-cycles-per-line-system, for any cycle position the wait10lines-loop can start with. Bet it can be shortened even more, but... not this session, at least for me;)
Another minus: ends on different rasterlines ($00 on ntsc, $0a on PAL). Maybe a plus, depends on how you look at it... |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
chk_ntsc:
ldx #TAX
lda $d012
bne chk_ntsc+1
txa
wait10lines:
bmi chk_ntsc
cmp #$37
//pagebreak
bne end_chk
dex
cpx #$0a
bne wait10lines
cpx $d012
bne end_chk
lda #00
end_chk:
and #$03
rts
The bmi can be "embraced" for the waitloop - 2 bytes saved;) - but a pagebreak is needed in this case.
Another approach could be to wait for a rasterline that exists on all systems (i.e.$fc), then wait for 63*63 cycles. The rasterline which we're in after such a waitloop should uniquely determine the system. I'll maybe try this later, should become even shorter than the above. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
As usual: Please feel free to add stuff like this to Codebase. Generations of C64 coders will thank you for all eternity. :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
