One problem I'm encountering right now is my v register is corrupted because the PPUMASK background rendering flag is turned on in the visible scanlines.
Here's what I captured from my log, the left bracket indicates the current scanline.
Code: Select all
...
[030] Write $2007 0x00 at 0x23F6
[030] Write $2007 0x00 at 0x23F7
[030] Write $2007 0x00 at 0x23F8
[030] Write $2007 0x00 at 0x23F9
[030] Write $2007 0x00 at 0x23FA
[030] Write $2007 0x00 at 0x23FB
[030] Write $2007 0x00 at 0x23FC
[030] Write $2007 0x00 at 0x23FD
[030] Write $2007 0x00 at 0x23FE
[031] Write $2007 0x00 at 0x23FF
[031] Write $2001: 0b00001010
[031] Write $2006: 0x3F
[031] Write $2006: 0x00
[031] Write $2007 0x0F at 0x3F00
[032] Write $2007 0x30 at 0x4F00
CRASH
My current rendering approach is by using scanline based rendering, where after each 341 PPU cycles passed, I fill my internal picture buffer in the current scanline roughly like this. I've also accounted for OAMDMA cycles but don't include it in the below example for the sake of simplicity.
Code: Select all
loop {
let cycles = cpu.step() * 3; // number of ppu cycles executed in this cpu instruction
if current_cycle + cycles >= 341 {
fill_current_scanline_to_temp_buffer();
current_scanline++;
current_cycle = (current_cycle + cycles) % 341;
} else {
current_cycle += cycles;
}
}
Question:
1. Am I going in the right direction in guessing that cycle accuracy is the problem?
2. If yes, what should I do about this? Should I just go with cycle based rendering instead? This is the slowest rendering technique but looks simpler than the other approaches.