It is currently Wed May 22, 2019 3:44 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Tue Apr 02, 2019 11:51 am 
Offline
User avatar

Joined: Sun Mar 17, 2019 10:15 am
Posts: 11
Location: Poland
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:

Image
Image
Image
Image

Thanks in advance for any help ^_^


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 12:13 pm 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 161
Location: freemland (NTSC-U)
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.)


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 12:29 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7461
Location: Canada
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.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 1:09 pm 
Offline
User avatar

Joined: Sun Mar 17, 2019 10:15 am
Posts: 11
Location: Poland
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;
}


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 1:32 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
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!


Last edited by Sour on Tue Apr 02, 2019 2:00 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 1:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7461
Location: Canada
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?


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 1:49 pm 
Offline
User avatar

Joined: Sun Mar 17, 2019 10:15 am
Posts: 11
Location: Poland
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.


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 2:25 pm 
Offline
User avatar

Joined: Sun Mar 17, 2019 10:15 am
Posts: 11
Location: Poland
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..


Top
 Profile  
 
PostPosted: Tue Apr 02, 2019 2:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7461
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group