| |
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....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I put it on codebase:
http://codebase64.org/doku.php?id=base:detect_pal_ntsc
I also wonder... does Ninja's older routine have any benefits over and above this short 12 byte routine? (Didn't have any time/energy to look into it myself now, sorry.) If not, I guess it could just as well be removed.
//FTC |
| |
Devia
Registered: Oct 2004
Posts: 401 |
You still need to catch NMI and disable IRQ for it to be completely reliable - and the 12 bytes is without the bcc in the end, which may be obsolete depending on how you implement it.
|
| |
Ninja
Registered: Jan 2002
Posts: 404 |
Frantic:
Technically, my routine does not have an advantage. From an educational point of view, it has (it was supplement code to an article after all) :) If you don't know the topic, then it surely helps to read my routine first, before you use the other (probably with disabling interrupts there, too). |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Okok... Thanks for the information. In fact, I added the whole article to the page, since I guess it might add something of value to someone out there. (Just tell me if you mind...) |
| |
Kickback
Registered: Apr 2004
Posts: 97 |
Actually this helps me BIGTIME. Because I always thought that the PAL/NTSC register was the way to go.
Thanks guys for the information, helps me with NTSc/PAL intros ;-)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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: 11108 |
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: 490 |
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 :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
