The emulator panics a fair amount at the moment, and will continue to do so until all the bugs in CPU/PPU emulation are ironed out.

Ideally, whenever a panic occurs, I want to know the following information:

• [ ] What was the last instruction successfully fetched and executed?
• [ ] What was the value of the program counter at the time of panic?
• [ ] What were the stack contents?
• [ ] Which scanline and tick was the PPU trying to process?

At the moment, some of this information is produced when a panic occurs in the CPU, but nowhere else. The library needs to be rewritten so that Result<T, E> are returned by functions instead of those functions themselves panicking.

Tracking issue for sprites + OAM emulation in the PPU. This is the final step necessary to get playable games with basic mappers such as Mario Bros. and Donkey Kong.

New data structures in PPU.

• pOAM (primary OAM) (holds 64 sprites for the entire frame)
• sOAM (secondary OAM) (holds 8 sprites for the current scanline)
• 16 (2x8) 8-bit shift registers - pattern data for up to 8 sprites on current scanline.
• 8 latches - Attribute data for 8 sprites.
• 8 counters - X positions for 8 sprites.

Sprite Evaluation

"Translated" from nesdev

• [x] Cycles 1-64: Clear secondary OAM full of $FF's.
• [ ] Cycles 65-256: Odd cycles: Fetch data (i.e. OAM[n][m]) from pOAM. Even cycles: Write to sOAM iff sOAM not full, else read from sOAM.
  1. For each n = 0..=63, copy pOAM[n][0] (y-coordinate) into next open slot in sOAM, according to alternating rules above. If y-coordinate in range of interest (qualify?) copy pOAM[n][1..=3] into remainder of slot.
  2. Increment n n has overflowed? All sprites in pOAM evaluated, go to (iv). Fewer than 8 sprites have been found/copied, go to (i). If 8 sprites have been found, disable writes to sOAM (as desc. above).
  3. Start at m = 0, evaluate every OAM[n][m] as a y-coordinate (seems a little strange... but OK) If the value is in scanline range, set sprite overflow flag in $2002 and read rest of slot. Handle m overflow into n (when m is 3, n++, m = 0) If not in range for scanline, increment n and m. If n overflows, go to (iv), otherwise go to (iii).
  4. Increment n until HBLANK is reached.
• [ ] Cycles 257-320: Sprite fetches (8 sprites, 8 cycles per sprite) 1-4: Read the Y-coordinate, tile number, attributes and X-coordinate of the selected sprite from sOAM. 5-8: Read the X-coordinate 4 more times, while the PPU fetches sprite data. (Maybe emulator can do nothing here?) Useful note: First empty sprite slot will consist of last sprite (63)'s y-coordinate followed by [0xFF; 3]. Then others will be [0xFF; 4].
• [ ] Cycles 321-340+0: Fetching the first byte in the secondary OAM needs to align with PPU fetches of next two background tiles for next scanline.

Sprite Rendering - TODO

Notes

I haven't given much thought to 8x16 sprites. Start with just 8x8 sprite support for now. Important for evaluation of byte 1 of sprite data in OAM.