Micro Machines: Background palette glitch

Micro Machines: Background palette glitch
by dawid9554 on 2019-04-02 (#236941)

Hello, NesDev!

You may probably remember me from another post where I was describing my earlier problem with a glitchy SMB title screen.
I'm here again to describe another problem I'm struggling with.

A couple of weeks ago I finished a major part of my work on Nesgaro, my own portable emulator for Windows. I tested some games, including some of these listed on the Tricky-to-emulate games list and they worked very well without noticeable glitches... until I started testing Micro Machines.
I noticed a few visual glitches such as incorrect background palette display (no black color in pictures on title screen), the background at the select screen is brighter than it supposed to be and the bars are black but not gray with black edges. Anything else beside these works OK.

I'm including a few screenshots of my emulator and another emulator, Mesen, that doesn't have glitches mentioned above for comparision:

Thanks in advance for any help ^_^

Re: Micro Machines: Background palette glitch
by freem on 2019-04-02 (#236942)

The linked wiki page states:

Quote:

[Micro Machines] also relies on proper background color selection when rendering is disabled and the VRAM address points to the palette

The "background palette hack" mentioned: https://wiki.nesdev.com/w/index.php/PPU ... lette_hack

Quote:

If the current VRAM address points in the range $3F00-$3FFF during forced blanking, the color indicated by this palette location will be shown on screen instead of the backdrop color. ... This can be used to display colors from the normally unused $3F04/$3F08/$3F0C palette locations.

If I had to guess, Micro Machines probably uses this for the black color and character select background. (I haven't looked into it, though, so I may be wrong.)

Re: Micro Machines: Background palette glitch
by rainwarrior on 2019-04-02 (#236943)

Your screenshots look like correct emulation for a Famicom, but not an NES.

Micro Machines relies on a behaviour not available on the Famicom, reading $2004 as a way to synchronize with a scanline:
Wiki description

If you're comparing against Mesen there's actually an option to disable that under Options > Emulation > Advanced.

Re: Micro Machines: Background palette glitch
by dawid9554 on 2019-04-02 (#236944)

rainwarrior wrote:

Micro Machines relies on a behaviour not available on the Famicom, reading $2004 as a way to synchronize with a scanline

The thing is I have OAMDATA reading and writing implemented as provided on the Wiki page you sent the linkage to and here as well. Otherwise the screen at character select would be shaking.

$2004 Read

Code:

case OAM_DATA: {   //Read $2004 R W

   if (scanline >= 0 && scanline <= 239 && renderingEnabled()) {
      if (dot < 64) return 0xff;
      if (dot < 256) return 0x00;
      if (dot < 320) return 0xff;
      return OAM2[0]; 
   } else { 
      return MEM::OAM[OAMV];
   }
}

$2004 Write

Code:

case OAM_DATA: {   //Write $2004 W R
   if (!(scanline >= -1 && scanline <= 239 && renderingEnabled())){
      MEM::OAM[OAMV++] = value;
   }
   break;
}

Re: Micro Machines: Background palette glitch
by Sour on 2019-04-02 (#236945)

Mesen has an option to disable $2004 reads, which produces essentially the same problem as your screenshots.
$2004 reads during rendering are more complex than the code you posted. They return a value that's based on what sprite evaluation is currently doing (e.g the contents of the read buffer that stores the value from oam ram before copying it to secondary oam), at least, as far as I remember.

Edit: I only just now realized rainwarrior had already mentioned the option, whoops!

Re: Micro Machines: Background palette glitch
by rainwarrior on 2019-04-02 (#236946)

Also, the palettes might be an unrelated issue. Are you doing anything special with colour $0D? This game uses that out-of-spec too-black colour that most other games do not.

Alternatively I think it makes some writes to palette at unusual times during the frame, or possibly you aren't mirroring the background colour correctly? e.g. Writing to $3F10 will set $3F00... but I notice there is supposed to be a blue like what is in your screenshot at $3F0C. Are you incorrectly mirroring $3F0C (or $3F1C) to $3F00, instead of having 3 "extra" hidden colours at $3F04, $3F08, $3F0C?

Re: Micro Machines: Background palette glitch
by dawid9554 on 2019-04-02 (#236947)

rainwarrior wrote:

Are you incorrectly mirroring $3F0C (or $3F1C) to $3F00, instead of having 3 "extra" hidden colours at $3F04, $3F08, $3F0C?

I have mirrored $3F14, $3F18 and $3F1C to $3F04, $3F08 and $3F0C so I have these 3 additional hidden colors, they aren't mirrors of $3F00.

rainwarrior wrote:

Writing to $3F10 will set $3F00

This one is mirrored as well.

rainwarrior wrote:

Are you doing anything special with colour $0D? This game uses that out-of-spec too-black colour that most other games do not.

I'm not doing anything special with this color. Should I do something with it? I don't quite understand what's the matter with this color.

Re: Micro Machines: Background palette glitch
by dawid9554 on 2019-04-02 (#236951)

A little update. I noticed something weird when I was inspecting the event viewer on Mesen emulator.
On scanline 107 at cycles from around 269 to 340 these things happen in order:

Write $84 to $2000
1st write $3F to $2006
2nd write $0F to $2006
Write $00 to $2001
Write $11 to $2007

But what really happened is that the color at $3F00 had been overwritten instead of $3F0F. I don't understand what actually happened there..

Re: Micro Machines: Background palette glitch
by rainwarrior on 2019-04-02 (#236953)

dawid9554 wrote:

rainwarrior wrote:

Are you doing anything special with colour $0D? This game uses that out-of-spec too-black colour that most other games do not.

I'm not doing anything special with this color. Should I do something with it? I don't quite understand what's the matter with this color.

Well, there's not much the matter with it for emulators, just another palette entry. For NTSC hardware, it generates a voltage that's lower than it should be and can cause the picture to desynchronize (depends on the TV, this response varies a lot). Most games don't use it.

I was only asking because in your screenshots it was a $0D black that was being replaced by that blue colour. Was wondering if it was due to an unusual interpretation of $0D's "special" property, but sounds like this is not the case.