Nestopia

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
Bregalad
Posts: 8008
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Jul 09, 2006 1:23 pm

I recommand you to use $2005 and $2000 every VBlank to setup proper scrolling. $2006 is weird, because it only allow you 8-pixel precision. Use $2006 for scrolling only during rendering if you have no other way to do arround.
If you set your sprites to 8x16 the selection nametable will be effectivly ignored.
Useless, lumbering half-wits don't scare us.

User avatar
Lloyd Gordon
Posts: 150
Joined: Mon Nov 07, 2005 11:32 am
Location: Toronto
Contact:

Post by Lloyd Gordon » Sun Jul 09, 2006 7:05 pm

Bregalad:

Here's the last part of my NMI routine before I restore the registers:

lda $2002 ;reset $2006 flag
lda <NamTab ;puts background to current nametable
sta $2006
lda #$00
sta $2006
lda <Scrollx ;horizontal scroll
sta $2005
lda #$00
sta $2005

NamTab is a variable containing either $20 or $24 which are the nametables I use. From my reading of Brad Taylor's "NES PPU addressing/scrolling operation details" vertical & horizontal table selection latch/counters can be set by either bits 1 & 0 of $2000 or bits 3 & 2 of the first write to $2006 (after reading $2002). So since I am using 8 x 16 sprites I don't see what I have to gain from updating $2000 in VBlank (bit 3 of $2000 is ignored). Also I was under the impression that you should always set the PPU address by writing the proper values to $2006 towards the end of VBlank. Anyway, I tried your advice and updated $2000 at the end of VBlank and the same thing happened. If I'm missing something, please let me know.

Marty:

I just downloaded 1.32 and the same thing happened. I will send you the rom and the source code. Let me know what I can do to have my sprites show up on Nestopia. I really like the NTSC filter. It really helps optimize palette choices to avoid nasty NTSC effects.

Thanks to all for the great help.

Marty
Posts: 40
Joined: Fri Nov 12, 2004 5:02 am

Post by Marty » Sun Jul 09, 2006 8:32 pm

Ah, uninitialized CPU RAM seems to be the cause. The second sprite turns up only if I let it be zero-filled after a cold boot. To fix this, just initialize it manually and everything should work. As for the reason of it working on a CopyNES, I assume it's because it does this automatically for you?

User avatar
Quietust
Posts: 1682
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust » Sun Jul 09, 2006 8:55 pm

Marty wrote:Ah, uninitialized CPU RAM seems to be the cause. The second sprite turns up only if I let it be zero-filled after a cold boot. To fix this, just initialize it manually and everything should work. As for the reason of it working on a CopyNES, I assume it's because it does this automatically for you?
Quietust wrote:I suspect the problem may be related to uninitialized memory.
The CopyNES BIOS initializes some of the system RAM for its own purposes.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Mon Jul 10, 2006 7:47 am

So how does Nestopia handle uninitialized memory differently than Nintendulator? The program works on Nintendulator and not on Nestopia. What exactly is the proper way to emulate uninitialized memory? Is it filled with purely random bits upon boot, or is it something less than truely random?

User avatar
hap
Posts: 355
Joined: Thu Mar 24, 2005 3:17 pm
Contact:

Post by hap » Mon Jul 10, 2006 8:26 am

What exactly is the proper way to emulate uninitialized memory?
blargg has tested that about a year ago, it's filled with $FF.

User avatar
Quietust
Posts: 1682
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust » Mon Jul 10, 2006 8:32 am

There is no correct way to handle uninitialized memory - most SRAM chips may start up filled with FF, but we've seen some that start with a few locations containing different values.

The "proper" method would be to start with RAM initialized to completely random data, but that would cause significant other problems for emulators that want to support movie recording (as it would require always storing the randomized-uninitialized memory in the movie file).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

User avatar
Lloyd Gordon
Posts: 150
Joined: Mon Nov 07, 2005 11:32 am
Location: Toronto
Contact:

Initialize CPU memory

Post by Lloyd Gordon » Mon Jul 10, 2006 11:40 am

Ok, now I'm completely confused. I tried setting all the memory from $0000-$07FF to either $00 or $FF at reset . Still my second character using $0208-$020F won't show up. Clearly I'm missing the boat here. Any help would be appreciated. Thanks.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon Jul 10, 2006 12:25 pm

I tried setting all the memory from $0000-$07FF to either $00 or $FF at reset.
Post the code you use to do this, in case it doesn't actually do this.

User avatar
Lloyd Gordon
Posts: 150
Joined: Mon Nov 07, 2005 11:32 am
Location: Toronto
Contact:

Ahhhhhhh!

Post by Lloyd Gordon » Mon Jul 10, 2006 3:08 pm

I was playing around with the code and thinking about what everybody was saying and your advice finally sank in! Sorry if I seemed out of it. I realized that I was just assuming the NES memory would be $00 after a hard reset when of course I had absolutely no reason to expect that. In fact as was pointed out to me, the memory seems to be mainly set to $FF on power-on. It looks like Nestopia uses $FF to fill up memory. Anyway, I learned a valuable lesson: never assume a memory location contains a certain value unless I've initialized it to that value. Thanks to everyone for helping me out. Now I can use Nestopia's very helpful NTSC filter. Unlike most of you guys, I mispent my youth with my nose more or less to the grindstone when I should have been writing assembler. Now I have to catch up with the disadvantage of (a lot?) fewer neurons.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon Jul 10, 2006 4:28 pm

By the way, how do you like Nestopia's NTSC filter?



(just kidding)

tepples
Posts: 22277
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jul 10, 2006 4:55 pm

Quietust wrote:The "proper" method would be to start with RAM initialized to completely random data, but that would cause significant other problems for emulators that want to support movie recording (as it would require always storing the randomized-uninitialized memory in the movie file).
Don't all movie files come with a saved state anyway? Wouldn't the RAM fill data be part of the saved state of RAM?

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Mon Jul 10, 2006 5:09 pm

tepples wrote:Don't all movie files come with a saved state anyway?
Not when they're recorded from reset.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Mon Jul 10, 2006 6:49 pm

Thread split in progress!

I think it's a good idea to at least have an option to save the reset state at the beginning of a movie, since it offers some protection in case you ever change reset behavior of your emulator, or try to play the movie on another emulator. Emulators apparently vary widely in how they initialize memory at power-up. If you use any kind of compression on the movie, the initial state should compress to practically nothing (unless you're initializing RAM to random values).

Post Reply