Page 1 of 2

PAL NES Questions

Posted: Thu Feb 16, 2006 6:21 am
by opius
What is the correct number of CPU Cycles for a scanline on a PAL NES.
106+5/9 or 106+9/16
And is it correct that the vblank period is 70 scanlines? ..

Posted: Thu Feb 16, 2006 6:54 am
by WedNESday
There are 106.53 CPU Cycles per scanline for a PAL NES.

Yes there are 70.

70 Scanlines (VBlank)
1 Dummy Scanline
240 Scanlines (Visible)
1 Dead Scanline

Posted: Thu Feb 16, 2006 7:21 am
by hap
Indeed. That number is calculated by dividing 341 (number of PPU cycles per scanline) by 3.2 (CPU speed vs PPU speed ratio).

(should be moved to newbie forum?)

Posted: Thu Feb 16, 2006 8:14 am
by Guest
WedNESday wrote:70 Scanlines (VBlank)
Boy, this is enough for a hell lot of tricks. No wonder elite needs PAL hardware to work.

Posted: Fri Feb 17, 2006 12:06 pm
by LocalH
PAL hardware seems to be universally better for demo effects, regardless of which system you're talking about. C64, Amiga, NES, SNES, Genesis, and any other system where the programmer has full control at the cycle level. Those extra VBlank lines really help out, especially on a system like the Genesis where you can write heaps more data to the VDP RAM during non-active scan.

Posted: Fri Feb 17, 2006 12:42 pm
by Bregalad
A flaw of the PAL TVs is that is doesn't hide the top and bottom 8 pixels, making a lot of glitches in pretty much every NES game. The sprites doesn't scroll proprely at the top because they cannot have negative coordinates and the BG glitches when scrolled.

Posted: Fri Feb 17, 2006 12:54 pm
by tokumaru
Yeah... those evil glitches! =)
The PAL NES seems to be fun for demos, but I kinda fell like what I fell about using MMC5. A bit like cheating. Maybe even worse. You see, there's the PAL system and the NTSC system, but they are the same videogame, the NES. If you make something that only runs on half the NES's around, it doesn't fell like a NES game anymore. How come there is a NES game that doesn't run, and can't even be converted to run, on half (most likely more than half, no?) of the NES systems? Just doesn't feel right using all that VBlank time, you know?

Posted: Fri Feb 17, 2006 1:07 pm
by Bregalad
Effectively, a PAL game using all it's VBlank cannot run on NTSC.
That's the main reason why I always devlopp games with NTSC in mind even if I'm from a PAL country. The second reason is that the NES is a japaneese console basically, and that the original japaneese NES is NTSC. The PAL NES is just a "port" of it.
However, the whole PAL VBlank could be used in a game where several frames are needed for some thing to be written to the nametable/pattern table and cause slowdowns, but could be fast up on a PAL system by taking less frames. This would "compensate" the fact that the system runs 5/6 slower.

Posted: Fri Feb 17, 2006 1:14 pm
by tepples
Bregalad wrote:Effectively, a PAL game using all it's VBlank cannot run on NTSC.
What part of bit $2002 bvc :- lda #0 sta $2001 don't some PAL-to-NTSC porters understand? If you limit your NTSC version to 192 scanlines, using either sprite 0 or the mapper's timer or both to detect the top and bottom of the window that you want to use, then you have just as much vblank time as any PAL NES has.

Posted: Fri Feb 17, 2006 1:22 pm
by tokumaru
Bregalad wrote:Effectively, a PAL game using all it's VBlank cannot run on NTSC.
Exactly what I said. If it's not possible for a game to run on both systems, not even through some hacking, it should not be called an actual NES game.
That's the main reason why I always devlopp games with NTSC in mind even if I'm from a PAL country. The second reason is that the NES is a japaneese console basically, and that the original japaneese NES is NTSC. The PAL NES is just a "port" of it.
Yeah, the basic ideas were designed for NTSC. I too prefer to code stuff compliant to the "origin".
However, the whole PAL VBlank could be used in a game where several frames are needed for some thing to be written to the nametable/pattern table and cause slowdowns, but could be fast up on a PAL system by taking less frames. This would "compensate" the fact that the system runs 5/6 slower.
I agree. If you're improving something, I guess that is OK. The wrong thing is when you can say this about a game: "This will not run on a NTSC console, never, ever, no matter how much you change it".

Posted: Fri Feb 17, 2006 1:34 pm
by tepples
Of course, anything is possible if you hack the cartridge to use dual-ported VRAM. A FIFO in a CPLD on the cart would capture writes to CPU $5000-$7FFF, queue them, and execute them in VRAM when the PPU isn't busy accessing VRAM. (It reads or writes only on every other cycle.)

Posted: Fri Feb 17, 2006 2:00 pm
by LocalH
Bregalad wrote:A flaw of the PAL TVs is that is doesn't hide the top and bottom 8 pixels, making a lot of glitches in pretty much every NES game. The sprites doesn't scroll proprely at the top because they cannot have negative coordinates and the BG glitches when scrolled.
I don't consider that a glitch in PAL, I consider that a short-sightedness of NTSC developers. The way I understand it, the hiding of those 16 scanlines was more a function of NTSC overscan rather than the NES not outputting them. An NTSC Genesis has 224 addressable scanlines, but 240 total outside of blanking, however it's impossible to see those 16 lines of border on most NTSC sets (but it is possible to view them on an underscanned monitor), so the system doesn't even give you access to them (it's possible to switch a PAL MD to 240 lines of addressable screen, but this doesn't work on NTSC).

Posted: Fri Feb 17, 2006 4:03 pm
by Memblers
tepples wrote:Of course, anything is possible if you hack the cartridge to use dual-ported VRAM. A FIFO in a CPLD on the cart would capture writes to CPU $5000-$7FFF, queue them, and execute them in VRAM when the PPU isn't busy accessing VRAM. (It reads or writes only on every other cycle.)
The only part of this I can't figure out is how to generate an actual /write pulse for the VRAM.

Posted: Fri Feb 17, 2006 4:33 pm
by tepples
Memblers wrote:
tepples wrote:A FIFO in a CPLD on the cart would capture writes to CPU $5000-$7FFF, queue them, and execute them in VRAM when the PPU isn't busy accessing VRAM.
The only part of this I can't figure out is how to generate an actual /write pulse for the VRAM.
The 21.5 MHz master clock is visible on the cart edge, right? After a PPU read cycle, you could wait a few 21.5 MHz clocks and then generate the /write pulse. Or are you talking about pin count?

Posted: Fri Feb 17, 2006 7:26 pm
by Memblers
tepples wrote:
Memblers wrote:
tepples wrote:A FIFO in a CPLD on the cart would capture writes to CPU $5000-$7FFF, queue them, and execute them in VRAM when the PPU isn't busy accessing VRAM.
The only part of this I can't figure out is how to generate an actual /write pulse for the VRAM.
The 21.5 MHz master clock is visible on the cart edge, right?
Nope, at least not on top-loading NES's and Famicoms. So that's no good. I dunno where to get the pulse. If I took CHR /RD and put it through a delay line maybe that'd work, but that'd cause the dumb situation of having VRAM updates not doable during vblank.. heheh. And delay lines are expensive anyways.