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