Solving NEStress errors

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Solving NEStress errors
by on (#71965)
I'll get down to brass tax here, my emulator sucks and I was thinking about abandoning its development in favour of another emulator I'm working on. However, I feel that the very least I can do is get it to a reasonably decent standard, and since I got Blargs CPU test (nestest.nes) working 100%, I want to get Blargs PPU tests (NEStress.nes) working to the same standard.

Here's the current state of the PPU test results from NEStress.nes

Image

It's really bad, and so many games clearly suffer as a result of it. I have to sort this out, I would would really appreciate your help.

I feel like I have implemented everything I need to get all the basic PPU reads and writes working correctly, here's a list of a few things which I think I have implemented correctly (or not as the case IS) to get these tests passing.
    *the first write/second write flip-flop is shared between $2005/6.

    *reading $2002 resets this flip-flop

    *first read from $2007 is always invalid, so one "junk" read must be made before reading from $2007. The first read does not increment the vram pointer.

    *this invalid read only occures after a PPU reguster is written to, all contiguous reads of $2007 do not suffer from any "inavlid reads" (other than the first of course).

    *the vram pointer wraps around 14 bits

    *$2000 - $2007 are mirrored all the way to $3FFF (1023 times!). Every write or read from here is treated the same as it would be for $2000 - $2007. i.e. writing to $2008 would change $2000 and visa versa. (I haven't emulated this yet as very few games actually write to this address space)

    *I have implemented pallete mirroring correctly (or atleast, i think), same with nametable mirroring.


Have I missed any important details?

Thanks

by on (#71966)
I just peeked at the code for Nestopia. This is how it does the 2007 reads.

Whenever you do ANY write to the PPU area (2000-2007 and mirrors, including OAM DMA transfers), you set "latch" to the last value written.
Whenever you read any valid readable register, you set "latch" to the last value that was read.
When you read anything that is not normally readable, you instead get the value of "latch".
When you read 2007, you receive the value of "latch", then it reads a byte from PPU memory (incrementing the address as usual), and stores it into "latch".

by on (#71967)
Cheers Dwedit, that's helpful, I was unsure about how the latched value works exactly.

I just thought, since my emulator fails every sprite test in NEStress, it might be a good idea to mention those too.

First of all, can anyone tell me what might be the cause of sprites not showing or flickering during many games? For example, in Super Mario Bros, Mario doesn't appear, although in games like Megaman, Megaman does appear but he flickers. I have heard that SMB relies on accurate Sprite 0 hit emulation, would this still have such a big impact if it wasn't emulated correctly?

Sorry for the awkward question and change of subject, but it's all in the same boat, my awful PPU emulation haha.

by on (#71997)
aphex wrote:
Sorry for the awkward question and change of subject, but it's all in the same boat, my awful PPU emulation haha.


If you stop SMB with a debugger is it looping on reads of $2002? If so then it's either looking for sprite 0 hit ($40) or VBLANK ($80) set.

If sprite 0 hit isn't working correctly SMB usually sits at the title screen without toggling the coin/?-box colors and without mario at the bottom left.

by on (#72008)
NESICIDE wrote:
aphex wrote:
Sorry for the awkward question and change of subject, but it's all in the same boat, my awful PPU emulation haha.


If you stop SMB with a debugger is it looping on reads of $2002? If so then it's either looking for sprite 0 hit ($40) or VBLANK ($80) set.

If sprite 0 hit isn't working correctly SMB usually sits at the title screen without toggling the coin/?-box colors and without mario at the bottom left.


Funny thing is that the game actually runs and starts when I press "start", but mario just isn't there. Also, pressing right or left does not scroll as you might expect, even though scrolling is working reasonably well is other games and is implemented well enough to work in SMB, i'm sure.

I think I have the frame basics working well, so I don't think VBLANK is the problem, I think it's something specific to sprites that just isn't working correctly. Sometimes, I have some issues with other games, like Hydlide if it is the first game I run after the emulator has started, the sprites are all over the place, but if I play another game first, it's fine. I'm sure I have my sprite DMA working fine, same with my read/writes through port $2004 to sprite ram.

Another quick point that may be relevent, when mario starts, if I jump, I can sort of see mario appearing to the far left.

I will of course continue to debug but if anyone has any suggestions I'd be very greatful, thanks.

by on (#75152)
I have fixed many erros since I posted this thread, games like Super mario now work almost flawlessly (graphics wise). The main problem that was causing this was the SBC instruction, in which I was not calculating the borrow correctly.

I have also renamed my "Nes emu" to something more interesting, introducing FooNES. I would be greatful if someone could update my place in the list of emulators currently being developed, http://wiki.nesdev.com/w/index.php/Emulators, as I am not a "trusted user" yet.



Image

by on (#75156)
Do you have a download available? I'll try your emu with my homebrew game. I notice in your screen-shot that you have a "debug" menu. I'm curious what debug features you have.

by on (#75161)
clueless wrote:
Do you have a download available? I'll try your emu with my homebrew game. I notice in your screen-shot that you have a "debug" menu. I'm curious what debug features you have.


The debug menu just contains a memory viewer whereyou can view the CPU and PPU memory, which looks like this.

http://img853.imageshack.us/img853/8533/10975348.png

And a half finished, half assed debugger which just lets you step through opcodes. I have never really bothered to finish it really, laziness on my part. Don't bother with it, it doesn't work.

http://img402.imageshack.us/img402/7793/85517916.png

You can try it out if you want, but bare in mind the following.

Vertical scolling isn't implemented properly, so don't expect games that use it to work correctly.

Only mappers that are supported are 1, 2, and (partially) 11 (and 0 of course).

APU emulation is basically non existent, but i'm working on it, so i'm disabling it in this case.

Some menu items don't work, as i'm providing this "as is". For example, the "Open rom viewer", which is very very alpha right now. Won't work for you at all.

8x16 sprites arn't supported yet, so if a game is missing sprites (Castlevania, Zelda etc), then that's probably why.


You can enable full screen by pressing F1, or choosing it from the video menu, you can also save a save state by pressing F4, and restore it using F5, you can also cycle through 9 different palette's using F2, if you want details on what they are, I'll be happy to provide info.

One last thing, remember that this is a work in progress and I know it sucks right now, but It can only get better.

Exe download, compiled in Visual C++ 2010 as release (reason for its large size).
http://www.mediafire.com/?xabkiqmt2quk4uf

As for the source code (if it was to come up), I'm not really happy with the way this emulator is written, it really needs a complete re-write. You see, it was the first emulator that I independently developed so the source could be improved greatly. hence, I think i will keep this closed source for now. However, I am developing a SNES emulator, which I plan to make open source if it ever gets that far.

by on (#75164)
No problem, aphex. I was just curious. I wish you luck in your endeavor. My game uses vertical scrolling. No big deal.

I know what its like to be embarrassed by code quality and not wanting to share it for fear of judgment.

by on (#75165)
Thanks clueless, no problem, I'm glad you understand.

by on (#75309)
So am I understanding that your emulator was able to pass nestest even though the SBC was broken?

Al