| |
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....
|
| |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
A quick way to determine the number of cycles per line is to start a timer at raster line 0 then wait until raster line 256 and check the MSB of the timer.
Correctly done (just some inversion) you'll now have the number of cycles directly.
I do this here: http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/testprogs/V..
modesplit.asm, line 194, function check_time. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The easiest way to determine cycles/rasterline is to count the rasterlines:
312 rasterlines -> 63 cycles per line
263 rasterlines -> 65 cycles per line
262 rasterlines -> 64 cycles per line
Counting the lines:
w0 LDA $D012
w1 CMP $D012
BEQ w1
BCC w0
Result in Akku (low byte of rasterlinecount-1):
#$37 -> 312 rasterlines
#$06 -> 263 rasterlines
#$05 -> 262 rasterlines
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
It should be pointed out that my routine is designed for the purpose of hardware analysis and emulator evaluation.
I therefor require the number of cycles per line to be measured directly, not relying on the number of raster lines.
That routine should work with any timing encountered as long as there are more than 256 raster lines on the system.
There are no known hardware with timings different from those listed by Graham so normally you can use his method.
It will for almost all intents and purposes be equally accurate and shorter.
EDIT: nojoopa points out that the Drean PAL-N machine has 65 cycles per line and 312 raster lines so my statement about the known machines was wrong. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
