It is currently Mon Feb 18, 2019 12:48 am

All times are UTC - 7 hours

Post new topic Reply to topic  [ 16 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Jan 21, 2019 6:46 pm 
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
I zoomed out my scope and found bad news with Pin 3 = 1, Pin 12 = 0:

tek00059.png [ 34.32 KiB | Viewed 1054 times ]

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.)

tek00060.png [ 38.67 KiB | Viewed 1054 times ]

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[i] 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.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group