Ocasionally some platforms or parts of the background change colors too.
Is this circuit implementation correct? I just used what I had at hand...
This seems to confirm my suspicions that it's kind of incomplete (or buggy) MMC1 clone.
I also tried to disable PRG ROM when writting PRG RAM using this circuit,(just added an 74ls04 to the mix) but ended with an unbootable cart: I'll try to do some videos showing what's up later.
Hope someone can give some advice this time...
Looks right?Fisher wrote:[...]
Code: Select all
M2 --+---_ | )---+ /ROMSEL -+---¯ +--+---_ | )--- PRG +CE A14 --+---_ +--+---¯ | )---+ A13 --+---¯
Is this circuit implementation correct?
Note that /ROMSEL arrives later than M2, by enough to potentially be a problem.
It ought to be ok, but maybe as stands writes to the MMC1 register at $E000 could accidentally write to RAM as well.
You could try rearranging as
PRG RAM +CE = AND(AND(AND(M2,CPU A14),CPU A13),/ROMSEL) so that the propagation delay of M2 through the first two AND gates might match, and see if that fixes anything.
I'm not clear why that's not working? But it's worth pointing out that the PRG ROM should already be disabled (i.e. the MMC1 should already be generating MMC1 PRG ROM /CE = OR(NES /ROMSEL,NOT(CPU R/W)) )
Code: Select all
CPU R/W ------+---_ | )---|>O--- PRG ROM /OE MMC1 PRG ROM /CE --|>O-+---¯
I have rearranged as you said and noticed no differences.
Should I add more logic to try to slow M2 down?
Maybe add a capacitor?
I have tried it because I'm afraid that the RAM protection may not be implemented properly.Fisher wrote:(i.e. the MMC1 should already be generating MMC1 PRG ROM /CE = OR(NES /ROMSEL,NOT(CPU R/W)) )
Maybe the LS04 I got is bad... I just got these parts from very old peripheral boards.
I think it may be some register data beig write to RAM, and not some bus conflict or RAM corruption. But I may be wrong...
I don't knowFisher wrote:Should I add more logic to try to slow M2 down? Maybe add a capacitor?
You're already using a 74LS part, which effectively has pullup resistors (transistors, really) on all its inputs.
You could try something like
Code: Select all
M2 -|<|-+- 74LSxx input | gnd -C--+
Anyway, Metroid writes to the PRG bank register via $E000, so if there were corruption of PRG RAM it'd be the byte at $6000. But Metroid is also a FDS port, so it writes to $E000 fairly rarely; if you're seeing tile corruption regularly and not just once, it's probably not that. More likely some other PRG RAM issue.
Tried even a crazy RAM protection circuit made with an LS02: No deal too.
Let me try to explain exactly where the bug first appears:
I start and go left to get the morph ball, then, go all the way to the right.
The bug starts when I enter the room that I can go up.
At first, the platforms appear fine, when the transitional animation ends some appears a little down, others disappear and are seem just as a solid wall.
I can jump up on the invisible platforms. If I go up, the next screen seems just fine.
About 3 or 4 screens up some parts change from blue to orange.
This is as far as I go in the game, it may or may not have more bugs.
I hope I can do a little video tomorrow, it may show the bugs better.
Would this be CHR RAM related?
The only thing on CHR RAM I see connected on MMC1 is A12. Should I connect it straight to PPU A12?
Again, many thanks for helping. I'm learning a lot while having fun!!
Can I somehow build a substitute externally like the PRG RAM decoder?
What about CHR RAM? Is the connection to MMC1 CHRA12 correct?
Yeah, nesdevwiki:MMC#Control.Fisher wrote:The mirroring circuit inside the misterious black bubble?
Probably notCan I somehow build a substitute externally like the PRG RAM decoder?
You could try burning a copy of tepples's Holy Diver, Batman! test, and see what it says...
Yes.What about CHR RAM? Is the connection to MMC1 CHRA12 correct?
I really will like to do this, but in the future. My knowledge is still very tiny.
I should have already made the ROM socketed. I was too confident when I modded it.
Or, maybe just give up and try a game that don't use the mapper's PRG RAM.
I was thinking in do a translated Megaman 2...
I'll try the Holy Driver tomorrow. I'll post here the results.
Again, many thanks!!
These are by far the best logical circuit classes I have get!!
A little before the second bug:
The video from the begining, it's boring see me playing Metroid:
Hope this make easier to get some clues.
Do traces go between PPU A10, PPU A11, and CIRAM A10 to the black chip-on-board?
( http://wiki.nesdev.com/w/index.php/MMC1_pinout , http://wiki.nesdev.com/w/index.php/Cartridge_connector )
They're connected according to the schematics I'm following, the same way they're shown on MMC1's pinout.
In fact, I have not touched these pins on my mod.
Looks like it has some internal register bug.
I had not removed the Flash ROM yet to try the holy driver.
Maybe I don't need to... just disconnect /CE and /OE from one chip and connect to another, making sure all the other pins match.
I think this can save me some time.
Looks like it's trying to comunicate!
Someone could please tell me what's he's saying? Perharps there's some bad soldering somewhere!
Or maybe he just says: "give up you pirate" ?
The nametable mirroring for this mapper doesn't match any of the supported mappers. Check PA13-PA10, /PA13, CIRAM A10, and CIRAM enable, and don't try running the 78.3 test on an emulator that does not support NES 2.0 format.