About the Earth demo (rNES C library)

[Zepper]

From this topic.

- A small correction: the iNES header offset 6 must be changed from 03 to 00 (horizontal mirroring, no battery). As far as I know, bit 1 means "backed battery", or "save/load 6000-7FFF to/from disk", it doesn't block WRAM access. Once the mirroring is changed, the Earth scrolls nicely.

- Now, the color glitch in my emulator: Petruza deserves a trophy, since I'm still looking for what's causing wrong colors in the Earth drawing. The glitch is present from beta 8 (beta 7 and older are fine), but my snapshots are poor - I have only beta 7 sources avaliable. I put back a lot of things, but still no effect.

- I know only 2 facts regarding this glitch: if I disable the color attribute byte while drawing, the earth has correct colors, so probably it uses the first 4 colors of the palette ram. Next, my cpu log file is huge - the first difference between beta7 and 8 is a VBlank time change.

- Offtopic: people here looks away of technical help, as it seems "noob" questions look MUCH more acceptable, or even some silly things and ideas. It's me or is this really true?

[blargg]

Has anyone even tried the demo on hardware?

[beneficii]

blargg,

I agree. To see if the error is in the emulators or in the software, we need to see what the software does on the actual hardware.

[tepples]

FCE Ultra gives the expected colors, but NES + PowerPak gives a black screen. I even had my camera ready only to be let down by nothing to shoot.

[Disch]

Fx3:

Are you clearing the nametables to 0 on powerup? First thing I think of is that he's not setting the attribute table properly and he's expecting the attributes to be zerod. Maybe your emu is assigning different attributes by default.

- Offtopic: people here looks away of technical help, as it seems "noob" questions look MUCH more acceptable, or even some silly things and ideas. It's me or is this really true?

Hey... I resent that. I try to help with technical problems when I can (and when I'm around -- I went on hiatus for a while).

Though "how do I fix my emu" problems can be hard because we're not familiar with your particular emu. Nobody is in a better position to answer questions about your emu than you are -- so if you're having a hard time, we'd likely have a hard time with it too. Maybe that's why you sometimes don't get the response you'd hope for.

[Zepper]

- Thanks, Disch.

[Bregalad]

Well, on the real hardware the name and attribute tables will *NOT* be zero-ed at powerup. You mustn't fix your emulator to run something that doesn't run on the real HW !

I guess NT, AT and CHR-RAM if present should contain mostly $ff with randomly a few bits clear to behave like real SRAMs. So does system-WRAM and RAM at $6000-$7fff if no battery present. That's the big drawback of emulation, even accurate emulators clear their RAM at powerup ! Only Nestopia doesn't do that I belive. I guess it put the high adress of the memory, once I remember seeing that $6000-$60ff were containing $60, $6100-$61ff contained $61, etc... I don't know about NT, AT and CHR-RAM tough.

[blargg]

FCE Ultra gives the expected colors, but NES + PowerPak gives a black screen. I even had my camera ready only to be let down by nothing to shoot.

So there you go, Fx3, your emulator should show a black screen when emulating this.

[tepples]

But then the PowerPak firmware might clear more RAM than the NES alone does.

[blargg]

Whoops; you're right, the PowerPak runs its own code before reset. If I'd paid more attention, I'd have realized your original point was that this shows that the code in question depends on the initial contents of memory.