MMC6 (Startropics) pinout findings

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

Moderators: B00daW, Moderators

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

Re: MMC6 (Startropics) pinout findings

Post by Ben Boldt » Mon Jan 21, 2019 6:46 pm

I zoomed out my scope and found bad news with Pin 3 = 1, Pin 12 = 0:
CPU R/W went low for a moment where the scope shots are triggered. This caused all CHR address bits to go high (as expected), then after some time, each individually went low sort of randomly. Though, if I repeat the test, they are repeatable, they move around only very slightly. In the scope shot, digital channel 0 - 7 correspond to CHR A10-A17. I hooked analog channel 4 to CHR A10 (same as digital channel 0). Also, I loaded CHR A10 with a 1k resistor to GND, and it did not change any timings. Nothing changed when I did a 1k pull-up to 5V either. The CHR and PRG pages selected are not lost from any of this. No difference if I float pin 12 instead of drive it low. It doesn't seem to like it if I drive 2.5V (seen below). 3V+ acts the same as 5V. (Pin 3 voltage dragging down is my bench supply hitting current limit, which is set only slightly higher than normal operating current.)
I would imagine that the disturbances seen on the PRG lines could explain the semi-random CPU crashing. I made sure to set both PRG pages differently and I checked each $1000 address (i.e. $0000, 1000, 2000 ... f000). Everything was normal with 3=1,12=0, including the non-changeable pages. Though there are glitches as seen in the scope shot, nothing that I have tried with pin 3 or 12 has actually changed the PRG page, and that makes it harder to explain the 100% consistent 500 Hz triangle channel thing. Somehow the Startropics program is doing some very specific audio writes the same every time, immediately when I go into any non-standard pin3/pin12 combination. And not interjecting its normal music, and nothing crashed. It seems odd to me how consistent this is, versus the inconsistent nature of an internal bias bleeding down (which is what this looks like). I feel like Startropics detected something and it is telling us something with that tone.

Also, as I was doing this, I made a button in my GUI as follows:
for(int i = 0; i < 0x40; i++ )
write i to $8000
write value from table to $8001

The table contained 64 numbers I generated randomly, then hard-coded them into the table. The MMC6 did use the last 8 values, confirming that it did still ignore bits 3 and 4 in register $8000. No surprises there. I clicked my button again in each combination of 3 and 12, and it did not affect the all 0 / all 1 CHR address bit behaviors.

I have to admit, this behavior is strange and intriguing -- CPU R/W and M2 affecting CHR page, and CHR A13 behaving differently... But it seems more like the MMC6 is just out to lunch.

Post Reply