[FIXED] Nametable issue

[VGdevOnSNES]

i made a code to write a "Hello, world!" message on the Nametable.

for some reason, when the PPU address reaches $207A, it jumps back to $2000 and writes over the characters i've already written.

if you want to see the code, here it is:

Code: Select all

Load_page1_message_loop:
  LDA PAGE1_MESSAGE,X
  STA PPU_DATA                   ; Write to PPU
  INX                            ; Increment cursor (X) by 1
  CPX #$00                       ; When X = $00, ignore branch
  BNE Load_page1_message_loop ; Branch until compare = 0

[tepples]

Have you enabled NMI? If so, what does your NMI handler look like?

[VGdevOnSNES]

Have you enabled NMI? If so, what does your NMI handler look like?

After verifying, it has nothing to do with NMI.
I know that because even with NMI enabled, when PPU jumps from $207A to $2000, the CPU isn't interrupted.
I use a RTI instruction so when it executes NMI, it does nothing.
But when the PPU does what is my problem, the CPU doesn't jump to my placeholder RTI.

[Quietust]

i made a code to write a "Hello, world!" message on the Nametable.

for some reason, when the PPU address reaches $207A, it jumps back to $2000 and writes over the characters i've already written.

if you want to see the code, here it is:

Code: Select all

Load_page1_message_loop:
  LDA PAGE1_MESSAGE,X
  STA PPU_DATA                   ; Write to PPU
  INX                            ; Increment cursor (X) by 1
  CPX #$00                       ; When X = $00, ignore branch
  BNE Load_page1_message_loop ; Branch until compare = 0

What emulator are you using to test your program? Does it have a debugger? If so, what exactly is happening when your code is running?

[VGdevOnSNES]

i made a code to write a "Hello, world!" message on the Nametable.

for some reason, when the PPU address reaches $207A, it jumps back to $2000 and writes over the characters i've already written.

if you want to see the code, here it is:

Code: Select all

Load_page1_message_loop:
  LDA PAGE1_MESSAGE,X
  STA PPU_DATA                   ; Write to PPU
  INX                            ; Increment cursor (X) by 1
  CPX #$00                       ; When X = $00, ignore branch
  BNE Load_page1_message_loop ; Branch until compare = 0

What emulator are you using to test your program? Does it have a debugger? If so, what exactly is happening when your code is running?

I use FCEUX, and what it does when running the program is (what it's supposed to do) writing on PPU addresses $2000-$20FF, but for some reason, when it reaches $207A, it jumps back to $2000 and writes over my characters i've already written.

NMI is enabled, but it does nothing except incrementing a VBlank counter and executing a RTI instruction.

So, when PPU_ADDRESS reaches $207A, it jumps back to $2000 and writes over my characters already written. After looking in debugger, it does nothing else than executing my code, and no NMI occurs.

I hope i brought enough info.

[Quietust]

I use FCEUX, and what it does when running the program is (what it's supposed to do) writing on PPU addresses $2000-$20FF, but for some reason, when it reaches $207A, it jumps back to $2000 and writes over my characters i've already written.

NMI is enabled, but it does nothing except incrementing a VBlank counter and executing a RTI instruction.

So, when PPU_ADDRESS reaches $207A, it jumps back to $2000 and writes over my characters already written. After looking in debugger, it does nothing else than executing my code, and no NMI occurs.

I hope i brought enough info.

At what point in time (i.e. which scanline) does your "Load_page1_message_loop" code start executing, and when does it finish running? Does your code turn off rendering (e.g. by writing #$00 to $2001) before trying to copy your message into VRAM?

Honestly, it would be lot more helpful if you posted your entire program rather than just a tiny code snippet.

[VGdevOnSNES]

I use FCEUX, and what it does when running the program is (what it's supposed to do) writing on PPU addresses $2000-$20FF, but for some reason, when it reaches $207A, it jumps back to $2000 and writes over my characters i've already written.

NMI is enabled, but it does nothing except incrementing a VBlank counter and executing a RTI instruction.

So, when PPU_ADDRESS reaches $207A, it jumps back to $2000 and writes over my characters already written. After looking in debugger, it does nothing else than executing my code, and no NMI occurs.

I hope i brought enough info.

At what point in time (i.e. which scanline) does your "Load_page1_message_loop" code start executing, and when does it finish running? Does your code turn off rendering (e.g. by writing #$00 to $2001) before trying to copy your message into VRAM?

Honestly, it would be lot more helpful if you posted your entire program rather than just a tiny code snippet.

After looking for the problem, i managed to fix it.

[Quietust]

After looking for the problem, i managed to fix it.

Could you go into more detail? Other people might run into similar problems in the future and want to know how to fix the problem, and finding a thread that just ends with "I fixed it" tends to be frustrating.

[VGdevOnSNES]

After looking for the problem, i managed to fix it.

Could you go into more detail? Other people might run into similar problems in the future and want to know how to fix the problem, and finding a thread that just ends with "I fixed it" tends to be frustrating.

Well, let's say you want to load characters to the nametable;

Code: Select all

PPU_ADDRESS_DEFINE:
  LDA #%00000110 ; <-------
  STA PPU_MASK
  LDA #$20
  STA PPU_ADDRESS
  LDA #$00
  STA PPU_ADDRESS
  LDX #$00
LOAD_PAGE1_DATA:
  LDA PAGE1,X
  STA PPU_DATA
  INX
  CPX #$00
  BEQ LOAD_PAGE2_DATA
  JMP LOAD_PAGE1_DATA
LOAD_PAGE2_DATA:
  LDA PAGE2,X
.....
  CPX #$C0
  BEQ FINISH_DATA_LOAD
  JMP LOAD_PAGE4_DATA
FINISH_DATA_LOAD:
  LDA #%00011110 <-------
  STA PPU_MASK
  LDA #$00
  STA PPU_SCROLL
  STA PPU_SCROLL

This code should help.
The dots are repetition of the code but it loads pages 2,3 and 4. (1 PAGE =/= 1 NAMETABLE)

[Quietust]

So, in summary, the problem was that you were trying to write to VRAM while rendering was enabled and your code was taking longer than 1 VBLANK to run, and you fixed it by turning off rendering beforehand.