Oh cool - I am glad you were able to figure that out, and thanks for sacrificing your CL3 jumper.
I genuinely did not know that the right time to make address changes was when M2 is 0. I will do that from now on.
It looks like the CHR banking is not reset from stopping M2 toggling. Since my PPU address bus is just floating, which ends up all 1s, I am not getting a very good representation of the actual banking that is going on, but the extended CHR address bits do flip one way, stay for a while, flip the other way, stay for a while, during this test. If it was resetting, I think it would mostly stay the same, and show little glitches as it changed and reset back right away.
I never did witness the PRG banking change (haven't checked the results this morning yet), so it makes sense that one is reset by delay in M2. I would probably not have seen the said glitches on the extended PRG bits unless I had my scope hooked to them or something.
Edit:
krzysiobal wrote:Wiki says that:
In other words, CL mode passes the lowest PPU address bits straight to CHR ROM, while SL mode runs them through MMC5. SL mode allows the MMC5 to perform smooth vertical scrolling in split mode, while CL mode does not. Nearly all MMC5 cartridges use CL mode - it is not known why SL mode was not used instead: possibly ROM speed issues.
But I analyzed all the MMC5 PCBs from botgod and no single one uses SL mode.
The wiki also said that there are 2 versions of MMC5: "MMC5" and "MMC5B". I think we have some work to do on the wiki. As we find things that seem somewhat conclusive, I have been (and I will continue to) add them on there as we go.
I will play around with CHR address ranges and see if I can affect either of these pins. They could be bi-directional pins. It seems quite odd to connect together 2 inputs, and not connecting them to gnd or vcc. There must be something more to that.
Edit 2:
In summary of the test, the only pins that ever changed after over 1,000,000 writes were the bankswitched CHR address bits. None of the unknown pins, and none of the PRG address bits. I had all PPU address bits = 1 the whole time.
The CPU address bits were being controlled to do the writes and reads, and at the time of sampling these bits, the CPU address would always have been $5208.
Looking at the writes in the range $5120 to $512A that caused a CHR bankswitch:
Code: Select all
Range $5120 - 5127:
A19 A10 SL3 CL3 A2 A0
| | | | | |
0011 1111 11 1 1 111
Range $5128 - 512A
A19 A10 SL3 CL3 A2 A0
| | | | | |
0000 0000 00 1 1 111
I got a reasonably even distribution of writes that triggered the change of A17 through A10, also really even distribution of the value that was written. I did observe one single write of $00 that triggered a bankswitch, but my test observed no write of value $FF that triggered it. It is completely possible that the random test just never hit that combination.
5120: 31
5121: 21
5122: 28
5123: 25
5124: 23
5125: 17
5126: 19
5127: 21
5128: 70
5129: 58
512A: 56