nesdev.org

Since we've already established that the palette contains different values on power-up, I still have to ask the same question again. If you leave the palette alone the screen will flash grey for a frame or two, which I think is best corrected by my first idea of filling the palette with 0x0F on a RO...

Bregalad wrote:...all bits can be neither one or zero at power up.

Erm, doesn't that defy the rules of logic?

tepples wrote:You only need to catch up the PPU on $2002 writes during those scanlines where $2002 is likely to change, such as those that contain sprite 0 and thosethat contain >= 8 sprites.

$2002 writes? Isn't $2002 read only?

I don't believe that doing so would make the emulator inaccurate. Waiting for a game to write to Colour 0 would be inaccurate, but setting all Palette values to a black colour would not effect any games (or is highly unlikely). Why do you think it would be wrong?

Can we all agree that the best values to have in palette memory when a ROM is loaded is either $0D, $0E or $0F? That way the screen won't flash grey for the first frame or two. I know that all NES's had pre-set values and some say that different colours would flash up, so I think that for neutrality...

1 CPU cycle = 3 PPU Cycles, unless you are in PAL mode then it is 3.2 PPU Cycles. 85.3 Cpu Cycles per Scanline, 28 CPU Cycles for HBlank. Those figures are about accurate.

I also had my own theory that CPU emulation would be handled by a very fast 65816 in 6502 emulation mode (or a small number of them). No doubt if we were to write off to an airline or hotel they would probably tell us to get stuffed if we requested a copy of the emulator (if one is used).

Even flown to the U.S. from the UK or vice versa? If so then you may of been able to play a Super Nintendo game in-flight. Now every passenger had the ability to do this at the same time and I doubt VERY MUCH that the airplane had 250 Super Nintendo consoles tucked away somewhere each with it's own ...

Here are some questions that I have. Thanks in advance for answering them. 1. Why is FCE Ultra so highly rated? It has a poor GUI and many bugs. For instance it can't run Clu Clu Land or Spy vs Spy, and they are basic NROM games. 2. Many emulators get a Dr. PC jr. pass in a PPU palette test in NEStr...

Yeah yeah, whatever.

Well isn't it? By now you should have phased out pathetically easy bugs like that.

Here is how I do mine:

if( (char)Accumulator + (char)Data + Carry < -128 || (char)Accumulator + (char)Data + Carry > 127 )
SetOverflow

Btw this is rather a noob question and does not belong in this section.

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?

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.

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?