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???
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???