MMC5 Hacking Adventures

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

Moderator: Moderators

User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

lidnariq wrote:
Ben Boldt wrote:[*]Then after that, do 4 sequential reads from address $5800, which is where this CL3 behavior occurs.
[*]During the 4 reads, CL3 is the inverse of M2.
That sure sounds like it became a chip enable...
Yeah, it sounds sort of like a RAM RD / WR combo. Strange though with only a 1kbyte range, and in between the MMC5's registers and its own RAM...

More details:
Tested the write range for SL3, and it is the same range. To test the range, I wrote an $FF to different addresses and watched SL3. Then I tried writing different values to $5800. It doesn't make any difference if I write $FF, 00, 01, 02, or 03 when doing the write. I still have not worked on $5207/5208 but I am betting that writing $03 to $5207 is all it takes to put it into this mode.

Edit:
Yep, I power cycled, then wrote $03 to 5207, then wrote $03 to $5800 and triggered my scope on that one !(M2) pulse sent through on SL3.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

In my MMC5 version writing anything to $5207 enabled this weird mode:
* During read cycle of any address in range $5800-$5bff: pin 97 goes low for duration of that cycle
* During write cycle of any address in range $5800-$5bff: pin 98 goes low for duration of that cycle
Attachments
w.png
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

What if you cycle power, write $F0 to $5207, then $F0 to $5800? Do you get the pulse? Mine stays high when I do that, no pulse.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

I get it.
Attachments
w.png
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

That is very interesting. Either we have different chip versions or parts of the logic are burned out in yours as you had originally suspected. I am not sure which is more likely. Between us, we have 3 L'Empereurs, we may have to try some more MMC5 chips with this. It will be interesting to see if you get an MMC5 or 5A in your L'Empereur. Both of mine had MMC5 letterless.

Either way, we get !(M2) out to SL3/CL3 when reading or writing in the address range $5800-$5BFF. That part is consistent. It seems like a way to expand the MMC5's internal RAM to 2x. What are the limitations of the existing internal RAM when used for the special PPU stuff that it can do? Are there any situations where doubling this RAM could be beneficial?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

That can't be used for any fancy ... whatever external IC is attached can only be attached to one of the CPU's or PPU's data bus at any given time.

Given the values that Just Breed writes, it looks like they were using it for a CPU usage indicator.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

And Just Breed doesn't initialize $5207 so those writes at $5800 are not externally vissible. Luckily, cause 97/98 are shorted.

I bet if any of those unknown five left MMC5 pins is /RD or /WR for the PPU-part of hypothetical dual-port RAM that could be externally connected.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

lidnariq wrote:That can't be used for any fancy ... whatever external IC is attached can only be attached to one of the CPU's or PPU's data bus at any given time.
Oh true, very good point.
lidnariq wrote:Given the values that Just Breed writes, it looks like they were using it for a CPU usage indicator.
So far, we don't know any difference that depends on the value written to this address range. But the fact that they do 2 writes on entry and 1 write on exit would be easily measurable, you might be onto something.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

I've just discovered that if both pins 81 & 82 are shorted to GND, it also puts MMC5 into reset state (which lasts until one of them goes high). This reset state is similar to the one caused by no action on M2 pin:
* EXRAM at $5c00-$5fff is turned off (it starts returning 00s), writing anything to $5104 does not stop it
* pins 97/98 becomes inputs

But there are also differences:
* PRG+CE is still active (logic 1)
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

krzysiobal wrote:I've just discovered that if both pins 81 & 82 are shorted to GND, it also puts MMC5 into reset state (which lasts until one of them goes high). This reset state is similar to the one caused by no action on M2 pin:
* EXRAM at $5c00-$5fff is turned off (it starts returning 00s), writing anything to $5104 does not stop it
* pins 97/98 becomes inputs

But there are also differences:
* PRG+CE is still active (logic 1)
Very interesting. It has to be both 81 and 82 grounded at the same time? When you release them, does it always automatically get out of reset and start functioning again or do you ever have to trigger a gap in M2 to unlatch?

