| |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
First of all: thanks to the testers!!! The routine behaves as it should on all tested real machines: in total 3 with new NTSC-VIC, one with old NTSC, two Drean-systems and two EU-PAL-systems (not counting my own system here).
So I think it's save to say the routine works. I just wrote up a (rather longish, sorry) explanation on codebase (-> yes, pswd has been found \o/).
Feel free to edit it or drop me a comment via pm if you think it should be changed/shortened/extended... |
| |
Knight Rider
Registered: Mar 2005
Posts: 114 |
I am sure the purists will argue that the SEI in the routine could lead to false results in some circumstances |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Really elegant! I might switch to that. Currently in Eye of the Beholder I use a timer and wait for a while, then check what raster line I'm on:
sei
lda #0
sta $d011
sta $dc0e
sta $dc0f
bit $d011
bpl *-3
bit $d011
bmi *-3
lda #$7f
sta $dc0d
bit $dc0d
lda #<(16384-1)
sta $dc04
lda #>(16384-1)
sta $dc05
lda #%10011001
bit $d011
bpl *-3
sta $dc0e
:lda $dc0d
beq :-
lda $d012
ldx #SYSTEM_PAL ;SYSTEM_UNKNOWN (default PAL and live with gfx glitches instead of total crash)
cmp #$cc
bne :+
ldx #SYSTEM_PAL
:
cmp #$f5
bne :+
ldx #SYSTEM_NTSC
:
cmp #$fa
bne :+
ldx #SYSTEM_NTSC_OLD
:
cmp #$c4
bne :+
ldx #SYSTEM_DREAN
:
stx system
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Knight RiderI am sure the purists will argue that the SEI in the routine could lead to false results in some circumstances Well, the SEI was the smallest solution to switch off IRQs (besides NMI ofcourse). As mentioned in the introductory text for the full VIC-detection routine, the routine requires to be run in a badline- and IRQ-free environment. Since such a VIC-detect-routine is usually called when initialising also other things, I don't think the SEI is a real problem here - depending on how you arrange your overall init code, it could even be ommitted.
Quoting JackAsserReally elegant! I might switch to that.
... Thanks! Feel free to use it if it improves things on the project. Ah, and thanks for sharing your code;) |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting JackAsserthen check what raster line I'm on:
[...]
bne :+
[...]
bne :+
[...]
Is there a specific reason to check for equality rather than ranges? =) |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting CopyfaultSo here comes my final (and hopefully robust-as-f*ck) version:
chk_victype: sei
ldy #$04
ld_DEY: ldx #DEY //DEY = $88
waitline: cpy $d012
bne waitline
dex
bmi ld_DEY + 1
wait40lines: lda $d012 - $7f,x
dey
bne wait40lines
and #$03
rts
Does this boil down to the same basic approach i suggested in https://csdb.dk/forums/?roomid=11&topicid=94459#146098 - but squeezed for size? =) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserthen check what raster line I'm on:
[...]
bne :+
[...]
bne :+
[...]
Is there a specific reason to check for equality rather than ranges? =)
Not really no, but bcc and bcs are so complicated. :D |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Krill[...]Does this boil down to the same basic approach i suggested in https://csdb.dk/forums/?roomid=11&topicid=94459#146098 - but squeezed for size? =) Correct! I pointed this out in the text I wrote on codebase, i.e. that the idea was brought up by a certain Krill;)
Have to admit that I had this idea on my own but it took me some days until I fully realised that this idea was not new at all, but rather the reason for your post here in the thread (see link above). Well, that tunnel thing /o\ |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting JackAsserNot really no, but bcc and bcs are so complicated. :D Though you were obviously joking... i use to picture CMP as just an SBC that doesn't store the result and has a built-in SEC. Then it becomes quite easy to decide between BCS (A/X/Y >= value) and BCC (A/X/Y < value). :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Quote: Quoting JackAsserNot really no, but bcc and bcs are so complicated. :D Though you were obviously joking... i use to picture CMP as just an SBC that doesn't store the result and has a built-in SEC. Then it becomes quite easy to decide between BCS (A/X/Y >= value) and BCC (A/X/Y < value). :)
Hehe.. Yeah, that's exactly how I think about it as well. So far so good, but if we talk about the v-flag instead (as associated with bvc/bvs), I have to confess that it is much less clear to me how to conceptualize it. Sometimes I use it with the BIT instruction, but then I just treat it as... a bit, e.g. a way to check the status of bit6. Using it with ADC/SBC is another issue. Anyway, back to topic. :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
