MMC1: PRG-ROM /OE vs /CE and CHR A11 glitching???

[infiniteneslives]

So in my efforts to recreate the MMC1 on a Xlinix 9500XL series CPLD I had a bug that boggled my brain for over a month and I finally killed the beast today. But I'm really not sure why this was happening.

So I was having similar issues on all games I tested reguardless of CHR-ROM or RAM. But it was easiest for me to identify the problem on this screen of Zelda:


As you can see the large sword has some sprites that are wrong, being replaced with smaller swords ironically. There are some other funky moss glitches and problems with the waterfall as you can see. If you open up this screen in a PT veiwer you can see that the sword sprite is getting replaced by the tile you'd find if CHR A11 was high instead of low like it should be (PPU $0800 vice $0000). I also confirmed this with an oscope and saw where CHR A11 was going high during sprite fetches.

Another interesting note is that I had 3 different versions of glitching. That image is the worst it got. One version would only have one tiny sword. The last version of the glitch I'd see made this screen look perfect, and you didn't see glitching until you got to other screens. I presumed the three versions of glitches were somehow related to the CPU PPU alignment, but still didn't explain the issue.

In my troubleshooting I actually ran zelda with 8KB of CHR-RAM wired DIRECTLY to the PPU/Cart edge. and the Mapper didn't even TOUCH the CHR lines. Additionally I hard wired mirroring since this screen is one screen mirroring. The problem persisted, even though the only thing my mapper was controlling was PRG-ROM and WRAM (which isn't used/relied upon until exiting this screen)

To debug further I hooked up an original MMC1 to my board and completely removed the CPLD. But the problem persisted. When doing thing I noticed the original MMC1 boards have the MMC1 PRG-ROM /CE output signal actually connected to the PRG-ROM's /OE pin instead of the /CE pin. I dismissed it though, and as usually happens it dawned on me as I was waking up the next morning the ONLY difference I had was the /OE /CE swaperoo. But by the time I had a time to work on the bug again I dismissed the idea as not worth my time to test out. I really couldn't see how that would have caused my CHR A11 glitch.

Several weeks passed, I got around to ordering my second batch of boards even though I couldn't find this bug, and tonight I sat down to give it a shot. Couldn't hurt to try, I was pretty desperate to find the cause at this point. I also noticed that my mmc1 repropak was similar to the original boards, but a little different. Retrozone's boards connect PRG-ROM /CE directly to CPU /ROMSEL on the cartedge and then control PRG-ROM /OE with the mapper. I tried that and the problem persisted. So I copied Nintendo's method of grounding /CE pin and having the mapper control /OE. It worked! Problem solved. But I STILL don't know how getting PRG-DATA a little faster by use of /OE vice /CE would cause CHR A11 to go high at times...

Any thoughts, ideas, or guesses as to why this phenomenon exists???

[lidnariq]

Is there any chance that the value in nametable RAM is correct for A11 to be wrong (D7 high) ? i.e. could the PPU/CPU have written the wrong value?

[infiniteneslives]

Is there any chance that the value in nametable RAM is correct for A11 to be wrong (D7 high) ? i.e. could the PPU/CPU have written the wrong value?

I'm not certain, but I don't think so. I had considered this possibility previously. The wrong sprites would actually flicker in and out at times. Just now I tested it out and it starts with one tiny sword, and then another one starts to gradually flicker in until it's solid. While that's happening the original tiny sword glitches remain solid (they aren't all flickering in unison).

In the title screen where things scroll up with all the weapons and stuff those ALWAYS flicker in and out with the wrong sprite (the ones in $0000-07FFF anyways). Looking at it again some are worse than others. There is a constant fast flicker to many, and a couple where they flicker every second or two.

So based on the fact it progressively gets worse in one viewing and some sprites flicker in and out of being proper I'd say the is NT good. Wait a min, of course the NT data is good, the background is flawless. This is sprite data in the PPU OAM, NOT nametable data... And this data IS updated every frame, so that would support the idea of the CPU writing the wrong value (D7 high) and that could gradually get worse as the PRG-ROM circuitry 'warms-up'.

I'm still confused about how having slightly slower PRG-ROM would cause issues on MMC1 and not anything else. (including discretes, MMC2,3,4, FME-7, etc)

[socram8888]

Could it be DMA-related?

[l_oliveira]

When you set /CE high, the chip "sleeps". It take a longer time for it to ready itself for a read or write cycle than it take if you strobe it with just /OE and /WE.

[infiniteneslives]

Could it be DMA-related?

The problem is most likely occurring during DMA. Not sure why this is mmc1 specific though...

I'll test this out for every new mmc1 game I try out and see if it happens on ALL mmc1 games. So far I've tested Zelda, metroid, and lolo all with the same problem. I might try out some faster flash chips and see what happens. I've tested dozens of other non-mmc1 with the same setup and never seen anything like it.

[80sFREAK]

I can guess, that your CHR RAM chip was made in the middle of 1986. Probably by Sony or Hitachi.

[infiniteneslives]

I can guess, that your CHR RAM chip was made in the middle of 1986. Probably by Sony or Hitachi.

Even if I were to give you the benefit of the doubt and assume you were taking about onboard CHR-RAM aka "CIRAM" it still has nothing to do with the sprite issue.

[blargg]

I thought you had already reasoned that this shouldn't be happening. How are you ruling CHR RAM or anything as a cause?

[infiniteneslives]

I thought you had already reasoned that this shouldn't be happening. How are you ruling CHR RAM or anything as a cause?

Based on 80sFREAK question, I'm not sure if you're asking about Name Table CHR-RAM 'CIRAM' or cartridge Pattern Table CHR-RAM. But either way here's how I've eliminated both of them:

Not the Pattern Table CHR-RAM because I see the same issue on CHR-ROM games.

Not the Name Table CIRAM because sprites aren't stored in Name Tables, their stored in OAM inside the PPU. The background looks fine, the problem is with sprites.

[3gengames]

Looking at Zelda, the BG tile with the swords is different. That's a CHR-ROM problem, yes?

[infiniteneslives]

Looking at Zelda, the BG tile with the swords is different. That's a CHR-ROM problem, yes?

The background is fine.



Those few segments of the sword are sprites because of the overlay with the triangle. You can also see the moss are sprites and the white part of the waterfall is as well. Those are all the places where my glitches are occurring.

Zelda is actually SNROM and has CHR-RAM. I did see the same issue with Lolo which is CHR-ROM though. But that isn't the issue because I actually saw CHR A11 going high using a scope while the PPU was fetching sprites. The CHR-RAM was outputing the proper tile that was addressed. Plus the glitch caries for the FULL tile, not just a few lines of the tile. So that suggests the PPU actually has the wrong tile stored in it's OAM since all 8 fetches for a given tile agree on which half of the PT the sprite is.

[3gengames]

Ahh, gotcha. Was thinking that part of the sword would be on the background. And yep, knew it was SNROM, but didn't think it'd be to the writes since it's supposedly a rendering problem...although I should have assumed it was a sprite too, but I didn't think that deep.

[Memblers]

Sounds not unlike the sprite strangeness I ran into long ago when using a ROM emulator device. Didn't matter what mapper or board it was on, it was only a replacement of the PRG-ROM and it would semi-consistently cause some sprites to be glitched. One theory is that the beginning of the sprite DMA is having a bus conflict with the PRG-ROM. kevtris had an adapter with 330-ohm resistors in series with the PRG data lines, and when the whole setup was run though that, it worked fine.