MMC5 Hacking Adventures

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

Moderator: Moderators

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

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

lidnariq wrote:Remember that Krzysiobal said that the timeout is 11us, not ms. You may need to have the PIC fake a series of dummy reads to some unrelated address (0 would be good) to speed things up enough.
Oh crap, that's probably the problem. Wow that was a bad mistake, I am thinking this microcontroller thing might have been a complete waste of effort because of that.... I know that I can't update the IO expanders that fast. Will have to rethink this I guess. Not sure, I might want to use a real Nintendo and flash PRG ROM now. That sucks...

Edit:
It takes me at least 74 usec to update an IO expander. I can't control precisely where each byte gets acknowledged and therefore makes it out to the IO expander pins. Deal breaker on that one. But there is always a way. I have these L'Empereurs, I will wire one up with a flashable PRG-ROM. I like not using the Nintendo because then I am in complete control of everything and I don't miss anything.

Edit 2:
I do have direct control of M2 and CPU R/W. In theory, I could keep M2 trotting along quite fast while setting up data and address busses and set/clear CPU R/W with high precision. But then reads get screwed up because I can't guarantee that the IO expander reads with M2 high. So I would have to make the CPU data bus all direct control too. Possible I guess but not sure I want to commit to invest more into this slow thing just yet. It is great for stuff that doesn't reset - Maybe it keep it as setup A for slow non-normal-NES controlled stuff and work on setup B with a real famicom. Setup B would not have been able to show us exactly how the scanline detection works, for example.

Edit 3:
You know, I don't have the +batt pin hooked up to anything -- I wonder if that is necessary in order to run the internal RAM? I will go back tomorrow and give that a try. Also, I will go ahead and give the hardware timer a try at this slow speed and see what happens.

Edit 4:
The +batt seems doubtful because I measured that pin tonight on a L'Empereur with a dead battery and it did not go up in voltage when run in a Famicom. I would have expected 5V to appear on this pin when running if it were necessary.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

What signals do you currently have on the I/O expanders vs the PIC's pins?
You could probably get away with just M2, R/W, D0-D7, /ROMSEL and A14 on the PIC itself, and everything else via the I/O expanders.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I have M2, CPU R/W, PPU /RD and PPU /WR on the Pic right now, everything else on the IO expanders. I do have 29 5V-tolerant pins available on the Pic. I should be able to put all of that and the whole CPU address bus on there. I ended up using a dsPIC33FJ64GS606 which is more RAM but only 64 pins vs the 80-pin '32GS608 that I initially was using. But this 606 micro is known-good, it came from a scrapped board that never got used (it passed blank check when I first rigged it up). It is OK speed, it runs at 40MHz, but most importantly I am very familiar with this particular micro.

I want to probe each unknown pin when turning on and off a 1.79MHz square wave into M2. In case any of them are affected by it, maybe it could have something to do with this reset function. I have not yet definitively seen this reset occur with my own eyes so I am very curious to reproduce it and see what else might be going on -- not that I doubt Krzysiobal. I just have a need to see it and poke at it happening to fully believe it.

I might be able to write to the hardware timer and then immediately start toggling M2 fast and watch /IRQ for example. And then try again with slowing down M2, basically repeating Krzysiobal's test. In addition, I don't think we know that the M2 reset necessarily disables or clears the built-in RAM. I could still be doing something wrong trying to unlock or write or read from it. This would become apparent with "setup B" if I wrote a 6502 program to do this test and put it on flash ROM. I think it is a good idea to have this 2nd setup that runs directly in a Famicom, for reality checks if nothing else.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I tried another 32GS608 today. I want that one because it has has a full 5V tolerant 16-bit port (Port B). I had the same problem with the I2C2 module though -- no acknowledge of the address. I went so far as to start a new project where all it did was set those 2 pins as GPIO outputs and toggle them and THAT didn't work either. We do use these micros where I work, so I might have to make it official to figure out what the heck is going on with that. Unlikely NOT to be my own fault. ;)

I did the test where I put in 1.79MHz into M2 and probed all of the unknown pins. I did find something sort of interesting with the PRG RAM control pins (including unknown pin 75) that might be showing us the exact reset time / behavior.

Quote from before when I also found pin 75 to behave like a PRG RAM pin when looking at voltages with and without pull-down resistor:
Ben Boldt wrote:
  • 76 (PRG RAM /WE) 4.96, 3.17
  • 72 (PRG RAM 1 /CE), 4.96, 3.17
  • 71 (PRG RAM 0 /CE), 4.96, 3.17
  • 75 (unknown), 4.96, 3.17
