This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Metatiles appearing differently in emulators and on hardware

Metatiles appearing differently in emulators and on hardware
by on (#154330)
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:
Attachment:
sdfsdf.png
sdfsdf.png [ 64.34 KiB | Viewed 2074 times ]

Powerpak:
Attachment:
20150829_225215.jpg
20150829_225215.jpg [ 64.71 KiB | Viewed 2074 times ]


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.
Re: Metatiles appearing differently in emulators and on hard
by on (#154331)
Definitely an issue with the code, but hard to say much without the ROM.
Re: Metatiles appearing differently in emulators and on hard
by on (#154332)
Shit, okay. I'll look it over tomorrow.
Re: Metatiles appearing differently in emulators and on hard
by on (#154335)
When it comes to strange compatibility issues, using uninitialized RAM is the most common cause.
Re: Metatiles appearing differently in emulators and on hard
by on (#154339)
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.
Re: Metatiles appearing differently in emulators and on hard
by on (#154343)
Memblers wrote:
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.
Re: Metatiles appearing differently in emulators and on hard
by on (#154347)
rainwarrior wrote:
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.

Memblers wrote:
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
Re: Metatiles appearing differently in emulators and on hard
by on (#154348)
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:
;;
; 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