| Posted By
Charles
on 2024-03-03
12:22:15
|  NTSC vs PAL compatibility
Hi Guys,
Can someone with a bit of relevant programming experience advise what needs to be changed to make a proggy fully work in NTSC as well? What do I need to detect (I guess 6th bit in $FF07 is sufficient) and what to adjust? There is a different screen refresh freq 60 vs 50 Hz, and different amount of screen lines if not mistaken.. Do I need to change Raster timings ($FF0B) for the visible screen part..? And I guess there must be less CPU cycles per screen. But are there same amount of available cycles in each scan line (and just diff count of lines) or everything is upside down..?
Sorry if this is a lame question but I've never looked at this matter, and I am curious if it's 1. easy to adjust my code 2. if it makes any sense to put effort into this in 2024.
Any help, tips, opinion is highly appreciated.. 
|
|
Posted By
gerliczer
on 2024-03-03
13:49:33
| Re: NTSC vs PAL compatibility
Visible parts need no adjustment. 262 vs. 312 raster-lines. Raster-line timing is exactly the same.
1 Depends on your code's cycle consumption. If it does not exceed what is available in NTSC then probably easy. Except the higher frame rate may need compensation.
2 Over at CSDb I see a lot of re-cracks of games that boast of NTSC compatibility. So I think it is worthwhile. Sometimes, even I try, too.
|
|
Posted By
TLC
on 2024-03-03
14:14:05
| Re: NTSC vs PAL compatibility
In short:
- Scanline timing is similar
- Top and bottom vertical borders have 25-25 less scanlines (roughly equally, but I don't remember exact details). All in all - you have 50 less border scanlines per frame.
- Kernal ROM is different (--> different signature bytes, different init value for $ff07). Yes, you'll find $48 in $ff07 on an NTSC machine (after reset).
- The visible screen part is unaffected (as much as $ff0b, $ff1a- $ff1f is concerned). That's in fact true for the visible screen part plus the first few ten lines of the bottom vertical border.
Frame rate is ~ 60Hz.
There are also two aesthetic differences (maybe nothing to do about them, but they'll be there anyway). First, the visible screen area is slightly stretched, compared to that of PAL. (Think this over: you have the same sized CRT, but you display 50 less (equally spaced) scanlines, of which the "visible screen area" is still 200 lines high.) Second, the colour palette would be a small bit different to that of PAL, horizontal colour resolution would be a bit worse. Unlike in PAL, no colour averaging would happen between adjacent scanlines. (All of them consequences of PAL - NTSC colour encoding differences.)
|
|
Posted By
Charles
on 2024-03-03
20:09:46
| Re: NTSC vs PAL compatibility
Thank You both for the prompt and precious answer, I think I get it.
My first attempt also suggested visible part should have the same timings and CPU cycles, but after all, if code is optimized for double buffering at 25 Hz - and almost all raster time is already allocated - I will probably need to target 20 Hz in NTSC (new screen every 3rd frame)
Still not sure about if it makes any sense though Are there NTSC +4 machines still around and "in use"?
|
|
Posted By
JamesC
on 2024-03-03
23:02:57
| Re: NTSC vs PAL compatibility
Are there NTSC +4 machines still around and "in use"?
Mine is packed away. I use YAPE when I'm in a nostalgic mood. 
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
