|  Post Your Message | |
| |
| | Previous Messages | Posted By
Gaia
on 2003-09-18
|  Re: PAL and NTSC
AFAIK there are certain registers (mostly other than $1b and $1c) that give back the last byte written to the SID... In this case it's better to use those to test (this feature is currently disabled in Yape ATM).
The demo's of Bionic/Synergy sport a SID detection algorhythm, maybe you could have a peek there as this behavioural part of Yape is not really 100% (to say the least).
|
|
Posted By
Crown
on 2003-09-18
| Re: PAL and NTSC
It is more complicated than that. That memory area is unconnected if there is no SID-card plugged in, and in those case the whole area gives random values when read.
The test should setup oscillator 3 to output a known waveform, then continously read either $1b (OSC3) or $1c(ENV3) and see what you get there. Note tough that the data will be slightly different for each SID type and revision as well...
A good resource for the SID is here
http://stud4.tuwien.ac.at/~e9426444/
|
|
Posted By
MC
on 2003-09-18
 | Re: PAL and NTSC
ok, i write to $fd5b and read back, it is ALWAYS a random value, at least in Yape 
sei
sta $ff3f
lda #$0
sta $fd5b
lda $fd5b
bne disp
lda #$30
bin.b $7c
disp:
lda #$31
sta $0c00
bne *
It should display 0 if no SIDcard present...
|
|
Posted By
TMR
on 2003-09-18
 | Re: PAL and NTSC
Those registers are a stock feature of the SID if memory serves, it should apply to wherever a SID card is mapped but don't quote me on that...
|
|
Posted By
Gaia
on 2003-09-18
| Re: PAL and NTSC
Detecting a SID is not straightforward as the registers are write-only. Although, if $FD40-5F is mapped, SID registers $1b and $1c should give you a random number indifferent of the value written.
I am not sure though if it works the very same way by the SID card...
|
|
Posted By
MC
on 2003-09-18
| Re: PAL and NTSC
ooops, that are major headaches.
first of all, vast majority of the high-tech demoeffects can not be scaled easily...
second, we don't really have NTSC hardware around here...
i think i better stay with NTSC detection and exit with error on those systems
BTW, how to detect the presence of a SID card?
|
|
Posted By
Gaia
on 2003-09-18
| Re: PAL and NTSC
Nice summary, Csabo! 
|
|
Posted By
Csabo
on 2003-09-18
| PAL and NTSC
This topic deserves a thread of it's own. Anyway. LOD is Back is one of the extremely few demos that are PAL and NTSC compatible. It's safe to say that almost all games/demos written in Europe are NTSC incompatible. The ones that were written by NTSC folks will usually run on both machines, but they will not use the extra horsepower of the PAL systems.
Detection: In my opinion, $40 on $FF07 is the simplest way to tell which machine you are working with. Sure, it can be changed manually before running the program. However, if someone does that, it's because their monitor can handle both formats, or they are just messing with your program, so it's fine.
How to write a NTSC compatible program: First of all don't overwrite $FF07, make sure to keep that $40 bit. Most simple raster effects will work just fine on both systems. NTSC has less rastertime though. The way to overcome that is to make the "number of whatevers" your demo a variable. For example, in LOD is Back, there are 15 bouncy things on PAL, 12 on NTSC. 30 bobs on PAL, 19 on NTSC. The plotter in the credits part is $5F long on PAL, and $3F on NTSC. I had to leave the vector cube out on NTSC completely, it used way too much rastertime. But I hope you get the point. Depending on the effect, you can do about 2/3s on NTSC. This, unfortunately, is always a trial and error process, and for that you probably need a real NTSC machine (until the emulators get good enough to properly emulate both).
For something more complex you might have to use separate code entirely.
One more thing: if you want to fade the screen in/out, on PAL you can wait for rasterline $FF, which is safely out of the screen on most monitors - so you won't see the dots when changing colors. On NTSC $FF is too late, it's already at the top of the screen. $F7 is a good value though. (This was the last fix I had to do in my demo, at the snake part.)
Music: it will be faster because of the faster refresh rate. It doesn't bother me, I think it's fine both ways, but you can compensate for it by slowing it down on NTSC systems.
That's all I can think of at the moment.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
