Micro Machines glitches

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Micro Machines glitches

Post by koitsu »

Why is it nobody in this thread (from what I can discern) has taken the time to check this out on actual hardware? Are people unaware of the fact that it looks glitchy even on the real thing? Here's proof, a la kevtris:

https://www.youtube.com/watch?v=oNkbuQx5v0E&t=4m40s

You guys are trying to solve something that shouldn't need to be solved. The level of obsession over this is amazing.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Micro Machines glitches

Post by rainwarrior »

koitsu, I posted a link to a real hardware video on page 2 of this thread.

It's not glitchy on a real NES (I have tested this, and so have others). Kevtris' video is demonstrating that Micro Machines isn't quite right on his HD recreation, but close. (He even says this a few seconds before the place in the video you linked.)

It is very slightly glitchy on a Famicom, however. I verified this on page 3 when I tested it there as well.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Micro Machines glitches

Post by krzysiobal »

There are 2 version of Micro Machines - one with 1991 on title screen (works better on PAL Famiclone, without any glitches, on NTSC there are minor glitches) and one with 1992 on title screen (works without any glitches on NTSC, hangs after codemasters logo on PAL).
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Micro Machines glitches

Post by Alyosha_TAS »

zeroone wrote:
After:

Image
Sorry for bumping an old thread, but I recently improved my emulators timings and I ended up with this same black line that flashes every other frame.

I dug a little into the problem and this is what I found:

That black line occurs at scanline 109. Right where it starts is where a $2006 write (the second one) occurs to change the VRAM address to $3F60.

The problem actually occurs in scanline 108. On alternating frames , the horiz(v) increment at 328 is missed because rendering is turned off slightly too early. This causes a write to $2007 that should go to $3F10 (a mirror of $3F60) to go to $3F09 instead. Then on the next scanline the wrong palette color is in the address so the black line appears.

According to the emualator, rendering is disabled at either 326 or 328 in scanline 108. Presumably the 2 pixel difference is due NMI happening at 1 cpu cycle different timing between frames and 1 of the 3 pixels is used up due to the skipped pixel on alternating frames.

So that is the cause of the black line. The question is, what is different between emulators that this line isn't showing up in others? What is the correct way to fix the problem?

EDIT: Turns out I had an order of operations problem. I was incrememnting the cycle count of the PPU before executing the CPU read, so for the $2004 read code, I had to use '<=' instead of '<' when comparin to the cycle time. Simple fix and Micro Machines now looks perfect! However, in order for this to work I have to do the 'PPU on' check for the horiz(v) increment 2 cycles before it happens. This needs investigating.
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 »

Alyosha_TAS wrote:Sorry for bumping an old thread, but I recently improved my emulators timings and I ended up with this same black line that flashes every other frame.

I dug a little into the problem and this is what I found:

That black line occurs at scanline 109. Right where it starts is where a $2006 write (the second one) occurs to change the VRAM address to $3F60.

The problem actually occurs in scanline 108. On alternating frames , the horiz(v) increment at 328 is missed because rendering is turned off slightly too early. This causes a write to $2007 that should go to $3F10 (a mirror of $3F60) to go to $3F09 instead. Then on the next scanline the wrong palette color is in the address so the black line appears.

According to the emualator, rendering is disabled at either 326 or 328 in scanline 108. Presumably the 2 pixel difference is due NMI happening at 1 cpu cycle different timing between frames and 1 of the 3 pixels is used up due to the skipped pixel on alternating frames.

So that is the cause of the black line. The question is, what is different between emulators that this line isn't showing up in others? What is the correct way to fix the problem?

EDIT: Turns out I had an order of operations problem. I was incrememnting the cycle count of the PPU before executing the CPU read, so for the $2004 read code, I had to use '<=' instead of '<' when comparin to the cycle time. Simple fix and Micro Machines now looks perfect! However, in order for this to work I have to do the 'PPU on' check for the horiz(v) increment 2 cycles before it happens. This needs investigating.
The black line does not appear in Nintendulator 970, but it is present in the newer Nintendulator 975. The older 970 contains a hack where the X/Y-increments occur 4 dots earlier than they should. Nintendulator 975 attempted to be more accurate by moving the increments closer to where they should be; however, accuracy problems manifested itself, such as in this game.

Can you elaborate on your "PPU on" check?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Micro Machines glitches

Post by Alyosha_TAS »

zeroone wrote: The black line does not appear in Nintendulator 970, but it is present in the newer Nintendulator 975. The older 970 contains a hack where the X/Y-increments occur 4 dots earlier than they should. Nintendulator 975 attempted to be more accurate by moving the increments closer to where they should be; however, accuracy problems manifested itself, such as in this game.

Can you elaborate on your "PPU on" check?

Are there any emulators that contain no hacks, do $2004 reads correctly, and still emualte micro machines without graphical errors?

By "PPU on" check I simply mean checking if the PPU is rendering before doing the increment, as the wiki says that increments only happen if this is the case. I did this check one tick earlier then usual and it removed the bug (obviously since rendering was being turned off early.) This caused other bugs though so I have reverted that back to the way it was and the black line remains.

I implemented all the $2004 read characteristics documented by Quietust and others, so in my emulator read2004.nes now shows this:

Image

