nesdev.com

Is the bug similar to this one?
It was fixed with a diode + capacitor on M2, as explained here.

These type they moving to diferent sites in the screen in a pattern like if they have a on/off switch. Sometimes they have more or less. Appears in all sites cartridge menu included.

Not appear in the noac.

Those lines imply that the CHR ROM is just barely too slow. Perhaps they wired /CE and /OE backwards...

Really is a little strange because the game smoke gun sound horrorous. The music is corrupted in the nevir and even in the modern noac

If you want i can open the cartridge and make a picture of internals.

I have try these cart in four different nevir mastergames and all have the issues.

But today someone gift me another absolute yellowed. Very early console buyed in january 92. And he not have issues with the cartridge, nothing.

Interesting.
Maybe you can compare the boards and find the differences.

I can make a pictures to compare,but in the beginnig is the same motherboard layout what mistery.

I view a big difference, this early verssion use two yundai HY6116AP—10 as ram instead the umc. Also the secondary chips change brand.

Using "modern" bootlegs from China made out of 3.3v flash may have that kind of problem (lines and flashing dots) on original Nintendo hardware (or clones using discrete chips).

Very interesting that this clone has the positions to make a second separated clock oscillator for the PPU. Very early board.

Interesting...
I've been "reviving" some dead cartridge boards using PLCC chips found on older motherboards.
I thing I should take a look if the chips are 5v tolerant or else I may have problems in the future!!

Those will be 5V unless they're "29Lxxxx" or have an "L" somewhere on the code number. Usually PCs using parallel NOR flash did stick to 5V parts. Serial ones (FWHUB or SPI) will likely be using 3.3v instead.

Of course FWHUB and SPI will be kind of useless for the NES, as they're serial memories... Right?

Sure!
I was thinking in using it somehow on the NES, but unfortunatelly I couldn't think about a nice and easy solution.
They're becoming more common on the thrashed parts.
But I think new motherboards are using something like I2C protocol, aren't they?

With this, my "raise from your graves" party are coming to an end soon...
Not that I have much more boards to "ressurect", but I would like to try some SNES games too.

SPI, not I2c, which also happen to be a industry standard on serial bus communication. SPI is that four wire protocol which is used for example in programming of AVR MCUs

Variants of SPI are used for NES, Super NES, and PlayStation controllers and for Game Link on Game Boy and Game Boy Color. The difference is that MOSI (master out slave in) and chip select are intertwined on the Nintendo systems.

Voltage in this case or is the umc ram speed?. Its not only litte lines,it depend of the console, but the lines can be massive in all screen. And in super mario bros i view a slowdown and a ghost images of the screen elements tubes etc etc that go with you until are redrawed with new ghost images.

I can't found anything about the umc ram specification anyway. But in the console with hyundai chips (100ns) works perfect.

I mean, both.

Basically, the little 8x1 glitches come from the PPU fetch pattern. Every 8x1 chunk of pixels in the background comes from the following sequence by the PPU:
* Fetch which tile should be drawn from PPU RAM
* Fetch what color that tile should be drawn from PPU RAM
* Fetch one bitplane of the tile from CHR
* Fetch the other bitplane of the tile from CHR

If any one of those steps go wrong, you'll get one of those 8x1 glitches.

There's a bunch of ways that adding an unprotected 3V ROM could screw things up.

* Because of the PPU's multiplexed data bus, a 3V ROM could drag the data bus too low to be reliably and correctly latched by the 74'373. In turn, that'd cause a fetch from the wrong address and thus the wrong tile.

* Because the CHR ROM is only driving its output up to ≈3.3V, the output won't necessarily have risen high enough fast enough to be received by the PPU correctly. And then, bad value → glitch.