I've also verified M2 to be used for sensing and blocking the second write during RMW instructions which is relied upon for games like Bill and Ted.
Fumarumota wrote:
So, correct me if I'm wrong, RAM at $6000-$7FFF will be selected when the CPU is reading/writing with A14 and A13 high, plus when A15 from the CPU is low and addresses are "stable" (/ROMSEL = 1) and M2 is high(which is when A15 in /ROMSEL is "ready to be latched")?
I might be misunderstanding your statement, but A15 doesn't get latched by /ROMSEL. A15 is used to generate /ROMSEL which is the cause of the delay.
The initial part of your statement is correct, but /ROMSEL = 1 and M2 high doesn't signify "addresses are stable", as those two signals are high in two separate cases. The first case is during memory accesses to $8000-FFFF, and the second is $0000-7FFF. So they are actually both high during every memory access creating the problem..
The first case is the problem during small time delay between /ROMSEL and M2, by definition when A15 is high, /ROMSEL = inverse of M2. Else if A15 is low, /ROMSEL = 1. So when A15 is high, there is a small time period after M2 goes high before /ROMSEL goes low. If you sense durring that small delay and A13/14 are both high, you'll erroneously sense a read/write from $E000-FFFF as a read/write from $6000-7FFF.
The second case is after that propegation time has occured and the one you are looking for during actual accesses to $6000-7FFF.
The cart doesn't get A15, and so the only option you have is to filter out that erroneously sensed memory access. Otherwise mapper writes to $E000-FFFF will corrupt WRAM, erroneous reads don't actually cause a problem. If you can, the best way to handle this is to delay the M2 signal to place it's rising edge after the falling edge of /ROMSEL. Otherwise you can filter out the small glitch in your generated WRAM /CE signal.