It is currently Wed Oct 18, 2017 2:33 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: PAL NES Questions
PostPosted: Thu Feb 16, 2006 6:21 am 
Offline
User avatar

Joined: Sun Feb 12, 2006 4:00 pm
Posts: 3
Location: Linkoping / Sweden
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? ..

_________________
/opius


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 16, 2006 6:54 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
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

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 16, 2006 7:21 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
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?)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Feb 16, 2006 8:14 am 
WedNESday wrote:
70 Scanlines (VBlank)

Boy, this is enough for a hell lot of tricks. No wonder elite needs PAL hardware to work.


Top
  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 12:06 pm 
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.


Top
  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 12:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 12:54 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10050
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 1:07 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 1:14 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19093
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 1:22 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10050
Location: Rio de Janeiro - Brazil
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".


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 1:34 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19093
Location: NE Indiana, USA (NTSC)
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.)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 2:00 pm 
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).


Top
  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 4:03 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 4:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19093
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 17, 2006 7:26 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], calima and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group