6522 handshaking questions

[Dan Moos]

SOLVED!

Its solved, but I'm surprised at what was happening. Consider the following psudo-code:

Code: Select all

SET CA1 = low to indicate DATA READY //this also sets CAS2 HIGH, as per the datasheet
while (CA2 == HIGH) {} //wait for CA2 to trigger LOW
SET CA1 = HIGH // reset CA1

what I saw on the scope was that my loop was quitting before CA2 went low! Further investigation showed a ~11 nS delay from when I set CA1 low, to CA2 responding. Surely such a short delay wouldn't matter with a CPU running at 1 MHz, and an MCU running at 8 MHz, right?

I decided to find out, and put a 1 millisecond delay, before my "check CA2 loop". Voila, it worked! I dumped the hard-coded delay, and now wait for it to go HIGH, before waiting for it to go LOW, and yup, still works!

Okay, so the fast running MCU was starting its loop before the VIA was setup. It just doesn't seem possible to me that even with the MCU running 8 times faster than the CPU, that 11 measly nano seconds would matter, but here we are. If my math checks, that means a clock cycle for the AVR is 125 nano seconds. So that delay is a tenth of a cycle. How is this happening? Even accounting for the 2 clocks being un-correlated?

[gfoot]

I had a similar issue but in the opposite direction, note that I initially polled for CA2 going high again but had to comment those lines out. It is why I said there seem to be race conditions that aren't really avoidable. Configuring the Arduino to give an interrupt on the transition of CA2 should give better results I think.

I also made the 6502 wait for an input before sending any data, so that the 6502 could be powered up first, then the Arduino, and neither would get confused by signals on pins that weren't initialised yet. Hardware pull-up resistors may help prevent that too.

There are certainly a lot of things that can go wrong, besides the protocol itself!