Metatiles appearing differently in emulators and on hardware

[Sogona]

As an exercise, I've been trying to make a 15 slider puzzle (One of these). It looks fine in FCEUX, the metatiles won't display at all in Nestopia, and for whatever reason on the Powerpak, only the first row won't display.

Emulators:

Powerpak:

I'm aware that there can be differences between emulators and an actual NES, but I've used this metatile decompressing routine before in multiple projects, and they've all worked fine when I tested them on real hardware. So do you think this is an issue with my code? I can post the routine if it's necessary, all it is is this.

[thefox]

Definitely an issue with the code, but hard to say much without the ROM.

[Sogona]

Shit, okay. I'll look it over tomorrow.

[Memblers]

When it comes to strange compatibility issues, using uninitialized RAM is the most common cause.

[thefox]

Yeah. You can use NDX (http://kkfos.aspekt.fi/projects/nes/too ... dulatordx/) to get some idea if uninitialized RAM access might be the cause. It has an option (Debug -> Debug Extensions -> Randomize Memory) for randomizing all RAM contents (so you should get different results on different power ups), and it will also warn if memory is read before being written to.

[rainwarrior]

When it comes to strange compatibility issues, using uninitialized RAM is the most common cause.

I think the second most common cause is trying to send data to the PPU (i.e. $2007 or OAM DMA) outside of the vblank window.

[Sogona]

I think the second most common cause is trying to send data to the PPU (i.e. $2007 or OAM DMA) outside of the vblank window.

All I've done is bulk drawing so far.

When it comes to strange compatibility issues, using uninitialized RAM is the most common cause.

Turns out it was, not the RAM, but the attribute tables that I forgot to initialize. How I didn't catch that before is beyond me. Always the simplest mistakes that cause the most headaches.

Anyways, all is working now

[tepples]

Errors of not initializing the attribute tables can be avoided in two ways. One way is to always initialize the whole palette, so that wrong attributes appear as wrong colors instead of invisible graphics. The other way is to have the screen clearing routine in your library take an attribute value as an argument. Here's the routine from my own library:

Code: Select all

;;
; Clears a nametable to a given tile number and attribute value.
; (Turn off rendering in PPUMASK and set the VRAM address increment
; to 1 in PPUCTRL first.)
; @param A tile number
; @param X base address of nametable ($20, $24, $28, or $2C)
; @param Y attribute value ($00, $55, $AA, or $FF)
.proc ppu_clear_nt

  ; Set base PPU address to XX00
  stx PPUADDR
  ldx #$00
  stx PPUADDR

  ; Clear the 960 spaces of the main part of the nametable,
  ; using a 4 times unrolled loop
  ldx #960/4
loop1:
  sta PPUDATA
  sta PPUDATA
  sta PPUDATA
  sta PPUDATA
  dex
  bne loop1

  ; Clear the 64 entries of the attribute table
  ldx #64
loop2:
  sty PPUDATA
  dex
  bne loop2
  rts
.endproc