I may have been a bit too optimistic in my claims of ease when working with VERA. VERA's first target is 6502 and I've spent all weekend trying to get my breadboard 6502 computer to work with it. I was ultimately successful but it was quite a mess getting here. Most of the time was spent staring at another unsuccessful run wondering how I might investigate further since the symptoms were always "VERA returned $00 when reading the register back." After lots of head-hitting-against-the-wall and some clever debug hacks inserted into the VERA design, I finally found the root cause. After a couple hours of failed workarounds, I finally hit on one that worked:
![image.thumb.png.e2477c17ab44a14ee961464561c64e5b.png](<___base_url___>/applications/core/interface/js/spacer.png)
100pF capacitors added to the 3.3V level-shifted side of the A4-A0 signals to slow them down a few nanoseconds and give VERA time to sample their intended value. I feel dirty after doing that. I'm not sure how many showers that hack calls for. Regardless, communication appears to have become reliable after that, however the oscilloscope can barely see a difference between the two:
![image.thumb.png.06dd517a11eb483794ab66efc1830a57.png](<___base_url___>/applications/core/interface/js/spacer.png)
(No capacitor on the left, 100pF cap on the right; 10ns/5V per division; cyan line is the WE# signal, magenta line is A1)
The issue was the generation of CS#/WE# signals. One of them has to de-assert for VERA to sample the address and data busses. The normal way to do this is to combine one with the clock; e.g. WE# = ~(PHI2 & ~RWB) will drive the WE# signal low (asserted state)
on the high phase of PHI2 during write cycles. When PHI2 goes low, the WE# signal will de-assert and we have 10ns to sample the address and data bus. That 10ns is a much harder deadline than I had thought. I couldn't get writes to VERA registers to go to the correct register because the propagation delay of a single gate plus the slew rate of the logic plus the setup time of VERA's IO pins was too long and the address bus started slewing to the address of the next instruction before it had been sampled. The data bus value appears to be retained much longer since the CPU is going to set its data lines to a high impedance state in preparation for the RAM or ROM to service the next instruction fetch, but the address bus is actively driven by the CPU and was changing almost immediately after the address hold time expired.
I know that at least some of the issues were caused by inductive and capacitive effects inherent to putting an entire computer on a breadboard. According the scope, the fall time of the clock was 23.8ns! I would hope that on a manufactured PCB, the signaling would be much cleaner.