Micro Machines glitches

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: Micro Machines glitches

Post by James »

Secondary
get nemulator
http://nemulator.com
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Micro Machines glitches

Post by Zepper »

Hmm... Guess I'm the only one to say... this code makes no difference running MM. :shock:
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Micro Machines glitches

Post by zeroone »

Zepper wrote:Hmm... Guess I'm the only one to say... this code makes no difference running MM. :shock:
Before:

Image

After:

Image
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Micro Machines glitches

Post by Sik »

Random question, but what operations is the game doing exactly once it hits the point it wants? (because don't forget you need to make sure that part is properly timed as well) And where is it getting the graphics for that line? Not like I know much about the NES inner workings but I wouldn't be surprised if it's expecting something to have a delayed side effect or something like that.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Micro Machines glitches

Post by zeroone »

Sik wrote:Random question, but what operations is the game doing exactly once it hits the point it wants? (because don't forget you need to make sure that part is properly timed as well) And where is it getting the graphics for that line? Not like I know much about the NES inner workings but I wouldn't be surprised if it's expecting something to have a delayed side effect or something like that.
The sprite 0 hit occurs toward the end of scanline 16. I experimented with advancing or delaying that signal. It offsets where the black line appears, but the line just wraps around the frame. It never vanishes into the hidden horizontal area.

When rendering is disabled (sprites and background is off) and V >= $3F00, it uses this color:

Code: Select all

palette[readVRAM(V) & 0x3F]
If I modify that code to return white instead of a palette entry, it produces this:

Image

That white bar stretches perfectly from the left side to the right side. The location of the black line is within that region. Meaning, the code disables rendering and then it alters the palette entry from blue to black and then back to blue.

Or, V advances to a palette entry that was set to black in that section.

I noticed that when V is divisible by 4, it produces blue. For instance, if I change the code to:

Code: Select all

palette[readVRAM(0x3F0C) & 0x3F]
Then, the black line disappears entirely. But, the subsequent menu screen is missing some graphics.

This might indicate that my V register is not update at the right moments in time.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: Micro Machines glitches

Post by James »

Are you accounting for palette mirroring and this, re: $3F04/$3F08/$3F0C?
wiki wrote: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. (Looking at the relevant circuitry in Visual 2C02, this is an intentional feature of the PPU and not merely a side effect of how rendering works.) This can be used to display colors from the normally unused $3F04/$3F08/$3F0C palette locations. A loop that fills the palette will cause each color in turn to be shown on the screen, so to avoid horizontal rainbow bar glitches while loading the palette, wait for a real vertical blank first using an NMI technique.
get nemulator
http://nemulator.com
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Micro Machines glitches

Post by zeroone »

James wrote:Are you accounting for palette mirroring and this, re: $3F04/$3F08/$3F0C?
Yes. Per the wiki:
Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. Note that this goes for writing as well as reading. A symptom of not having implemented this correctly in an emulator is the sky being black in Super Mario Bros., which writes the backdrop color through $3F10.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Micro Machines glitches

Post by tokumaru »

zeroone wrote:Yes. Per the wiki:
Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. Note that this goes for writing as well as reading. A symptom of not having implemented this correctly in an emulator is the sky being black in Super Mario Bros., which writes the backdrop color through $3F10.
What about the colors at $3F04, $3F08 and $3F0C? These were once believed to be mirrors of $3F00, but turns out they are individual memory locations, and the colors in these positions are only visible when rendering is off and the VRAM address is pointing at them.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Re: Micro Machines glitches

Post by James »

I can reproduce the black line issue by breaking writes to the palette. Specifically, by mirroring $3F00 writes to $3F04, $3F08, and $3F0C. Writes shouldn't be mirrored here, but reads from these locations while rendering should return the value at $3F00.
get nemulator
http://nemulator.com
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Micro Machines glitches

Post by Zepper »

The problem is that "piece of" line in dark blue.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Micro Machines glitches

Post by zeroone »

James wrote:I can reproduce the black line issue by breaking writes to the palette. Specifically, by mirroring $3F00 writes to $3F04, $3F08, and $3F0C. Writes shouldn't be mirrored here, but reads from these locations while rendering should return the value at $3F00.
Unfortunately, that did not the solve the problem for me. Is this read-only mirroring mentioned in the wiki? I don't recall reading about this before.

Thanks for your suggestions.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Micro Machines glitches

Post by Zepper »

@zeroone
Currently, what's the problem with Micro Machines? Just a recap.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: Micro Machines glitches

Post by zeroone »

Zepper wrote:@zeroone
Currently, what's the problem with Micro Machines? Just a recap.
On the title screen and on the player select screen, there are black lines in the middle-right and other minor distortions. The game itself seems to play correctly. Scroll through the images in this thread to see some of the slight improvements that have happened.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Micro Machines glitches

Post by Zepper »

Specifically, by mirroring $3F00 writes to $3F04, $3F08, and $3F0C. Writes shouldn't be mirrored here, but reads from these locations while rendering should return the value at $3F00.
Writing to $3F00 mirrors to locations 4/8/C, but writes to 4/8/C are NOT mirrored to $3F00..??? And reading from 4/8/C should return data at $3F00..?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Micro Machines glitches

Post by rainwarrior »

The Wiki article on [url=http://wiki.nesdev.com/w/index.php/PPU_palettes]PPU palettes[/url] wrote:Addresses $3F04/$3F08/$3F0C can contain unique data, though these values are not used by the PPU when normally rendering (since the pattern values that would otherwise select those cells select the backdrop color instead). They can still be shown using the background palette hack, explained below.

Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. Note that this goes for writing as well as reading. A symptom of not having implemented this correctly in an emulator is the sky being black in Super Mario Bros., which writes the backdrop color through $3F10.
I don't think there's any special case for reading vs writing. $3F04/8/C is not a mirror for $3F00, there's just no way to display it on the screen normally (except by setting the PPU address to it). $3F10 is a mirror for $3F00, though, and $3F14 for $3F04, etc. There's 28 unique bytes in the palette (with 4 mirrors), and only 25 can display to the screen.
Post Reply