6502.org

I am more or less following / using the schematic from the 6502 primer at (http://wilsonminesco.com/6502primer/addr_decoding.html) and using the /CS for the 6522s ANDed with PHI2 as the clock signal for a SN74LS273N.

It looks okay, except for the fact that the 74273 is too fast (typ switching high-to-low 18ns), but my data bus is only valid after 42ns (see attached screenshot of my logic analyser).

Is there a way to fix this, or am I on the complete wrong path here?

Let's see if I understand. You don't actually have any 6522s -- you're just re-purposing that decode signal, like this: Does this reflect what you're doing? If so, you'll do better if the AND is replaced by a NAND. That's because the '273 uses the rising edge of CK to register the new data. And you want that to happen at the end of the 65xx cycle, when Phi2 goes low.

-- Jeff

That's exactly what I am doing.

And your fix worked great! Thanks.

I have to say, I also NAND R/!W to the /CS signal as well, because I only want to use the data when I am writing to the output address:

Alright, and no great harm done. But from another point of view this extra precaution isn't really necessary, and the gate is wasted. Presumably you're in control of the code that gets executed, and if you don't code any reads of the '273's address then none will occur. [* note]

Fun fact (carrying this one step further). It's actually sometimes advantageous if reads do trigger the output register. I'm referring to the case where one has arranged things so the register triggers from an address which also activates RAM. This makes it possible to simultaneously write to the register and to RAM. Then later you can if you wish read that address, and the RAM will respond and tell you the value of the last byte that was output (and stored in RAM). That ability can be handy if, say, you want to increment the byte that was output, or alter just one bit of the byte that was output. In order to do so you need to know what was there before.

-- Jeff

[*] 6502 and 65C816 (but not 65C02) can in some circumstances do a spurious read from an address other than one that's been explicitly coded, and this can in some circumstances cause trouble -- for example if you take my suggestion and eliminate the "wasted" gate. I mention spurious reads only in passing. Suffice it to say the effect is rare, and both hardware and software remedies exist.