This matches what Quietust posted with one extra FF at the beginning for some reason (the FF's at the end are just RAM initialized to FF.) Nothing I do can get me to exactly 4 starting FF's, so maybe that is a hint at the problem? Or are there just a variable number of FF's?

This is enough to remove the black line on the title screen but not on the subsequent select one/two player screen.

So yeah, I'm currently at a loss as to how fix the black line.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Micro Machines glitches

Post by Quietust »

Alyosha_TAS wrote:This matches what Quietust posted with one extra FF at the beginning for some reason (the FF's at the end are just RAM initialized to FF.) Nothing I do can get me to exactly 4 starting FF's, so maybe that is a hint at the problem? Or are there just a variable number of FF's?
The number of FFs you get is timing-dependent - each number corresponds to a single PPU cycle (i.e. 1/3 of a CPU cycle), so clock alignment has a very noticeable effect.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Micro Machines glitches

Post by Sour »

Thanks for bringing up that test rom - I did not even know it existed!
This made me notice a few things that were wrong/broken about Mesen's sprite overflow bug & $2004 reads.
I've managed to fix the result to be near-identical to the screen you posted (6 FFs on mine - I can alter this by changing the timing between the CPU/PPU, like Quietust said)

Things that were wrong in Mesen:
1- Reads from $2004 during sprite evaluation (cycles 65 to 256) were completely wrong (never returned the correct result)
2- Fixing 1) made me notice I was also not returning the secondary OAM values on even cycles once the secondary oam was full.
3- The sprite overflow bug wasn't being emulated correctly - after the $00 read that "fixes" the bug in the test, my code did not read the next 3 bytes properly and didn't realign correctly after those 3 bytes.

.. And yet none of these mattered. Fixing them changed nothing to the result of all 225 test roms I test Mesen against, and Micro Machines still works correctly (like it did before).

For Micro Machines to work properly, it's the $2004 reads outside sprite evaluation that matter (cycles < 65 || cycle > 256), if I remember correctly. Those reads are based on the timing of sprite rendering (rather than sprite evaluation).

Hopefully this at least lets you rule out some possibilities and helps you figure out what your issue is!
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Micro Machines glitches

Post by Alyosha_TAS »

@sour: at what cycle is rendering disabled on scanline 108 on the micro machines title screen in mesen? This is really the heart of the problem. Some other test roms you might not be aware of are oam.nes and oam3.nes . They outright crash mesen :shock:
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Micro Machines glitches

Post by Sour »

Ah, there we go.
The "rendering enabled" flag is delayed by 2 cycles in Mesen (I guess that's what you'd call a hack!)
If the CPU writes to $2000 on cycle 326 - cycles 327 & 328 are both considered to have rendering still active.

This is the only way I had found to fix Battleloads while passing all other tests a long time ago.
I wasn't aware it happened to have an impact on Micro Machines though.

I wouldn't be surprised if something like this is actually a thing, considering the recent thread that discovered (still unconfirmed on hardware, though) that the video ram address update done after the 2nd write to $2006 seems to be delayed by 3-4 cycles.

Whether or not a delay exists in the rendering flag's state would probably be fairly easy to figure out with the Visual 2C02/Visual NES, though I don't have time to check right now.


I actually found out about the oam3 tests a couple of weeks ago - the crash was a silly memory mapping issues due to the rom's unusual NES 2.0 headers if I recall correctly. It's fixed in the code, but not in the latest release. Thanks for mentioning it though!
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Micro Machines glitches

Post by Alyosha_TAS »

I managed to get 4 FF's by adjusting the power up timing of the emulator. It now also matches the startup behaviour indicated in the wiki so I guess that solves that.

Delaying the flag does indeed fix the black line (although Battletoads wasnt crashing for me before that so not sure what's happening there exactly.) Now Micro Machines runs without glitches, although that delay definitely needs confirmation.

I can't help but wonder what other delays exist in the ppu, seems like a can of worms might be opening up here. :?
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 »

@Sour @Alyosha_TAS Do your emulators delay $2007 VRAM reads and writes like Nintendulator?
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: Micro Machines glitches

Post by Alyosha_TAS »

zeroone wrote:@Sour @Alyosha_TAS Do your emulators delay $2007 VRAM reads and writes like Nintendulator?
No, mine doesn't, it seems plausible given what is known about $2006.

What situation/game does this effect?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Micro Machines glitches

Post by Sour »

I'm not quite sure what you mean by VRAM read/writes delays, so I'll go ahead and assume I haven't implemented any. I haven't looked at Nintendulator's source in a long time, either..

I played a bit with the Visual NES, this might not be 100% accurate (especially since I did this in like 15 minutes), but nonetheless:

Code: Select all

0A7960,55,F1,0819,19,18,FF,00,DF,2001,00,01,01,00,  ;PPU rendering is disabled (01 in before-last column)
0A7961,55,F1,0819,19,18,FF,00,18,2001,00,00,01,00,  ;CPU starts writing $18 to $2001, which will enable rendering 
0A7961,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,  ;PPU Cycle transitions from 85 to 86 ($55 -> $56)
0A7962,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7962,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7963,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7963,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7964,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7964,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7965,56,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7965,57,F1,0819,19,18,FF,00,18,2001,00,00,01,00,  ;PPU cycle transition from 86->87 ($56 -> $57)
0A7966,57,F1,0819,19,18,FF,00,18,2001,00,00,01,00,
0A7966,57,F1,0819,19,18,FF,00,18,2001,00,01,00,01   ;Rendering is enabled (before-last column turns to 00), 1.5ish PPU cycles after the write
So there are 12 master clocks (1.5 ppu clocks) between the start of the write & the rendering flag being enabled.
This assumes I'm tracing the right signals, obviously - but it is called "rendering_disabled", so it's a pretty good bet.

Again, though, testing with Visual NES is not enough to prove anything, would need a test rom of sorts (but I do not have the slightest clue how one could test this, so I'm definitely not going to be the one writing a test for it :p)
Post Reply