Of particular note: Pin 73 (unknown pin) did not behave this way, it kept its voltage steady with these tests.
M2 Timeout:  11.24usec
M2 Timeout: 11.24usec
M2 Timeout: 11.59usec
M2 Timeout: 11.59usec
The noise might actually be clocking it here, not sure.
The noise might actually be clocking it here, not sure.
4. Pin 75, inverted + 22nsec delay from M2.png
Seen here, the timeout can be triggered when M2 is held high for about 11.5 usec, definitely confirming Krzysiobal's findings. It is unknown if the timeout can be triggered with M2 held low.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

More attachments, comparison to the other known RAM pins. Very similar!
5. Pin 76 - PRG RAM !WE.png
6. Pin 71 - PRG RAM 0 !CE.png
7. Pin 72 - PRG RAM 1 !CE.png
Edit:
Confirmed M2 held low does trigger reset. Adjusted my scope and setup, new attachment.
8. Reset with M2 held low confirmed.png
Edit 2:
Another observation about pin 75. If power is applied to the MMC5 with M2 low, then later M2 starts toggling at 1.79MHz, pin 75 always follows M2, inverted, +22nsec, every time. But if I turn on the 1.79MHz into M2 before applying power, about 3 out of 4 times pin 75 will latch high once power is applied. The latch can always be cleared by stopping M2 and then starting it again.

While latched, if I remove and reapply power many times quickly, with M2 still running the whole time, it stays latched. If I remove power for several seconds and reapply, it is back to the 3 in 4 chance that it will stay latched.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

On the wiki, what exactly do you mean by "PRG RAM 2" ?
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

This pin behaves identically to PRG RAM 1 /CE, so PRG RAM 2 /CE is my best guess. What is on your mind, do you disagree? In my testing, the address bus was $7FFF, RAM /WE always high, RAM 0 /CE always high, RAM 1 /CE was M2 inverted, and pin 75 was also M2 inverted.

It seems like this theory would be enabling 2 RAM chips at the same time. That doesn't really make sense I guess. When I finally get my setup working, I should run through all CPU addresses and watch these pins. For now I will adjust that label in the wiki.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC5 Hacking Adventures

Post by lidnariq »

I mean, there are a few possibilities that come to mind...

1- It could be "PRG RAM /CE", for a single 64 KiB SRAM instead of two 32 KiB SRAMs. Another pin should probably be "PRG RAM A15", if so.

2- It could genuinely be "PRG RAM 2 /CE", for a third 32 KiB SRAM. Another pin should probably be "PRG RAM 3 /CE", if so.

Those are just possibilities that are immediately obvious. There might be other options.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

Thanks for catching me jumping to conclusions lidnariq -- it is hard to see that happening without a second set of eyes somtimes. I will need to do some more experiments to get a better idea on this.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

It was a rough night but I got it running. After figuring out the minimum setup delays before errors started appearing, and then doubling that amount, I have M2 at 50kHz (minimum speed to not trigger reset), and I was able to do the full multiply test with no errors. No I/O expanders were used for this test -- the whole CPU address and data bus is now available directly to the micro.

For the address bus, I used non-5V tolerant pins via this little circuit on each pin:

Code: Select all

                      10k ohm
         |---------+---/\/\/--- 5V
         |<--|     |
Pic _____|---|     +----------- MMC5
             |
            Gnd
I still have an issue to work on -- If I do attempt to read or write to an I/O expander, the code still pauses M2 for the duration of the transaction. I will have to work on that if I want to be able to use that without causing reset. But for now, I don't think that holds me back from playing with the internal RAM. I will give that a try soon.
Attachments
IMG_1574.JPG
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

I found out more about pin 75 today.

First I made a test that writes $5100 PRG mode. Then for all PRG addresses, when M2 is high it reads back RAM 0 /CE, RAM 1 /CE, and pin 75. In the address range $6000 to $7FFF:

RAM 0: high (inactive)
RAM 1: low (active)
75: low (active)
(outside this range, everything inactive)

Since I never enabled RAM mode in any of the PRG banks, I found this result to be the same for each PRG mode.

Next, I wrote $04 to $5113, which would select RAM chip 1. This had the same result, as expected.

Next, I wrote $00 to $5113, which would select RAM chip 0. In the address range $6000 to $7FFF:

RAM 0: low (active)
RAM 1: high (inactive)
75: low (active)
(outside this range, everything inactive)

Here is my theory on this:

Take L'Empereur for example. It has 2x 8kbyte WRAM, which uses 13 address bits. They could have laid out the board such that there was a 16kbyte WRAM location, with its /CE coming from pin 75, and now using PRG RAM A14. A single ROM could be written such that it keeps bits 1 and 2 the same in $5113. Then the board could be populated with 2x 8k or 1x 16k, whichever is available or cheaper.

It says in the wiki that there is a game that use 1x 32kbyte RAM. Is that right? Where does it get PRG RAM A15 from?


