What PPU rendering differences are there between the PAL and NTSC 2C02? I ask this because Brad Taylor's NTSC 2C02 Technical Reference doesn't mention PAL.
I am aware of the following;
1. Different VBlank Time
2. 106/113 CC per Scanline
3. 3/3.2 Pixels rendered
4. 232/240 Scanlines
Anything else?
Only differences between NTSC and PAL systems that I'm aware of are:
1) 70 scanlines of VBlank instead of 20 (making 312 scanlines in a frame instead of 262)
2) The pre-render scanline is ALWAYS 341 ppu cycles on PAL instead of alternating between 341 and 340 like it does on NTSC
3) 3.2 CPU cycles to every 1 PPU cycle on PAL... instead of 3 CPU cycles to 1 PPU cycle like on NTSC (this effectively makes a scanline 106.5625 CPU cycles long instead of 113.6666667)
4) PAL CPU clock rate is 1.65 MHz (1652097.902 I believe)... slightly slower than NTSC's 1.79 MHz. This lowers the pitch of sound played on PAL systems.
5) Adjusted DMC frequency lookup table to adjust for the pitch difference.
6) The top and bottom 8 scanlines on PAL displays aren't clipped like they usually are on NTSC displays (all 240 rendered scanlines are visible)
7) ~50.0 FPS on PAL instead of ~60.1 FPS like on NTSC
Disch wrote:
3) 3.2 CPU cycles to every 1 PPU cycle on PAL... instead of 3 CPU cycles to 1 PPU cycle like on NTSC (this effectively makes a scanline 106.5625 CPU cycles long instead of 113.6666667)
lol. I think you mean 1 CPU cycle for every 3.2 PPU cycle on PAL.
gah... yeah I always do that.
CPU cycles are 3.2 times as long... not the other way around.
Gah!!!
But yeah you know what I mean ;D
2 things:
1. The PAL PPU is not an RP2C02(G) - it is an RP2C07(G?).
2. The PAL CPU clock rate is not 1652097.902Hz, but 1662607Hz.
Thanks, it's just that I heard it is better to include PAL support as you write your PPU code not include it after.
Since PAL renders 3.2 pixels, do you render an extra pixel every 5 CPU cc's?
On PAL NES system, total scanline is 312 lines, but VBlank time is still 20 lines, because VBlank start at 291 line(0-241 are display lines).
tpu wrote:
On PAL NES system, total scanline is 312 lines, but VBlank time is still 20 lines, because VBlank start at 291 line(0-241 are display lines).
Sorry, but you're absolutely
wrong. The PAL PPU generates NMI at line 241 just as the NTSC PPU does, so there are exactly 70 scanlines worth of VBLANK.
How do I know this? I've examined tests (performed by kevtris) done on an actual PAL PPU which clearly show NMI staying low for a duration of 70 scanlines.
I have a PAL rom that run fine on a real PAL nes. But on emulator, it run the same only if I start VBLANK at lines 291. I'll make a test rom recently.
I have made a test on my NES(nes on chip).
My TV system is PAL-D. My NES have a 26.601712 MHz clock input.
This is the result:
1: ppu cycles per frame: 106392 (341*312)
2: ppu cycles per line: 341
3: lines per frame: 312
4: VBlank lines: 20
NMI driven PAL games which use CPU-cycle counting IRQ timers (such as Mr. Gimmick) will not work properly if there's only 20 scanlines between NMI and rendering -- you need the full 70.
Other PAL games which don't rely on sprite-0 hit or IRQ counters ... using nothing but cycle-timed code (PAL version of Balloon fight, for example) will not scroll properly unless there's 70 scanlines between NMI and the start of the frame.
You just said you were using an NES-on-a-chip. It would appear to be very likely that it is NOT a perfect copy, as a real NES PAL PPU (RP2C07) provides a full 70 scanlines between NMI/VBLANK and the beginning of the next frame.
As far as I'm concerned, only tests performed on genuine Nintendo hardware are relevant. Tests on clones are as useful as tests on emulators, that is, for showing any inaccuracies as compared to the real thing.
I can't get a real PAL mode NES now. But I think NES-on-a-chip have the better compatibility than real PAL NES. Almost all NTSC mode games can run on it with a little slowly.
tpu wrote:
But I think NES-on-a-chip have the better compatibility than real PAL NES.
By definition,
nothing can have more compatibility than a real PAL NES.
For the record, when kevtris tested a genuine PAL PPU (RP2C07-0) in his 3-in-1 tester (which manually clocked the PPU and examined its external data/address bus and read/write and NMI lines), I got the following results:
1: ppu cycles per frame: 531960 / 5 ==
106392
2: ppu cycles per line: 1705 / 5 ==
341
3: lines per frame: 106392 / 341 ==
312
4: VBlank cycles: 119350 / 5 ==
23870 --> 23870 / 341 ==
70 lines
I think tpu meant better compatibility with NTSC games than a PAL NES. Thing is, an NTSC NES has perfect compatibility with NTSC games, a PAL NES has perfect compatibility with PAL games, and anything between will have some incompatibility with both.
Quote:
I think tpu meant better compatibility with NTSC games than a PAL NES.
Yes.
There have too many NTSC games on the world, a system like NES-on-a-chip is better choose in china.