I'm just sitting here reading through Disch's mapper doc for MMC1.
Then it hit me...I think. I'm not sure if I just missed the bus on this and everyone else has already figured this out...
Of course...in the INC $FFFF case:
The 6502 issues "back-to-back" writes, not toggling RW between. If the MMC1 address decoder is negative-edge-triggered on RW, that would explain why the second write is ignored.
Here's a Visual6502 trace of a program that is nothing more than
In cycle 6 of course RW goes back high to do the opcode fetch. Note there's no transition on RW between cycles 4 and 5.
So perhaps emulating MMC1 like: keep track of the current CPU cycle of a write and "ignore" a write in the immediately-following CPU cycle is correct?
Then it hit me...I think. I'm not sure if I just missed the bus on this and everyone else has already figured this out...
001.txt wrote:
Consecutive writes that are too close together are apparently ignored.
Of course...in the INC $FFFF case:
001.txt wrote:
you know that this will read $FFFF (getting $FF), write that
value ($FF) back to $FFFF, increment it by one, then write the new value ($00) to $FFFF. This results in
two register writes: $FF, then $00.
value ($FF) back to $FFFF, increment it by one, then write the new value ($00) to $FFFF. This results in
two register writes: $FF, then $00.
The 6502 issues "back-to-back" writes, not toggling RW between. If the MMC1 address decoder is negative-edge-triggered on RW, that would explain why the second write is ignored.
Here's a Visual6502 trace of a program that is nothing more than
Code:
$0000: INC $FFFF
$0003: KIL
(data at $FFFF is $00 -- couldn't get the sim to accept ?a=ffff&d=ff)
$0003: KIL
(data at $FFFF is $00 -- couldn't get the sim to accept ?a=ffff&d=ff)
Code:
cycle ab db rw Fetch pc a x y s p
0 0000 ee 1 INC Abs 0000 aa 00 00 fd nv‑BdIZc
0 0000 ee 1 INC Abs 0000 aa 00 00 fd nv‑BdIZc
1 0001 ff 1 0001 aa 00 00 fd nv‑BdIZc
1 0001 ff 1 0001 aa 00 00 fd nv‑BdIZc
2 0002 ff 1 0002 aa 00 00 fd nv‑BdIZc
2 0002 ff 1 0002 aa 00 00 fd nv‑BdIZc
3 ffff 00 1 0003 aa 00 00 fd nv‑BdIZc
3 ffff 00 1 0003 aa 00 00 fd nv‑BdIZc
4 ffff 00 0 0003 aa 00 00 fd nv‑BdIZc
4 ffff 00 0 0003 aa 00 00 fd nv‑BdIZc
5 ffff 00 0 0003 aa 00 00 fd nv‑BdIzc
5 ffff 01 0 0003 aa 00 00 fd nv‑BdIzc
6 0003 02 1 unknown 0003 aa 00 00 fd nv‑BdIzc
6 0003 02 1 unknown 0003 aa 00 00 fd nv‑BdIzc
0 0000 ee 1 INC Abs 0000 aa 00 00 fd nv‑BdIZc
0 0000 ee 1 INC Abs 0000 aa 00 00 fd nv‑BdIZc
1 0001 ff 1 0001 aa 00 00 fd nv‑BdIZc
1 0001 ff 1 0001 aa 00 00 fd nv‑BdIZc
2 0002 ff 1 0002 aa 00 00 fd nv‑BdIZc
2 0002 ff 1 0002 aa 00 00 fd nv‑BdIZc
3 ffff 00 1 0003 aa 00 00 fd nv‑BdIZc
3 ffff 00 1 0003 aa 00 00 fd nv‑BdIZc
4 ffff 00 0 0003 aa 00 00 fd nv‑BdIZc
4 ffff 00 0 0003 aa 00 00 fd nv‑BdIZc
5 ffff 00 0 0003 aa 00 00 fd nv‑BdIzc
5 ffff 01 0 0003 aa 00 00 fd nv‑BdIzc
6 0003 02 1 unknown 0003 aa 00 00 fd nv‑BdIzc
6 0003 02 1 unknown 0003 aa 00 00 fd nv‑BdIzc
In cycle 6 of course RW goes back high to do the opcode fetch. Note there's no transition on RW between cycles 4 and 5.
So perhaps emulating MMC1 like: keep track of the current CPU cycle of a write and "ignore" a write in the immediately-following CPU cycle is correct?