Do you have to release both of them to get out of reset? Can you GND both, and then release just 81 to get out for example, or does it wait for both to be released?

Unrelated question:
Are there any demo ROMs out there that get the MMC5 to do fancy stuff like vertical split screen with scrolling, etc? It would be interesting to probe the MMC5 while doing strange stuff like that.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I tried a lot of things today but didn't find anything new. I specifically looked for dual-port RAM /CEs or /WEs. I made a test where I wrote random data to 1 known writable register (selected randomly), then changed the PPU address bits randomly, and then changed the PPU /RD and /WR randomly. Then read 1 CPU address randomly, any address. Then loop. I never got any of the unknown pins to become outputs. I verified that my M2 gap never exceeded 10 usec in this test. I also individually drove low each unknown pin with a 500 ohm resistor to GND and read all of the other unknown pins. I found no effect from that. I did not try pins 81 and 82 at the same time or any other multiple pins at the same time. I also tried a 500 ohm to 2MHz function generator on each unknown pin, then set my scope to trigger on any frequency that fast. I probed all around with the test running, looking for 2MHz on the unknown pins, the PRG and CHR pins, etc. I never found 2MHz getting out anywhere.

Also during this test, I monitored CPU reads that caused the DAC to change value. I recorded 100 of such addresses with leaving all unknown pins floating. I found no statistical anomalies, which might have suggested a way to change the address range of DAC read mode. Not surprisingly, all changes in DAC value that I observed corresponded either to a write to $5011 or to a read in the range $8000-BFFF. Previous to this test, I did write non-zero incrementing data to all address $5800-5FFF.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

No new findings but maybe some ideas. I took MMC5.97 (CL3), through a 500 ohm resistor, to each of the unknown pins (including SL3), then ran my test again, this time looking to see if the MMC5 drove the CPU data bus when reading from $5800. I also tried my random test with reads and writes outside of the range $5800-5BFF to see if any random register writes could affect the range of CL3/SL3. The range held true. This is a 1 kbyte range.

It is very strange to use CL3/SL3 to control RAM at $5800-5BFF, as $6000-6FFF already can only be used for RAM. If you were going to put 1k RAM at $5800, why on earth not just put it at $6000 and skip all this weird register business? That doesn't add up. Dual port RAM makes lots of sense, especially how the range $5800-5BFF is exactly the size of 1 nametable, but we seem to be missing some very elusive /CS /WE signals.

Riddle me this:

Code: Select all

CPU Side                   PPU Side
                
CPU A0       A0         A0     PPU A0
CPU A1       A1         A1     PPU A1
CPU A2       A2         A2     PPU A2
CPU A3       A3         A3     PPU A3
CPU A4       A4         A4     PPU A4
CPU A5       A5         A5     PPU A5
CPU A6       A6         A6     PPU A6
CPU A7       A7         A7     PPU A7
CPU A8       A8         A8     PPU A8
CPU A9       A9         A9     PPU A9
CPU A10      A10        A10    CHR A10

CPU D0       D0         D0     PPU D0
CPU D1       D1         D1     PPU D1
CPU D2       D2         D2     PPU D2
CPU D3       D3         D3     PPU D3
CPU D4       D4         D4     PPU D4
CPU D5       D5         D5     PPU D5
CPU D6       D6         D6     PPU D6
CPU D7       D7         D7     PPU D7

GND          /OE        /OE    PPU /A13
CL3          /CE        /CE    PPU /RD
SL3          /WE        /WE    PPU /WR
RAM +CE      +CE        +CE    VCC
In this situation, we have 1 nametable mapped to CPU address range $5800-5BFF. Basically creating a different extended RAM for the other side of the vertical split screen. $5800-5BFF on one side of the split, $5C00-5FFF on the other side of the split. I guess that would play into the whole "ease of programming" thing because you could write to both sides the same way. But honestly it isn't really any different than writing to the PPU the normal way, maybe worse because now you don't have auto-increment PPU address, so I am not really sure where I am going with that idea.