In other news, I was able to write and read back from the internal RAM. I filled it and played with the +$1000 versions of the DMC registers, nothing happened. It definitely could be my setup, but I found that I was able to set read mode in $5010 and I was still able to write raw samples to $5011 and they updated the DAC output. I wrote several values less than $80 to $5010, with and without bit 0 set, and writes to $5011 remained successful. Later on, possibly after a power cycle, I was able to get it into read mode again where it would not allow me to write to $5011. Again -- it might be my setup but I though it was interesting and worth noting.

Edit:
It looks like these 4 Koei games used 32k PRG-RAM:
  • Aoki Ookami to Shiroki Mejika: Genchou Hishi
  • Nobunaga no Yabou: Bushou Fuuunroku
  • Sangokushi II
  • Romance of the Three Kingdoms II (i.e. USA version of Sangokushi II)
I always forget about the 0th address bit. 32k makes sense, 2^15 = 32k, 15 address bits is A0 to A14... My bad.

Edit 2:
I should try writing $08 to $5113 and see if it affects pin 75.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

Today I tried writing these values to $5113:
  • $08
  • $F8
  • $FF
None of these had any effect on the range where pin 75 went active. I think I should try setting each bit 7 in registers $5114 - $5117, in each PRG mode in register $5100 and see if 75 shows any different behavior.

So far with what we know, I think a good label for the wiki would be:

71 -> PRG RAM 0 /CE **
72 -> PRG RAM 1 /CE **
75 -> PRG RAM /CE **

** PRG RAM 0 /CE and PRG RAM 1 /CE are selectable by bit 2 in register $5113. This allows the use of 2 PRG-RAM chips. PRG RAM /CE is not affected by bit 2 in register $5113.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

1. Yes, I can confirm - pin 75 is just 71 (/PRG0) && 72 (/PRG1). Before knowing that, I wanted to connect single 64K (62512) SRAM to MMC5, which would involve building logic-gate decoder.
Now it can be enabled using just this pin and /PRG0 (or /PRG1) can be used ad A15

Image

In the example above, pin 73 seems to alter its state around 125ns BEFORE (wtf?) every rising edge of M2. But in fact, it changes its value upon change of address on the addres bus, not the M2, but not does not happens for every address, I need to examine it.

---

pin 73 seems to be 0 when bit $5113.3==0 && CPU address (read/write - no matter) is between $6000-$7fff or $e000-$ffff. It is combinatorial (it changes with CPU address, not with M2)

Spikes on 72/75 at $e000-$ffff are just because of slight delay before M2 and !ROMSEL changes.

Image

---

pins 81, 82, 92, 29, 30 seems to be input with +5V pullup (voltage drops to 1.3V when shorting with 10k to GND, in contrary to SL3/CL3 where it drops to 0.45V - maybe just pullup is stronger)

pin 93 seems to be output

--

pin 93 drives 0 when bit $5116.2==0 && CPU address is between $4000-$5fff or $c000-$dfff
Last edited by krzysiobal on Mon Nov 12, 2018 4:16 pm, edited 3 times in total.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: MMC5 Hacking Adventures

Post by Ben Boldt »

Very cool stuff krzysiobal, I like what you found with pin 73 and 93, I wonder what that could be used for???

I did some testing today with PRG Mode ($5100) and each PRG bank ($5114,5,6,7). I tried each mode 0-3, and $7F and $FF in each bank register. I did this while monitoring the 3 PRG RAM /CE pins. I never found any place where 75 was not the 'AND' of the other two. Interestingly, though, I found that the RAM got enabled as follows:

Code: Select all

PRG-RAM /CE gets enabled in this extra areas, in addition to $6000-7FFF where it is always enabled:

        |  Bank 0 7F  |  Bank 1 7F  |  Bank 2 7F  |  Bank 3 7F
--------+-------------+-------------+-------------+-------------
Mode 3  |  8000-9FFF  |  A000-BFFF  |  C000-DFFF  |  none
Mode 2  |  8000-9FFF  |  A000-BFFF  |  C000-DFFF  |  none
Mode 1  |  8000-9FFF  |  A000-BFFF  |  C000-DFFF  |  none
Mode 0  |  8000-9FFF  |  A000-BFFF  |  C000-DFFF  |  none
It seemed to not care about mode. I set my scope to trigger on M2 gap larger than 10.5 usec and it never triggers in this test, so I don't think I am triggering reset. It could be that I am not writing the mode correctly. Any chance you could verify this table? If you get a different result, I probably have more work to do on my setup.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: MMC5 Hacking Adventures

Post by krzysiobal »

Yes, that's how MMC5 works - if high bit in each of those regs is 0, (value $00-$7F) then RAM in proper region ($8000/$a000/$c000), instead of ROM is enabled.
Post Reply