Trying to pass PPU read buffer tests

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Trying to pass PPU read buffer tests
by twicetimes on 2019-03-22 (#236431)
My emulator is starting to produce accurate looking games, but there's some graphical errors, so I'm trying to run the PPU-related tests from the test page on the wiki.

I'm getting the following results from the ppu read buffer tests:

Image

I'm not sure what to make of the "should I go on", when there's no failures before that point. Anyone who's run these tests before have any insight here?

Thanks.
Re: Trying to pass PPU read buffer tests
by twicetimes on 2019-03-23 (#236471)
Solved. The issue was not updating the PPUDATA read buffer correctly when reading from palette memory (0x3F00 - 0x3FFF)

The wiki says that

Quote:
Reading palette data from $3F00-$3FFF works differently. The palette data is placed immediately on the data bus, and hence no dummy read is required. Reading the palettes still updates the internal buffer though, but the data placed in it is the mirrored nametable data that would appear "underneath" the palette.


However, I couldn't find any info on exactly which address should be used to populate the read buffer in this scenario. From other emulators, it appears to be PPU_ADDR - 0x1000, but I can't really intuit why that is the case.
Re: Trying to pass PPU read buffer tests
by tepples on 2019-03-23 (#236475)
It's the case because the majority of the time (that is, on just about every board but GTROM), video memory $3000-$3FFF mirrors $2000-$2FFF. When PA13 is high ($2000-$3FFF), nothing is listening to PA12 (the line that distinguishes $0000-$0FFF from $1000-$1FFF and distinguishes $2000-$2FFF from $3000-$3FFF).
Re: Trying to pass PPU read buffer tests
by twicetimes on 2019-03-23 (#236483)
Makes sense, thanks.