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? ..
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
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?)
WedNESday wrote:
70 Scanlines (VBlank)
Boy, this is enough for a hell lot of tricks. No wonder
elite needs PAL hardware to work.
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.
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.
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?
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.
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.
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.
Quote:
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".
Quote:
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".
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.)
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).
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.
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?
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.
Quote:
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.
Not an 8-bit shift register like the one in every NES and SNES controller. :)
It's analog delay lines that are expensive.
A shift register, interesting idea. I don't know what would clock it though. All I've got so far is CHR/RD NAND CHR/WR for the 'idle cycle /CE'.
Here's the kind of delay line I was talking about.. these suckers are over $6 each.
http://pdfserv.maxim-ic.com/en/ds/DS1100.pdf
Sorry for hijacking the thread a bit.. it's still on topic somewhat though. It'll be cool once this kinda stuff works.
> 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.
>
> 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.
> 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".
This is pure BS IMO. The goal of retrocoding typically is to make cool stuff that works on the favorite console of your childhood memories, and I fail to see why anyone doing so should feel obliged to consider similar consoles which can only be played in black-and-white on his television, and are only used in countries far abroad which he may never even visit. And this most definitely goes for the case when his target console is far superior to the foreign similar ones mentioned above.
Even a pirate clone with mediocre NES compatibility is a perfectly valid target system, as long as you specify it as the target system. (i.e., label your creation a Pegasus game (or any other clone system you developed it for) rather than a NES game)
On the other hand, I agree that it is a nice goal to code your stuff for both systems. And if you wish to eBay your creation when done, you better do some thinking about how to convert (or peel off) its features to make it NTSC-compliant if you want to make some cash off retrogamers out there.
> 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.
Come again? PAL television sets predate the NES's birth by MANY years, so I can assure you that the flaw is not in the TV. A PAL TV has 288 visible lines out of 312 total (312.5 if you want to be interlace about it), and the PAL NES just fills the empty lines out with more neat vblank time.[/quote]
Yeah, I mean PAL NES, not PAL TVs, I went wrong. Sorry.
Bananmos wrote:
Even a pirate clone with mediocre NES compatibility is a perfectly valid target system, as long as you specify it as the target system. (i.e., label your creation a Pegasus game (or any other clone system you developed it for) rather than a NES game)
But then you get into "Nesticle games" which might be fine for (say) a few
Final Fantasy fans (and marginally better than
Fake fake fake fake fake) but apparently not for some vocal critics. That said, "FCE Ultra/Nestopia/Nintendulator games" are fine for at least me right now.
Quote:
On the other hand, I agree that it is a nice goal to code your stuff for both systems. And if you wish to eBay your creation when done, you better do some thinking about how to convert (or peel off) its features to make it NTSC-compliant if you want to make some cash off retrogamers out there.
But then you're either tearing apart NES carts to get lockout chips or you're selling "NES-with-CIC-pin-4-cut games", not "NES games".
tepples wrote:
selling "NES-with-CIC-pin-4-cut games"
Otherwise known as "Famicom/Toploader-NES games"...
But are there enough PAL toploaders?
Bananmos wrote:
I fail to see why anyone doing so should feel obliged to consider similar consoles which can only be played in black-and-white on his television, and are only used in countries far abroad which he may never even visit.
That comment was kinda selfish. We, here in the nesdev boards, are from many different countries, but we still like to share our projects with each other (after all, who could be more interested in nesdev'ing than other nesdev'ers?). Wouldn't it be nice if everyone could enjoy your game/demo just as much?
Of course it's all easier with emulators, just set it to whatever the demo/game is supposed to run in.
It's not an obligation... It's just that compatibility is a nice thing to have.
Making something work on both a PAL and NTSC NES costs something in extra complexity and lack of use of things which only work on one console. As an example of the costs, consider what it would take to make these nesdev boards accessible to someone no matter what their native language, to the point of disallowing any discussion that isn't accessible to everyone, and making everyone put up with the endless rounds of misunderstanding due to poor language skills. Without a restricted scope, many things would never get done due to the cost of the general solution (selfishness is an example of this, the scope being restricted to what is in one's own interests).
tepples wrote:
Bananmos wrote:
Even a pirate clone with mediocre NES compatibility is a perfectly valid target system, as long as you specify it as the target system. (i.e., label your creation a Pegasus game (or any other clone system you developed it for) rather than a NES game)
But then you get into "Nesticle games" which might be fine for (say) a few
Final Fantasy fans (and marginally better than
Fake fake fake fake fake) but apparently not for some vocal critics. That said, "FCE Ultra/Nestopia/Nintendulator games" are fine for at least me right now.
I'd say on my own that any poorly written NES programm that only runs under nesticle or something, big changes are that is it possible to fix it to run on a real NES or a decent emulator proprely, unlike the faked faked faked faked FFX for NES, which actually has nothing to do with the NES exept graphics.
yeah, celius phrase is like a stick it's sound good...
ff nes imitators
fake fake fake fake fake fake!!!
ps: memblers.. can you making a automatic fake counter and send it to ff imitators??? hahaha (lol)