Edit:
I realized on the way home that the PPU /A13 won't work, it will always enable the RAM, out of control of the MMC5... So that can't actually work that way.
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

Maybe my idea of additional dual-port ram was too extravagant. There is no register for switching fourth nametable nor pins for controlling /RD & /WE for the PPU side.

Knowing that in first mode you can use those two pins as general input/output (useful for driving any kind of two wire protocols like I2C - for EPROM memories), probably the second mode is just for utilizing them as /OE & /WE for some arbitrary external chip whose IO regs can be placed at $5800 (like extra audio chip - AY8910 or anything you can imagine). Or maybe this is remains of some debug device that was used in factory to test the chip.

Very interesting. It has to be both 81 and 82 grounded at the same time? When you release them, does it always automatically get out of reset and start functioning again or do you ever have to trigger a gap in M2 to unlatch?
M2 was cycling all the time. I just grounded both of them (by 1k resistors) and it went into reset state. During reset state, it was not accepting commands (like writing to 02 to $5104 and reading from $5c00-$5fff still returnedzeros).
I had to disconnect one or two of those pins from GND and then write 02 to $5104 to make reads from EXRAm return non-zero things). No idea why this is two-pin reset. Maybe it is some comparator or place to connec two batteries and when they are grounded, MMC5 detects them as brown-out).
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

krzysiobal wrote:Maybe my idea of additional dual-port ram was too extravagant. There is no register for switching fourth nametable nor pins for controlling /RD & /WE for the PPU side.

Knowing that in first mode you can use those two pins as general input/output (useful for driving any kind of two wire protocols like I2C - for EPROM memories), probably the second mode is just for utilizing them as /OE & /WE for some arbitrary external chip whose IO regs can be placed at $5800 (like extra audio chip - AY8910 or anything you can imagine). Or maybe this is remains of some debug device that was used in factory to test the chip.
Yes I suppose that sounds about right. We still don't really know why on earth they would have connected these pins together. That seems like a clue that we don't really understand, for some intended function. It has 2 different output modes that we know about. Maybe it has 2 different input modes somehow too. Set one as output, the other as input, and something could get enabled when reading or writing $5800... Seems like a strange way of doing things, but there must be some reason to connect those together. I can think of no other explanation than one being output and one being input. It can't be an ID thing with SL3/CL3 jumpers, or else there would be just a separate jumper to GND for each pin (you don't get more than 4 combos this weird way or anything). If you swap those jumpers as they are, one gets GND and the other floating. Close both, they both get GND. Those are not normal combinations, and that must be a clue. It persists on different boards too, it isn't just a weird quirk on 1 board.

I got my SMB 2J cart today. It doesn't work. Waaaa.... Black screen. I opened it and it does have the 3 big DIPs inside. However, the yellow case is one of the typical newer/thinner/cheaper ones. Will see if I can remove the W27C010 ROMs and dump them. If anything other than the glob is broken I will fix it, otherwise the ROMs will probably be transferred into an FC Wizardry if MMC3 is the right mapper.
User avatar
Ben Boldt
Posts: 1148
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I got the RAM chips today! Not tested yet. They appear pretty legit and have no signs of being soldered before. Will try putting one into my MMC5 socketed cart and using all the PRG-RAM lines we know about now! :D

Off topic (not really worthy of its own thread): With the SMB2J cart, I tested all connections of the PRG-ROM to the edge connector and all was good. Then I removed the EEPROMs and dumped them. I put an ines header set to MMC3 and put them into a file and it did run in fceux. So I am thinking it is either the glob or the RAM chip. The ROM dump itself seems quite similar to loopy's MMC3 SMB2J but definitely has a small percentage of extra / different data. In areas where loopy's is all 00s (for example), this ROM has data there. Maybe it is an older revision of loopy's hack with unnecessary stuff still left in there? Anyway, will probably just scavenge the EEPROMs, reflash with loopy's latest, and hack up my Wizardry cart for this, which I got for just such a purpose. Anyone curious about this ROM dump should send me a PM.
Post Reply