| |
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
|
|
... 72 posts hidden. Click here to view all posts....
|
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Gents - the main point is that unless I write h/w diagnostic software, I basically initialise TOD because I need it for the PRG to serve its purpose. Otherwise I wouldn't waste bits for checking the frequency, would I? Of course if I have a very good day and mem to spare I might do a more graceful exit and maybe even tell the user "Hey - your TOD is broken. I quit." In generic case though I hardly see a point in accounting for broken hardware. TOD that does not count what it should is of no use, even if everything else works correctly. Drean is a different thing because it has a different characteristics even if working 100%. As much as I understand it (never had one in hands) it doesn't change much in terms of TOD initialisation, which should still work as expected also on Drean. It does change in terms of the video norm though, because if the CIA clock is the same as on NTSC machines then it will recognise it as NTSC. This might be worth researching and eventually accounting for (if possible) but only if we talk about the side-effect of recognising video norm next to TOD ticks freq. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting Krill[..](And a system with unreliable timers is not what i'd like to code for or consider for compatibility.)
Precisely that. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting KrillEdit: Groepaz told me of this TDC-L (D1) 2/4Mhz C64 Accelerator which does indeed change CIA clocking, and not consistently depending on mode. In a C64 CIA is clocked off PHI2. Since Kisiel clocks CPU at variable rate there, that will affect. |
| |
Krill
Registered: Apr 2002
Posts: 2847 |
Quoting Silver Dream !Quoting KrillEdit: Groepaz told me of this TDC-L (D1) 2/4Mhz C64 Accelerator which does indeed change CIA clocking, and not consistently depending on mode. In a C64 CIA is clocked off PHI2. Since Kisiel clocks CPU at variable rate there, that will affect. I know. I just wasn't aware that there are accelerators which do not come with an own external faster CPU but do the ballsy thing of speeding up operation of parts of the C-64 itself, including overclocking the CPU. Thought there were a few good reasons why Commodore didn't do this in the first place. :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting KrillI just wasn't aware that there are accelerators which do not come with an own external faster CPU but do the ballsy thing of speeding up operation of parts of the C-64 itself, including overclocking the CPU. Thought there were a few good reasons why Commodore didn't do this in the first place. :)
I recall there was a quasi-2MHz accelerator for the 64 once published in 64'er but AFAIR it used properly rated CPU for that. I don't recall ever seeing ICs rated higher than 2MHz in a 64. Most are 1MHz rated in fact. It doesn't mean they won't run but it means that if they do, they run (partially way) out of specs. IOW, while I truly appreciate Kisiel's ideas, I wouldn't bet on full reliability of this approach in *every* machine. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
