SOLVED - Debugging an MMC3 Dev Cart

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

SOLVED - Debugging an MMC3 Dev Cart

Post by Karatorian » Mon Oct 07, 2013 3:40 pm

I built a dev cart out of an NES-TLROM-03 board (this one in particular), but it doesn't seem to work and I'd like some help

I removed the roms and replaced them with 28 pin sockets (from which I'd clipped pins 1, 22, and 27 to support rewiring). I then ran jumper wires as follows:

Code: Select all

	Board					Socket

	PRG	32 Vcc	29	27 /WE
	PRG	27 A14	 3	 1 A14
	PRG	22 /CE	24	22 /OE

	CHR	32 Vcc	29	27 /W
	CHR	27 A14	 3	 1 A14
	CHR	22 /CE	24	22 /OE
This should have tied the write enables high, and the output enable to chip enable, so that EEPROMs placed in the sockets would act like ROMs. It should also have fixed the A14 line.

I loaded the PRG socket with an Atmel AT28C256 EEPROM and tried it out, but it didn't work. So I started checking connections with my meter. Even though pin 27 was clipped, there was still a connection between the socket and the board (due to the jumper wire going to pin 1). This would have the effect of pulling A14 high at all times. That shouldn't (AFAICT) have changed anything, but I fixed it anyway. After removing the jumper wire and a lot of work sucking solder out of the hole, I finally managed to break the connection. To avoid remaking it, I ran the A14 jumper wire to a pad connected to the MMC3's A14 line instead.

I didn't fix the CHR, which had the same problem, as it didn't have any chip loaded in it. It still didn't work, so I removed all the CHR jumper wires (just in case) and tried again, but it still didn't work.

I don't have access to a proper EEPROM burner (I'm looking to remedy that soon), but I've hacked together an eight-bit jobbie and it seems to work. By pulling all the unused address lines high, I'm able to write one page to the top of the ram, which should end up mapped to $FF00-$FFFF. As one page NES programs are in short supply, I wrote one of my own (which you can download here.) All it does is change the background color to purple and turn on sprite rendering (so that the background color shows), but it ought to be enough to confirm that it's working.

My NES is out of commission, so I've been testing on a cheap 72-pin famiclone. The only thing I can think of that would be an issue with using the clone is that it doesn't supply a full 5 volts, it only puts out 4.16 volts. The datasheet on my EEPROMs calls for a supply of 5 ± 10% volts, so it's slightly out of spec. I haven't tested whether the EEPROMs work when under-supplied.

At this point, I can't figure out what's wrong. Four possibilities come to mind:
  • Something is wrong with my rewiring.
  • The EEPROMs don't like the clone's under voltage.
  • The MMC3 doesn't function with the CHR missing.
  • My test program doesn't work on real hardware.
  • Despite appearances, my hacky EEPROM burner doesn't work.
Here's some pictures if you think it'll help:
Would anyone with a MMC3 dev board be willing to test out the little ROM I made? Does anyone have any suggestions for troubleshooting?
Last edited by Karatorian on Sat Oct 26, 2013 1:43 am, edited 3 times in total.

lidnariq
Posts: 9774
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Debugging an MMC3 Dev Cart

Post by lidnariq » Mon Oct 07, 2013 8:59 pm

Ok, I took your program, put it on an m218 devcart I made, and tried. It worked. So
Karatorian wrote:•My test program doesn't work on real hardware.
Not that.

My devcart has an AT28C64 in it, so hopefully the same characteristics as your AT28C256. So then I took my bench supply, supplied power to my NES after the regulator, and turned the bench supply down to 4.1V (and then to 3.3V), and it still worked. (Video gets darker, known effect). So
Karatorian wrote:•The EEPROMs don't like the clone's under voltage.
Not that.

Then, I took a random MMC3 game (SMB3) and tried running it at 4.1V. (and then at 3.3V). It worked fine at 4.1V, and provided entertaining glitches from CHR being too slow at the lower voltage, so it's not that either.

Hope that helps...

3gengames
Formerly 65024U
Posts: 2281
Joined: Sat Mar 27, 2010 12:57 pm

Re: Debugging an MMC3 Dev Cart

Post by 3gengames » Mon Oct 07, 2013 9:19 pm

Did you split the ROM with ReadNES3, my NES rom splitter? I've had problems with ReadNES normal version, it sucked. Worked for some games, not all by far. I don't know what was wrong with it, but it didn't work for me. It'd flake out somewhere in the CHR-ROM, and trash a little of the program to make it not work. At least that's what I remember.

Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Re: Debugging an MMC3 Dev Cart

Post by Karatorian » Mon Oct 07, 2013 11:48 pm

