Commander X16

In this particular implementation, the upper 8 bits of the 24-bit address are always ignored. Fixing this while retaining X16 compatibility would require a CPLD and a major architecture change to the board. On my latest PCB, I ensured that it was electrically compatible with the 65C816, but nothing beyond that.

The issue I fixed was a marginal timing condition on VERA where it snapped the address and data bus on writes at the rising edge of /WE. The precise reason this did not work is not clear to me, however the general reasons were: the datasheet specifies only 10ns from the falling edge of PHI2 when the write address and data are guaranteed to be held on the bus; the propagation delay of the NAND gate that drives /WE eats up most of that time; the stray capacitance of /WE on the board eats up a little more; the level shifter on VERA eats up a tiny bit more; I *think* that VERA sees /WE fall ~1-2ns before the end of the holding window. For some reason that 1-2ns isn't enough and VERA would occasionally catch some signals transitioning and end up with a corrupted write.

On the 65C02, this pretty much always ended up being the correct data written to the wrong address. In particular, for reasons not at all clear to me, it was always, or almost always, A2. I worked around the issue on the boards I took to VCFMW last weekend by adding a 30pF cap on A2. This would slow A2 falling from logic 1 to logic 0 by about 1ns and VERA would always catch the correct value. The 65C02 write value was always correct because the CPU doesn't start slewing those until well after the falling edge of PHI2 (except when writing the return address on the stack following a JSR or interrupt, but hopefully nobody designs a computer where VERAs IO windows overlaps the 6502's stack page.)

On the 65C816, the data lines switch to the address bank somewhere around 10.5-12ns after the falling edge of PHI2. I don't think VERA ever saw a write that wasn't $00 (the address bank of everything in emulation mode).

The fix was to sample the address and data bus on every VERA clock edge (every 20ns). When /WE is deasserted, the snapped bus state is the one seen on the last clock edge. There's a voice in the back of my head saying that there may be a metastability in there if VERA's clock edge is very close to /WE deassertion, but I've yet to see anything over millions of read/write cycles. I tried to avoid this by using the second-most-recent bus state, but that did not work. I'm not sure why.

More HW savvy readers may ask the obvious question of why I needed to add capacitance to VERA when Kevin's PCB did not. The most likely answer (to me, anyway) comes from a size comparison of the two PCBs:



Kevin's board is micro-ATX and mine is mini-ITX. The trace length of the address and data lines on the official board are 2.5-3 times longer than mine. Those longer wires necessarily have more stray capacitance, and one doesn't need a great deal of additional capacitance to get it working. Considering all of the wires on the official board have to cross nearly the full width of the micro ATX board *twice* and then some, it seems to make sense.

The reason I had to dig down on this timing issue and not continue using a 30pF cap on A2 is that on my latest board (the green one in the first post) I tightened up my trace lengths even more and now VERA was missing A4 and occasionally A0. While pondering the exact cause and solution to the problem, my brain wandered back to the discussion I had with the other retro hardware experts Sunday evening and then had my eureka moment: the issue causing my current board to misbehave worse than the previous one and the issue preventing 65816 from working on the board had the same underlying cause: /WE deassertion wasn't seen by VERA until we were right on the edge of missing the correct bus state.

After getting the board to boot from 65C02 without adding more load caps, I swapped in a 65C816 to test the theory. After removing the 30pF load cap from A2, it worked!