jburks
commented
1 year ago Revisiting this, and testing deeper, the true issue was determined that the data bus was sampled too late. For reasons that are not clear to me, it appears that there is a delay of a few nanoseconds between VERA detecting the falling edge of /WE and VERA sampling the address and data busses. That small delay is enough to push the sampling of those busses just past the 10ns hold time.
This issue with the data bus isn't seen on 6502 because that CPU holds the data bus value well beyond the 10ns hold time in nearly all cases (pushing the return address onto the stack following a JSR or interrupt being the only exceptions I have seen).
This issue with the address bus isn't seen on the official prototype hardware because the drive strength of the address bus signals is weaker and the stray capacitance on the wires retains their value for longer. An attempt on unofficial hardware to eliminate this problem, before it was understood, by minimizing the length of address bus signals and ensuring good ground return made the issue worse as more of the address bus signals got cleaned up.
An experimental work-around was implemented where the address and data busses are continuously sampled on both clock edges and the oldest sample is used when the falling edge of /WE is detected. The board has correctly come out of reset with a W65C816S installed and successfully run all applications following this.
I connected a 65C816 to my X16 hardware today and the ROM was stuck waiting for VERA ready. Looking at the logic analyzer trace, I suspect that there may be an issue of propagation delay or related timing during a write. The read always comes back with $00. My suspicion is that the write data is sampled too early, but this probably needs to be tested in simulation.
In the logic analyzer capture below, the A1 marker is at the start of the write instruction
lda #42/sta $9F20and the A2 marker is at the start of the read instructionlda $9F20.