MMC6 (Startropics) pinout findings
Moderator: Moderators
MMC6 (Startropics) pinout findings
I updated the pinout on the wiki for MMC6 (MMC3 variant used only for Startropics 1/2).
https://wiki.nesdev.com/w/index.php/MMC6_pinout
I found pins 4 and 5 to have infinite resistance to all other pins (considering them n/c).
I found these 2 outputs:
Pin 6 = Inverted M2 output
Pin 16 = Non-inverted PPU A13 output
I also found that pin 26 is CHR A15.
The MMC6 has these additional input signals in Startropics, not present on the MMC3:
Pin 58 = CPU A12: Not used for the internal RAM -- this is something else.
Pin 28 = PPU /RD: Unknown purpose. Not being buffered through the MMC6 for the purpose of CHR /OE.
Pin 29 = PPU A13: Pin 16 is a buffered output of this signal, but not being used in Startropics. CHR /CE connects directly to PPU A13, so not sure why MMC6 still is getting this one as an input, or why the output was not used.
https://wiki.nesdev.com/w/index.php/MMC6_pinout
I found pins 4 and 5 to have infinite resistance to all other pins (considering them n/c).
I found these 2 outputs:
Pin 6 = Inverted M2 output
Pin 16 = Non-inverted PPU A13 output
I also found that pin 26 is CHR A15.
The MMC6 has these additional input signals in Startropics, not present on the MMC3:
Pin 58 = CPU A12: Not used for the internal RAM -- this is something else.
Pin 28 = PPU /RD: Unknown purpose. Not being buffered through the MMC6 for the purpose of CHR /OE.
Pin 29 = PPU A13: Pin 16 is a buffered output of this signal, but not being used in Startropics. CHR /CE connects directly to PPU A13, so not sure why MMC6 still is getting this one as an input, or why the output was not used.
Re: MMC6 (Startropics) pinout findings
Sometimes they added an OR gate, like in Sunsoft 4, to combine PPU /RD and PPU A13 to use ROMs with a single enable.
And sometimes, like the VRC7, they appear to have tried to do that and screwed it up somehow.
And sometimes, like the VRC7, they appear to have tried to do that and screwed it up somehow.
Re: MMC6 (Startropics) pinout findings
Yes, I verified you are exactly correct, pin 16 = PPU /RD || PPU A13. Will update.
For my testing, I have unknown pins (3,7,8,9,12) all floating, and all float to 0.
For my testing, I have unknown pins (3,7,8,9,12) all floating, and all float to 0.
Re: MMC6 (Startropics) pinout findings
Have you found any reason to think that pins 28 and 29 are used for anything other than an OR gate?
Re: MMC6 (Startropics) pinout findings
No, I have found no other function affected by 28/29 yet but I also haven't tested much yet. I am thinking that at some point I should put the board back together and:lidnariq wrote:Have you found any reason to think that pins 28 and 29 are used for anything other than an OR gate?
A. Disconnect 28/29, tie them low or high, see if it makes any difference
B. Try each combination of unknown input pins while playing the game.
Re: MMC6 (Startropics) pinout findings
CPU A12 is for internal RAM, my bad. MMC3 maps RAM from $6000-7FFF and MMC6 maps RAM $7000-7FFF, thus it needs CPU A12 to distinguish between $6xxx and $7xxx... So no surprises there after all.Ben Boldt wrote:Pin 58 = CPU A12: Not used for the internal RAM -- this is something else.
Re: MMC6 (Startropics) pinout findings
I reassembled the board with tape under these MMC6 pins:
3, 7, 8, 9, 12, 28, 29
I then soldered a magnet wire to each of these pins, through a 500 ohm resistor, each to its own switch that can be set to GND or 5V. I then tested with the title screen, flipping the switches.
I tried to see if I could find a RAM read protect or write protect by registering names and power cycling. I found no combination of switches that prevented me from reading or writing to the RAM.
I found that setting pin 3 high causes the CHR page to change and the triangle channel to always turn on to a particular note. The CPU will crash when attempting to exit the title screen to start the game with this pin high. CHR page returns to normal when switching back to GND but audio sometimes has some registers corrupted and sounds strange as it continues playing.
I found similar but different results with pin 12 when set low. With Pin 12, triangle channel always turns on with the same note as pin 3, but the CHR page is not affected. On the world map, the bottom 2 rows of tiles, which are normally black, become visible. When I walk around, which should scroll the map, the map does NOT scroll in any direction, but the bottom row of tiles updates like it normally would for scrolling. When I set pin 12 back high, instantly the background updates to where it should have scrolled to and the 2 bottom rows of tiles go back to black. Some tiles have the wrong palettes but causing the screen to scroll brings them back to normal. Sometimes a few tiles get changed from this and remain even when scrolling. When returning pin 12 high, triangle channel always remains on indefinitely and no additional music will play, even if I do it during the title and start the game where different music should start playing.
When setting pin 12 low when talking to Chief Coralcola, the background disappears, except for his mouth which keeps moving. The status bar on the bottom moves up by about 4 or 5 pixels. It does not move up by a full tile and Chief's mouth does not change position.
Setting pin 12 low and pin 3 high at the same time causes the screen go a little crazy. The tile data changes rapidly, not with any recognizable pattern. The screen looks like it is jerkily scrolling vertically but the palettes stay in place. You can clearly see the 2x2 tile palettes colors staying completely still on the screen. Flipping both switches back, everything goes pretty much back to normal, with slight corruptions and the triangle channel stuck with no music playing like before.
I was not able to find any effect during gameplay from toggling pins 7,8,9 (unknown pins) or 28/29 (normally PPU /RD, PPU A13)
3, 7, 8, 9, 12, 28, 29
I then soldered a magnet wire to each of these pins, through a 500 ohm resistor, each to its own switch that can be set to GND or 5V. I then tested with the title screen, flipping the switches.
I tried to see if I could find a RAM read protect or write protect by registering names and power cycling. I found no combination of switches that prevented me from reading or writing to the RAM.
I found that setting pin 3 high causes the CHR page to change and the triangle channel to always turn on to a particular note. The CPU will crash when attempting to exit the title screen to start the game with this pin high. CHR page returns to normal when switching back to GND but audio sometimes has some registers corrupted and sounds strange as it continues playing.
I found similar but different results with pin 12 when set low. With Pin 12, triangle channel always turns on with the same note as pin 3, but the CHR page is not affected. On the world map, the bottom 2 rows of tiles, which are normally black, become visible. When I walk around, which should scroll the map, the map does NOT scroll in any direction, but the bottom row of tiles updates like it normally would for scrolling. When I set pin 12 back high, instantly the background updates to where it should have scrolled to and the 2 bottom rows of tiles go back to black. Some tiles have the wrong palettes but causing the screen to scroll brings them back to normal. Sometimes a few tiles get changed from this and remain even when scrolling. When returning pin 12 high, triangle channel always remains on indefinitely and no additional music will play, even if I do it during the title and start the game where different music should start playing.
When setting pin 12 low when talking to Chief Coralcola, the background disappears, except for his mouth which keeps moving. The status bar on the bottom moves up by about 4 or 5 pixels. It does not move up by a full tile and Chief's mouth does not change position.
Setting pin 12 low and pin 3 high at the same time causes the screen go a little crazy. The tile data changes rapidly, not with any recognizable pattern. The screen looks like it is jerkily scrolling vertically but the palettes stay in place. You can clearly see the 2x2 tile palettes colors staying completely still on the screen. Flipping both switches back, everything goes pretty much back to normal, with slight corruptions and the triangle channel stuck with no music playing like before.
I was not able to find any effect during gameplay from toggling pins 7,8,9 (unknown pins) or 28/29 (normally PPU /RD, PPU A13)
Re: MMC6 (Startropics) pinout findings
That sounds like pins 3 and 12 somehow break banking.
Re: MMC6 (Startropics) pinout findings
Perhaps they're specialized chip reset signals?lidnariq wrote:That sounds like pins 3 and 12 somehow break banking.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: MMC6 (Startropics) pinout findings
I should look at the CHR A10-A17 pins while doing this for clues.lidnariq wrote:That sounds like pins 3 and 12 somehow break banking.
I thought that MMC3 started up in an unknown state, suggesting it didn't have a reset mechanism? Interesting thought, maybe they added it.Quietust wrote:Perhaps they're specialized chip reset signals?lidnariq wrote:That sounds like pins 3 and 12 somehow break banking.
What really baffles me is how this can trigger the triangle channel to turn on, always the same note, and the other channels to turn off. Always the same every time. How can this be possible?
Re: MMC6 (Startropics) pinout findings
I measure the triangle channel at 500 Hz when this happens.
Something new I found is if I power cycle lots of times with pins 7,8,9 = 1,0,0, (which is the opposite of how the PCB is wired), once in a while it will cause the game to crash right away. Once it has done this, it seems the MMC6 is latched in a condition where 1,0,0 causes it to crash. I can press reset repeatedly and it will crash every time. Changing 7,8,9 and pressing reset again:
000 crashes when entering town
001 OK
010 crashes at title
011 OK -- PCB's combo
100 crashes at title
101 OK
110 OK
111 OK
Switching to 1,0,0 or 0,1,0, it crashes again right away, before pressing reset, but I pressed reset anyway to make sure I didn't catch an intermediate combination or trigger something with switch bounces, etc. I repeated these tests many times, especially trying to get 110 to crash but it never did for me. Power cycling again clears this behavior and no combination of 7,8,9 can cause any noticeable effect or crash.
I tried again power cycling with the original PCB's combo 0,1,1, then once running, change the switches to 1,0,0. It was able to get latched that way, showing that the power-on values of 7,8,9 does not affect getting into this mode or not.
I power cycled 55 times, and it got into the mode 15 / 55 times = 27.27%, which seems reasonably close to 25%, potentially suggesting 4 modes, 1 of which listens to 7,8,9 and triggers this crash. That is making a lot of assumptions but still worth considering.
Playing a bit more with this, I got into the crashy mode again, with switches set to an OK combo, then got to the menu where you enter your name. I switched to a crash combo and it didn't crash, but the sound effects when entering characters were glitchy and distorted. Switching back to an OK combo, the sound effects are normal again. both crashy combos distorted the character entry sound effects the same way. Combo 000 did not have any effect on this screen that I could tell.
Something new I found is if I power cycle lots of times with pins 7,8,9 = 1,0,0, (which is the opposite of how the PCB is wired), once in a while it will cause the game to crash right away. Once it has done this, it seems the MMC6 is latched in a condition where 1,0,0 causes it to crash. I can press reset repeatedly and it will crash every time. Changing 7,8,9 and pressing reset again:
000 crashes when entering town
001 OK
010 crashes at title
011 OK -- PCB's combo
100 crashes at title
101 OK
110 OK
111 OK
Switching to 1,0,0 or 0,1,0, it crashes again right away, before pressing reset, but I pressed reset anyway to make sure I didn't catch an intermediate combination or trigger something with switch bounces, etc. I repeated these tests many times, especially trying to get 110 to crash but it never did for me. Power cycling again clears this behavior and no combination of 7,8,9 can cause any noticeable effect or crash.
I tried again power cycling with the original PCB's combo 0,1,1, then once running, change the switches to 1,0,0. It was able to get latched that way, showing that the power-on values of 7,8,9 does not affect getting into this mode or not.
I power cycled 55 times, and it got into the mode 15 / 55 times = 27.27%, which seems reasonably close to 25%, potentially suggesting 4 modes, 1 of which listens to 7,8,9 and triggers this crash. That is making a lot of assumptions but still worth considering.
Playing a bit more with this, I got into the crashy mode again, with switches set to an OK combo, then got to the menu where you enter your name. I switched to a crash combo and it didn't crash, but the sound effects when entering characters were glitchy and distorted. Switching back to an OK combo, the sound effects are normal again. both crashy combos distorted the character entry sound effects the same way. Combo 000 did not have any effect on this screen that I could tell.
Re: MMC6 (Startropics) pinout findings
(sorry about the delay, I missed seeing this the first several times I read through) If PRG banking is somehow broken, and it jumps into the wrong code, all bets are off. Once on this bad code path, the only thing noteworthy about it is that it appears to be consistent ... which only implies that PRG banking is predictably broken, not random.Ben Boldt wrote:What really baffles me is how this can trigger the triangle channel to turn on, always the same note, and the other channels to turn off. Always the same every time. How can this be possible?
Re: MMC6 (Startropics) pinout findings
I am looking at the MMC6 again today. I hooked up more signals to help understand these unknown pins.
With all unknown input pins set the same as the Startropics PCB, except setting pin 3 = 1, I find that all CHR-ROM address bits (A10-A17) follow exactly CPU R/W. I tried writes to several different addresses. Setting pin 3 back to 0, the previously selected CHR bank is restored on A10-A17. In both of the screenshots, I had my CHR bank set to $AA.
With all unknown input pins set the same as the Startropics PCB, except setting pin 3 = 1, I find that all CHR-ROM address bits (A10-A17) follow exactly CPU R/W. I tried writes to several different addresses. Setting pin 3 back to 0, the previously selected CHR bank is restored on A10-A17. In both of the screenshots, I had my CHR bank set to $AA.
Re: MMC6 (Startropics) pinout findings
It seems that when pin 3 = 1, the CHR bank is overridden by either all 0s or all 1s, depending on M2, R/W, and pin 12.
The bank value overwritten follows (M2 && R/W) || (12 && R/W)
The MMC6 never appears to lose track of its original CHR bank, it will always restore the bank when returning to any 'normal' combination in the table. I did not find any sort of latching or edge triggering behavior. Everything seemed combinational. All of the tests I did were with function generator hooked to pin 3 or 12, doing CPU reads and writes.
Edit:
Revised combination 1,0,1,1. Specifically CHR A13 = 0, all others = 1 in this combination.
Value overwritten (CHR A10-A17, except A13):
(M2 && R/W) || (12 && R/W)
Value overwritten (CHR A13):
(12 && R/W)
All of this testing was done with PPU A10,11,12,13 all driven = 0. Will try other PPU addresses and see what happens.
Edit 2:
I have tested each and every case with all combinations of PPU A10, A11, and A12 and found no violation of the table above. In cases where I am in a 2kbyte CHR bank, CHR A10 is in fact still overridden per the table, even though it is behaving with its normal passthrough from PPU A10 to CHR A10 when not overridden.
The above testing was with PPU A13 always = 0. I also tried a couple additional combinations with PPU A13 = 1 and found no differences.
The bank value overwritten follows (M2 && R/W) || (12 && R/W)
Code: Select all
3 | 12 | M2 | R/W | Effect on CHR bank
-----+-----+-----+-----+-------------------------------------------
0 | 0 | 0 | 0 | Normal (Audio/CPU crash)
0 | 0 | 0 | 1 | Normal (Audio/CPU crash)
0 | 0 | 1 | 0 | Normal (Audio/CPU crash)
0 | 0 | 1 | 1 | Normal (Audio/CPU crash)
0 | 1 | 0 | 0 | Normal (Same as Startropics PCB)
0 | 1 | 0 | 1 | Normal (Same as Startropics PCB)
0 | 1 | 1 | 0 | Normal (Same as Startropics PCB)
0 | 1 | 1 | 1 | Normal (Same as Startropics PCB)
1 | 0 | 0 | 0 | CHR A10-A17 all 0
1 | 0 | 0 | 1 | CHR A10-A17 all 0 <- yes, zero
1 | 0 | 1 | 0 | CHR A10-A17 all 0
1 | 0 | 1 | 1 | CHR A10-A17 all 1, except CHR A13 = 0
1 | 1 | 0 | 0 | CHR A10-A17 all 0
1 | 1 | 0 | 1 | CHR A10-A17 all 1
1 | 1 | 1 | 0 | CHR A10-A17 all 0
1 | 1 | 1 | 1 | CHR A10-A17 all 1
Edit:
Revised combination 1,0,1,1. Specifically CHR A13 = 0, all others = 1 in this combination.
Value overwritten (CHR A10-A17, except A13):
(M2 && R/W) || (12 && R/W)
Value overwritten (CHR A13):
(12 && R/W)
All of this testing was done with PPU A10,11,12,13 all driven = 0. Will try other PPU addresses and see what happens.
Edit 2:
I have tested each and every case with all combinations of PPU A10, A11, and A12 and found no violation of the table above. In cases where I am in a 2kbyte CHR bank, CHR A10 is in fact still overridden per the table, even though it is behaving with its normal passthrough from PPU A10 to CHR A10 when not overridden.
The above testing was with PPU A13 always = 0. I also tried a couple additional combinations with PPU A13 = 1 and found no differences.
Re: MMC6 (Startropics) pinout findings
Attached example scope shots of how I built the table. I ran these tests with each combination of PPU A10,11,12.