Thanks guys. My particular concern (which may not be the
correct concern!) is the parameter called THR in the MOS/Commodore datasheets--the 10ns period that begins when Phi2 falls to .4V during which the data being supplied to the 6502 is expected to remain valid.
To answer Garth Wilson's question: No, there is no 'LS' logic in there. The SRAM is connected directly to the 2A03. So what you're saying is: Because of this, when the /OE on the SRAM goes high and the data lines begin their transition to a high-Z state, the logic levels on them will decay at a sufficiently slow rate than the 10ns THR time is not a concern ... ? Of course, the datasheet for the SRAM does not declare a
minimum transition time.
In any case, it does seem to (mostly) work. Here's a short video of the thing:
https://www.youtube.com/watch?v=UM9OqdAa4GAI'll be tearing it apart tonight and rebuilding it with a larger SRAM. (And also using the Arduino's memory interface instead of bit-banging it like I'm doing right now.)
Unrelated to the question of the thread, but I'll mention it anyway: One of the problems I'm having is that, seemingly randomly, the 2A03 will not come out of reset. The bus remains high-Z, although Phi2 is oscillating at the correct frequency. The reset signal on the 2A03 has a pull-down resistor on it, and then the Arduino pulls it up after it's loaded the SRAM with the 6502 code. I've got an Epson programmable MEMS oscillator part supplying the clock for the 2A03, and it's got a rather nasty-looking waveform. I'm wondering if that could be the issue? Maybe I'll follow it with a Schmitt trigger inverter and see if that helps. The duration of reset doesn't seem to matter. I can hold it in reset for seconds, and still, perhaps one out of five times, it won't come out of reset when the reset signal goes high. Nuts!