Thanks a bunch lidnariq for messing about with hardware for me. My "bench supply" is a hacked PC power supply, so I don't have the option to put out arbitrary voltages. (I should probably hack up something to fix that.) You've eliminated two of the potential issues, so I can concentrate on the rest. I figured that little test program would run work, but without a dev cart, I had no way to be sure. I was rather worried that the low voltage was the issue (as it'd mean my cart would be useless to me, even if built properly), so it's nice to have that eliminated.

The more I think about it, I rather doubt that the MMC3 really cares whether the CHR is there or not. Which leaves my rewire job or the burner. The burner seems to work, but the only hardware I have to read memory chips is the burner itself. If I've got some address or data lines crossed, it'd appear to work, but the actual data written would be garbled. But I think the wiring is more likely the problem. At this point I'm wondering if the problem is that what I was trying to do isn't correct or whether my implementation is flawed.

I suppose it's probably difficult to tell exactly what I did or was trying to do from the description in the first post. I'm thinking about making some schematics, which might make things clearer.
3gengames wrote:Did you split the ROM with ReadNES3, my NES rom splitter?
I didn't use any ROM splitter. I used a modified version of my ld56 linker script that output the last page as a raw binary. If I where to split an arbitrary ROM image, I'd probably just use dd.

lidnariq
Posts: 9774
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Debugging an MMC3 Dev Cart

Post by lidnariq » Tue Oct 08, 2013 12:01 am

Karatorian wrote:The burner seems to work, but the only hardware I have to read memory chips is the burner itself. If I've got some address or data lines crossed, it'd appear to work, but the actual data written would be garbled.
Are the original Mask ROMs still intact? If so, you could verify by dumping them. (But my intuition agrees with yours, it's probably the rewiring job.)
Karatorian wrote:I'd probably just use dd.

Code: Select all

dd if=one-page.nes bs=16 skip=$((1+15*1024/16)) > /dev/ttyUSB0
:D

Overload
Posts: 47
Joined: Mon May 30, 2011 4:38 pm
Location: Australia
Contact:

Re: Debugging an MMC3 Dev Cart

Post by Overload » Tue Oct 08, 2013 6:48 am

Karatorian wrote: This should have tied the write enables high, and the output enable to chip enable, so that EEPROMs placed in the sockets would act like ROMs.
There's no need for output enable to be tied to chip enable, you're better off connecting it to ground.

Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Re: Debugging an MMC3 Dev Cart

Post by Karatorian » Thu Oct 10, 2013 4:36 pm

lidnariq wrote:Are the original Mask ROMs still intact? If so, you could verify by dumping them.
Unfortunately, the original mask ROMs aren't entirely intact. I took the easy route to desoldering them and clipped the pins off. There's probably enough of the pins left to solder some wires onto, but it'd be a pretty messy hack. (Now I'm thinking that I shouldn't have been so lazy.)
Overload wrote:There's no need for output enable to be tied to chip enable, you're better off connecting it to ground.
Yeah, that'd be simpler. Why didn't I think of that? I'll keep it in mind as I investigate.

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Debugging an MMC3 Dev Cart

Post by infiniteneslives » Fri Oct 11, 2013 12:17 pm

Overload wrote:There's no need for output enable to be tied to chip enable, you're better off connecting it to ground.
I've found that it's actually required to tie /CE to ground for most EPROMs due to timing issues. Not doing so often results in graphics glitches interestingly enough.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Karatorian
Posts: 76
Joined: Sun Sep 30, 2007 9:54 pm
Location: Corneria
Contact:

Re: Debugging an MMC3 Dev Cart

Post by Karatorian » Fri Oct 25, 2013 12:01 pm

I was able to solder leads onto the PRG rom I clipped off the donor board and read back the correct data, so I've ruled out my EEPROM programming setup as the problem. Must still be something wrong with my wiring.
infiniteneslives wrote:I've found that it's actually required to tie /CE to ground for most EPROMs due to timing issues. Not doing so often results in graphics glitches interestingly enough.
That makes it sound like it's fast enough for the CPU's clock speed, but not for the PPU's higher rate. Either way, it makes sense to me to ground it. So that's what I've done.

My current rewiring setup is as follows:

Code: Select all

Socket  1 A14  -->  MMC3 A14
Socket 20 /CE  -->  GND
Socket 27 /WE  --> +5V 
Which I just realized is wrong, because it leaves the EEPROM's /OE line tied to A16. I'll go fix that and see if it works.

Edit: I rewired the entire PRG side of the board. This time I cut some traces so I didn't have to deal with clipping or lifting pins and the rewire job was much cleaner. After a few missteps, I finally got it working. Thanks for all the help and suggestions.

P.S. This whole experience has made me realize three things: Donor boards are not convenient, neither are socketed EEPROMs, and, I need a desoldering gun.

User avatar
poorstudenthobbyist
Posts: 132
Joined: Fri Jun 24, 2016 4:20 pm

Re: Debugging an MMC3 Dev Cart

Post by poorstudenthobbyist » Wed Oct 14, 2020 6:14 am

infiniteneslives wrote:
Fri Oct 11, 2013 12:17 pm
I've found that it's actually required to tie /CE to ground for most EPROMs due to timing issues. Not doing so often results in graphics glitches interestingly enough.
Sorry for bumping such an old thread - but is this true? I had never heard of that before. Is that why /CE is normally tied to GND on NES games?

Is the timing issue from specifically slower EPROMs, and if so, how slow do they need to be to show problems? I've used both the /CE and /OE pins separately on boards before with 39SF040 chips (access time worst case of 70ns) and haven't seen any issues.

Post Reply