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

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

Author:  Zepper [ Sat Feb 28, 2015 3:34 pm ]
Post subject:  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.

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

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.


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.

Author:  tepples [ Sat Feb 28, 2015 4:30 pm ]
Post subject:  Re: Micro Machines glitches

rainwarrior wrote:
Zepper wrote:
Just to be crystal clear. Writing to $3F10 mirrors to $3F00, but does writing to $3F00 mirror to $3F10?

I don't understand what the one-way concept of the mirror is supposed to be.

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.

Author:  Zepper [ Sat Feb 28, 2015 4:53 pm ]
Post subject:  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:
              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;

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

Zepper wrote:
Even Nintendulator have this "piece of" dark blue line. So, I believe the following code is NOT correct after all... :(
Code:
              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;


Can you post a screen shot of Nintendulator?

Author:  Zepper [ Sat Feb 28, 2015 5:09 pm ]
Post subject:  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
Micro Machines (Unl) (U) 000.bmp [ 180.05 KiB | Viewed 2052 times ]

Author:  zeroone [ Sat Feb 28, 2015 5:11 pm ]
Post subject:  Re: Micro Machines glitches

Zepper wrote:
Not needed, here's another. See the darker line there? Only Nestopia has a perfect image.


My emulator looks just like that! Is Nestopia cheating?

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

No. It uses a cryptic code though... :(

Author:  zeroone [ Sat Feb 28, 2015 9:13 pm ]
Post subject:  Re: Micro Machines glitches

What about puNES?

Author:  Quietust [ Sat Feb 28, 2015 9:57 pm ]
Post subject:  Re: Micro Machines glitches

Zepper wrote:
Even Nintendulator have this "piece of" dark blue line. So, I believe the following code is NOT correct after all... :(
Code:
              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;

Oh, that code is definitely correct - the behavior was discovered by early tests and later confirmed by examining the silicon itself.

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.

Author:  Zepper [ Sun Mar 01, 2015 10:34 am ]
Post subject:  Re: Micro Machines glitches

Notice that my emu uses a different way of rendering graphics, and the glitch is exactly the same. ^_^;;

Author:  zeroone [ Sun Mar 01, 2015 12:22 pm ]
Post subject:  Re: Micro Machines glitches

From this thread:

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

Author:  Zepper [ Mon Mar 02, 2015 4:30 pm ]
Post subject:  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:
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;
      }

Author:  Jarhmander [ Mon Mar 02, 2015 6:28 pm ]
Post subject:  Re: Micro Machines glitches

Zepper wrote:
I didn't know about wrapping to zero if the sprite address is incremented from $FF. Is this documented??

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.

Author:  Kilokahn [ Sun Apr 26, 2015 4:26 pm ]
Post subject:  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?

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