Simply trying to write 1 individual tile. Getting screen fluctuation everytime the 1 tile is drawn.
Code:
LDX $#00
LDA $2002
LDA #$23
STA $2006
;determine low byte vram address to load/write
TYA
PHA
LDY #$00
LDA $A443,Y
CMP $B7
BEQ $A473
INY
CMP #$09
BNE $A467
LDA $A44B,Y
STA $2006
;determine tile to load/write
LDY $B8
LDA $A49C,Y
STA $2007
LDA $FF
AND #$FB
STA $2000
LDA #$00
STA $2005
STA $2005
PLA
TAY
RTS
If display is enabled, you can only usefully write to $2007 during the 20 scanlines after NMI. If the game is already using all that time up, you'll have to rewrite their code to be faster.
If this wholly original code, you'll have to wait for an NMI before you write to $2007.
Crud, snapped the debugger where my routine begins, scanline says it's at 21. But the routine I have, is that the correct order?
Yeah, basically.
It's usually better to precalculate things so that you aren't spending precious vblanking time doing arithmetic instead of uploading data.
Well I tried initiating this code earlier to where when my debugger snaps, it says the Scanline is at 19, and when I initiate the code I still get the screen fluctuation?
You're not restoring whatever scroll the game expects, if it doesn't expect zero.
Or maybe by only moving your code earlier, you make their code run too late, and it can't set the correct scroll value before it runs out of time.
Ok really weird, I went somewhere where the scanline was around 241, (was sniffing around a vram buffer in the game I wasnt utilizing for what I'm doing) and I sub routined my code there, and now it works.
I've always been flakey with the NES timings, ugh.
Which emulator are you using? I think that in FCEUX, it stays stuck in scanline 241 all throughout vblank (which lasts roughly 20 scanlines in NTSC), which is when you're allowed to access vram, so that sounds correct.
Yup its FCEUX, and that explains it cause it's running perfect.