6502.org

Your code is on my list to try out.

If the RAM is known to be good in another system then that just leaves something like a bad/incorrect connection. if the circuit is configured as per the diagram it should be working

Yes, I had that in mind when writing the test code. You'll notice that there's a write to the VIA between filling the RAM with test values and verifying those values, which should catch cases where the decode is incorrect.

Despite having a fair number of bypass caps on your prototyping breadboard, I would suggest placing a 0.1uF directly at the SRAM chip to pins 14 and 28. I would also note that there's other differences between your implementation and Garth's original schematic. On U3b, move pin 5 directly to +5V and also use the PHI2 out on the CPU to drive U3a pin 1 and the 65C22 clk line. All are simple changes.

Lastly, I would also look to meter all of the lines for the SRAM to ensure your don't have any intermittent or bad lines between the SRAM and the CPU.

So I finally found out what's wrong with the circuit. The quality of that breadboard was so bad that the VIA didn't get high enough voltage to register a one although I did measure it and it looked OK. When I changed the breadboards to Global Specialities ones everything just started to work. So moved on replacing the 74XX00 with an ATF22V10 GAL and that works just fine as well. So my next SBC will have a GAL as an address decoder instead of a Lattice MACH4A.
All's well that ends well.
BTW the old breadboards have been binned, any prototyping will hereinafter be done with GS breadboards.

Ah, the joys of dynamic versus static behaviour. You have no idea how much I have to explain to people who *should* know better that transient behaviour sometimes matters more than the steady state.

What did you use to program the ATF22V10?

I used an XGecu PRO TL866II plus, that is the original programmer and not a clone.