I'm trying Nestopia because I like the NTSC filter. However on Nestopia my second moving character doesn't show up even though it does on FCEUD and Nintendulator. I'm using a 0 mapper with the 8 X 16 sprites. Any ideas?
It would be useful to know what program you're trying to run...
I think he means on his own program.
Sounds strange. If it works on Nintendulator, it's probably ok on the NES. No way to be sure though without testing (I trust it for testing my PAL code timing though, hasn't failed me yet). Are you using Sprite-DMA?
I've got my dev system hooked up now if you want a test.
Sorry, I'm running my own code, a sidescrolling game. It's pretty simple so far. There are only 2 "characters", the one that the user moves and one enemy. It's the enemy that doesn't show up at all on Nestopia although it does on FCEUD and Nintendulator. The "enemy" movement seems more accurate on FCEUD for some reason. I only use sprite DMA which I update on every VBlank. The NTSC filter is really good on Nestopia as it shows how bad my artwork would look on the console on a real tv. It's sort of weird how Nestopia doesn't show the second character at all. Any help would be appreciated. I could email the .nes file. I still have problems with NTSC weird colour effects, which I think are due to palette choices and graphic detail.
Are you sure you don't have more than 8 sprites per line ?
Are you sure you have proper sprite name table select via $2000 at the end of VBlank ?
I've got an NROM (actually CNROM) RAM cartridge, if you'd like to see how the program behaves on a "real NES" (as opposed to Nestopia) - email me a copy of the ROM image (via GMail; the account name is the same as I'm using here) and I'll test it tonight.
Bregalad wrote:
Are you sure you don't have more than 8 sprites per line ?
Are you sure you have proper sprite name table select via $2000 at the end of VBlank ?
Either of those would have definitely caused problems in Nintendulator as well, so it must be something else.
Bregalad:
I'm only using two characters each using 2 8x16 sprites. All the other sprites are hidden with a Vertical position of $F7 until I need them. So the 8 sprite per line limit shouldn't matter. Nestopia can turn off that limit and it doesn't change anything.
I'm not sure what sprite nametable select means. I select the proper nametable address via $2006 at the end of VBlank. I set up $2000 and $2001 only when I need to change something . I don't change $2000 routinely in VBlank and I only set $2000 D3, the Sprite Pattern Table Address, near the beginning of the program. I thought the NES ignores D3 of $2000 if D5 was set to 1 for 8 x 16 sprites. If I'm confused or missing something, please let me know.
Quietust :
I'll send you the .nes file on Gmail.
Thanks.
Does it work in Nestopia if you take six cycles to lda #0 sta
OAMADDR before each write to OAM_DMA ($4014)?
Tepples:
NMI: pha ;Non-maskable interupt
txa ;store a,x,y
pha
tya
pha
lda #$00
sta $2003 ;initialize spram pointer
lda #$02 ;must update spram in Vblank
sta $4014 ;DMA sprite transfer
This is the beginning of my NMI code. Is this what you mean?
I've just tested it on my CopyNES and it works fine - both characters (one being a square guy with arms and legs, the other looking like a blue cloud) are fully visible and appear to move around normally.
I suspect the problem may be related to uninitialized memory.
You're copying page $0200 to OAM correctly, but what are you writing into each byte of $0200-$02FF?
You're copying page $0200 to OAM correctly, but what are you writing into each byte of $0200-$02FF?
Right now, I'm just using 4 8 x 16 sprites to make two 16 x 16 characters so I'm updating the first 16 bytes of $0200-$02FF in non-NMI to keep track of the vertical & horizontal positions, tile numbers, & sprite attributes.
The second 16 x 16 character shows up correctly on FCEUD and Nintendulator but not at all on Nestopia. I'd like to amend my code so all the sprite graphics show up on Nestopia so I can optimize the palette choices for NTSC.
Quietust:
Thanks for taking the time to run it. Now if only I could figure out how to get my sprites to show up properly on Nestopia. If my code works on the NES and not Nestopia does this mean this behaviour is caused by a bug in Nestopia?
Thanks everybody for the help.
Have you tried it on my
latest build, released yesterday?
If you have and it still doesn't work, could you send me your ROM image so I can have a look at it? martin-freij at home . se
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.
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.
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.
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?
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.
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?
Quote:
What exactly is the proper way to emulate uninitialized memory?
blargg has tested that about a year ago, it's filled with $FF.
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).
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.
Quote:
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.
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.
By the way, how do you like Nestopia's NTSC filter?
(just kidding)
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?
tepples wrote:
Don't all movie files come with a saved state anyway?
Not when they're recorded from reset.
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).