nesdev.com
http://forums.nesdev.com/

Micro Machines glitches
http://forums.nesdev.com/viewtopic.php?f=3&t=12425
Page 4 of 6

Author:  James [ Thu Feb 26, 2015 6:16 pm ]
Post subject:  Re: Micro Machines glitches

Secondary

Author:  Zepper [ Thu Feb 26, 2015 6:29 pm ]
Post subject:  Re: Micro Machines glitches

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

Author:  zeroone [ Thu Feb 26, 2015 6:36 pm ]
Post subject:  Re: Micro Machines glitches

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


Before:

Image

After:

Image

Author:  Sik [ Thu Feb 26, 2015 10:14 pm ]
Post subject:  Re: Micro Machines glitches

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.

Author:  zeroone [ Fri Feb 27, 2015 11:49 am ]
Post subject:  Re: Micro Machines glitches

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:
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:
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.

Author:  James [ Fri Feb 27, 2015 12:13 pm ]
Post subject:  Re: Micro Machines glitches

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.

Author:  zeroone [ Fri Feb 27, 2015 1:02 pm ]
Post subject:  Re: Micro Machines glitches

James wrote:
Are you accounting for palette mirroring and this, re: $3F04/$3F08/$3F0C?


Yes. Per the wiki:

Quote:
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.

Author:  tokumaru [ Fri Feb 27, 2015 1:30 pm ]
Post subject:  Re: Micro Machines glitches

zeroone wrote:
Yes. Per the wiki:

Quote:
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.

Author:  James [ Fri Feb 27, 2015 4:23 pm ]
Post subject:  Re: Micro Machines glitches

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.

Author:  Zepper [ Fri Feb 27, 2015 6:49 pm ]
Post subject:  Re: Micro Machines glitches

The problem is that "piece of" line in dark blue.

Author:  zeroone [ Fri Feb 27, 2015 8:51 pm ]
Post subject:  Re: Micro Machines glitches

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.

Author:  Zepper [ Sat Feb 28, 2015 4:58 am ]
Post subject:  Re: Micro Machines glitches

@zeroone
Currently, what's the problem with Micro Machines? Just a recap.

Author:  zeroone [ Sat Feb 28, 2015 10:19 am ]
Post subject:  Re: Micro Machines glitches

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.

Author:  Zepper [ Sat Feb 28, 2015 1:55 pm ]
Post subject:  Re: Micro Machines glitches

Quote:
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..?

Author:  rainwarrior [ Sat Feb 28, 2015 2:07 pm ]
Post subject:  Re: Micro Machines glitches

The Wiki article on PPU palettes 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.

Page 4 of 6 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/