e.g. cpu_dummy_writes_oam.nes fails because we don't properly implement duplicate writes on LOAD/WRITE instructions

https://wiki.nesdev.com/w/index.php/APU_Mixer

Startup screen also shows the wrong tile in the top left.

Maybe an MMC1 mapper issue?

https://wiki.nesdev.com/w/index.php/APU_Sweep

I currently poll for interrupts before retrieving the opcode of instruction n+1. Technically this is incorrect, interrupt polling happens during the previous operation (perhaps cycle 2? perhaps penultimate cycle?). This will break some test roms (cpu_interrupts_v2 at least) and makes my cycle counts slightly offset to other accurate emulators.

Fixing perhaps requires better knowledge about which cycle I'm in during an operation. Maybe already have that via the addressing mode + instruction type?

Legend of Zelda uses 16 pixel high sprites and on the name selection screen Links sprites are reversed and upside down. That could be that the attribute byte is wrong but could equally be a misinterprtation of how to find the 16 pixel high bytes. Not confident by that code either

As an example, presumably something is being changed during the scanlines which are screwed up. Maybe rendering disable/enable? Maybe PPUSCROLL change mid scanline? Maybe changing vram addr midscanline with 2002 read/write?

https://wiki.nesdev.com/w/index.php/PPU_palettes#The_background_palette_hack

"If the current VRAM address points in the range $3F00-$3FFF during forced blanking, the color indicated by this palette location will be shown on screen instead of the backdrop color. (Looking at the relevant circuitry in Visual 2C02, this is an intentional feature of the PPU and not merely a side effect of how rendering works.) This can be used to display colors from the normally unused $3F04/$3F08/$3F0C palette locations. A loop that fills the palette will cause each color in turn to be shown on the screen, so to avoid horizontal rainbow bar glitches while loading the palette, wait for a real vertical blank first using an NMI technique."

I think this might be why the full_palette test doesn't display anything at the moment, I always use black as the background color

No investigation done yet

Given that this is the first of those tests which suggests that the 9th sprite is way after the 8th perhaps I'm missing something timing related with how the sprite eval machine works with sprites that are not getting copied to secondary OAM. Doesn't seem likely given the code though :/

c.f. ppu_open_bus.nes (we don't implement decay of bits at the time of writing)

Currently we load the attribute byte into an internal register on the right cycle but don't then move it into the attribute shift registers or correctly shift them. Unsure precisely how this works.

Instr Test v3 includes a BRK test which is failing, don't think I've tested that anywhere else so it's likely just egregiously bad

Very complex mapper described in detail here: https://wiki.nesdev.com/w/index.php/MMC5. Only actually used for ~15 games but does have some unique mapper tests for it

Result is #3 at the moment which the readme says means:
"3) Length should be clocked when halted at 14915"

Specifically the test is testing "Changes to length counter halt occur after clocking length, not before."

When in game of tetris we should be using bank 3 (CHR) on both banks. It seems like I'm using bank 0 accidentally.

Significant faster than 60fps, unclear why at the moment

Lots of the mapper tests are failing, likely because I'm not sure what to return for unmapped addresses

Sprite overflow isn't used much but there are some roms which rely on it. c.f. https://wiki.nesdev.com/w/index.php/Sprite_overflow_games for games which can be used to test the functionality

There's loads of potential issues with sprite rendering, various sprites will pick up the wrong colors, jump about the screen and generally just not appear correctly.

It's hard to find a single sprite that does render properly in fact. So most likely culprit is the sprite fetch pipeline looking at the wrong bytes for attribute/y/x

About the only thing that does mostly work is that the right tiles are being drawn (generally)

This covers a couple of test roms that do more thorough testing as well as a significant number of games

https://wiki.nesdev.com/w/index.php/APU_Envelope

Zelda hangs after pressing start or as it scrolls to the sprites

Probably something relating to interrupts since that's what I've changed most recently. Just need a cpu dump at the time to see what loop it's stuck waiting on

contrast to

Upper left of the image has a different tile, maybe sprite? Rendered

As per https://forums.nesdev.com/viewtopic.php?f=3&t=19005 garbage nametable reads take place during sprite fetch. These come from the page at 0x2000 on the CHR bus so drive A12 low. I don't see how A12 can remain high for the requisite number of cycles with these reads in place.

Disabling them in my emulator causes IRQ tests to pass, enabling them causes them to fail. That thread isn't sufficiently illuminating to me!

This is likely caused by misalignment of when we should increment the y scroll around the reads that happen during HBlanking. Should be simple enough to fix

I don't think that this is that hard given my current architecture.

Only game listed on https://wiki.nesdev.com/w/index.php/Tricky-to-emulate_games which relies on it is battletoads...which might well fail for any number of other reasons so isn't a great candidate.

Legend of Zelda apparently uses this in some way, maybe to split the scroll for the status bar?

Minor flicker with occasional pixels flickering on the right hand side of the screen

https://wiki.nesdev.com/w/index.php/APU_DMC

"Caesars Palace (USA).zip" hits an index out of bounds exception

index out of bounds: the len is 32 but the index is 32', src\ppu\sprites.rs:212:21

nestest log matches exactly to the one online but:

cargo run --release .\roms\test\blargg_nes_cpu_test5\official.nes

seems to error on basically all tests so presumably something is badly wrong

OAM RAM is supposed to decay when it's not being refreshed. Possibly just whilst rendering is off entirely?

For some reason the wrong buttons are being registered on button press. Specifically -> appears to be = somerthing else but down appears to work.

Failing with result #4

Test is checking "Write to length counter reload should be ignored when made during length
counter clocking and the length counter is not zero."

And #4 means 4) Reload during length clock when ctr = 0 should work normally

To me that looks like I'm starting to render the status window way too high up the screen, unclear what could cause that though. Question is how it decides when to start rendering it. Sprite zero hit? Sprite overflow? Cycle counting?

Game is mapper 3 so nothing interesting there