Micro Machines glitches
Moderator: Moderators
Re: Micro Machines glitches
Just to be crystal clear. Writing to $3F10 mirrors to $3F00, but does writing to $3F00 mirror to $3F10? Since SMB background was mentioned, $3F00 could have unique data instead of mirroring to $3F10.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Micro Machines glitches
I don't understand what the one-way concept of the mirror is supposed to be. There is only one piece of data, but two addresses you can access it with. It doesn't make a difference which one you use.Zepper wrote:Just to be crystal clear. Writing to $3F10 mirrors to $3F00, but does writing to $3F00 mirror to $3F10? Since SMB background was mentioned, $3F00 could have unique data instead of mirroring to $3F10.
Re: Micro Machines glitches
The mistaken concept might have been that there exist two pieces of data and a particular address would select both for writing. It's similar to how the Codemasters mapper selects both the lockout chip and the bank switching circuitry at $E000-$FFFF.rainwarrior wrote:I don't understand what the one-way concept of the mirror is supposed to be.Zepper wrote:Just to be crystal clear. Writing to $3F10 mirrors to $3F00, but does writing to $3F00 mirror to $3F10?
Re: Micro Machines glitches
Even Nintendulator have this "piece of" dark blue line. So, I believe the following code is NOT correct after all...
Code: Select all
int offset = VRAMaddr & 0x1F;
int value = data & 0x3F;
ram_color[offset] = value;
//Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C.
if( !(offset & 3) )
ram_color[offset ^ 0x10] = value;
Re: Micro Machines glitches
Can you post a screen shot of Nintendulator?Zepper wrote:Even Nintendulator have this "piece of" dark blue line. So, I believe the following code is NOT correct after all...Code: Select all
int offset = VRAMaddr & 0x1F; int value = data & 0x3F; ram_color[offset] = value; //Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. if( !(offset & 3) ) ram_color[offset ^ 0x10] = value;
Re: Micro Machines glitches
Not needed, here's another. See the darker line there? Only Nestopia has a perfect image.
- Attachments
-
- Micro Machines (Unl) (U) 000.bmp (180.05 KiB) Viewed 5738 times
Re: Micro Machines glitches
My emulator looks just like that! Is Nestopia cheating?Zepper wrote:Not needed, here's another. See the darker line there? Only Nestopia has a perfect image.
Re: Micro Machines glitches
No. It uses a cryptic code though...
Re: Micro Machines glitches
What about puNES?
Re: Micro Machines glitches
Oh, that code is definitely correct - the behavior was discovered by early tests and later confirmed by examining the silicon itself.Zepper wrote:Even Nintendulator have this "piece of" dark blue line. So, I believe the following code is NOT correct after all...Code: Select all
int offset = VRAMaddr & 0x1F; int value = data & 0x3F; ram_color[offset] = value; //Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. if( !(offset & 3) ) ram_color[offset ^ 0x10] = value;
As explained earlier, there are 28 "bytes" (only 6 bits wide, though) of palette SRAM inside the PPU, but 32 addresses by which they can be selected. Most addresses select unique cells, but $3F10 selects the same cell as $3F00 (and vice-versa, by definition), and the same for 3F14/3F04, 3F18/3F08, and 3F1C/3F0C, and that obviously affects both reading and writing - in my code, I chose to do the mirroring during writes because it's faster (writes tend to be counted in dozens, while reads tend to be counted in tens of thousands).
It's more likely that the graphical glitch in Nintendulator is being caused by something else. Exactly what, I can't be sure without checking more closely - probably a timing glitch or something.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Micro Machines glitches
Notice that my emu uses a different way of rendering graphics, and the glitch is exactly the same. ^_^;;
Re: Micro Machines glitches
From this thread:
I also fixed Micromachines which requires exact cycle accuracy on the 2004 readback during rendering. even being off a cycle or two is too much- it won't work right. Once I fixed that so the readback is exactly what it should be, the game worked great.
Re: Micro Machines glitches
I didn't know about wrapping to zero if the sprite address is incremented from $FF. Is this documented?? Other than that, the Nestopia source doesn't bring much info after all. Here we go.
Code: Select all
NES_POKE_D(Ppu,2004)
{
Update( cycles.one );
NST_ASSERT( regs.oam < Oam::SIZE );
NST_VERIFY( IsDead() );
if (IsDead())
{
if ((regs.oam & 0x03) == 0x02)
data &= 0xE3;
}
else
{
data = 0xFF;
} //note: I wonder about "data" being used uninitialized..?
byte* const NST_RESTRICT value = oam.ram + regs.oam;
regs.oam = (regs.oam + 1) & 0xFF;
io.latch = data;
*value = data;
}
NES_PEEK(Ppu,2004)
{
NST_ASSERT( regs.oam <= 0xFF );
if (!(regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED) || cpu.GetCycles() - (cpu.GetFrameCycles() - (341 * 241) * cycles.one) >= (341 * 240) * cycles.one)
{
io.latch = oam.ram[regs.oam];
}
else
{
Update( cycles.one );
io.latch = oam.latch;
}
return io.latch;
}
- Jarhmander
- Formerly ~J-@D!~
- Posts: 569
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: Micro Machines glitches
Well, sprite DMA is just a stream of writes to $2004, so if address didn't wrap it wouldn't work at all if one didn't set $2003 before each write to $4014. Also, it would require more logic to do something different than wrapping for a 8-bit up counter.Zepper wrote:I didn't know about wrapping to zero if the sprite address is incremented from $FF. Is this documented??
((λ (x) (x x)) (λ (x) (x x)))
Re: Micro Machines glitches
My Everdrive N8 with MM shows more glitches than the example on YouTube. Are you sure that is not emulated? Must be a stock cart? How do I switch to read mapper 2?