Basically, is their ominous background music that I'm missing like the swimmers in a shark film?
I think we've backed away from the nervousness about having a pair of reads only one Ø2 cycle apart, and rightly so. In any case, that isn't quite what I meant a few posts back when I mentioned "the potential booby trap that awaits if you start using additional VIA functions." Allow me to elaborate on the subject of interrupts.
When you replace an 8-bit read of the VIA with a 16-bit read, there's obviously an extra, unnecessary read cycle. We may be accustomed to thinking of read cycles as being harmless, but that's only true for ordinary memories and for simple IO devices. Most of us are aware that some of the fancier devices -- mostly IO but also certain memories such as those with sequence-actuated locking features -- may attach extra significance to a read. Beyond being a request to retrieve some data, the read also serves as a cue or semaphore. And if that cue gets sent erroneously it's no surprise that it'll gum up the works!
The chart below shows how several registers of the 6522/65C22 VIA are sensitive to this. A read of ORA, the ShiftReg, ORB, T2L or T1L has potential to alter what's contained in the Interrupt Flag Register. This behavior is a feature that can be used to streamline the Interrupt Service Routine. But it also means a spurious read of one of those registers can cause an interrupt to go unserviced... and this sort of problem can be treacherously misleading to troubleshoot because the code that misbehaves (the ISR) typically isn't the same code that generated the spurious read.
It's worth noting that Martin's cautiously proposed coding shortcut is not the only source of spurious reads; they can also arise during so-called Dead Cycles, which have been a perverse reality of 65xx bus behavior ever since the family originated. During the dead cycle, the CPU is typically performing some useful and necessary internal operation. But, although dead cycles are always reads (not writes), a problem arises if the address on the bus happens to touch a sensitive device.
When the 6502 was superseded by the 65C02, the new chip had certain features added which largely eliminated the risk of a dead cycle touching a sensitive device. (For example, during most dead cycles PC would appear on the address bus.) Then later for the 65C816 this feature was removed (!), but in its place we got the new VDA and VPA signals. VDA is low during dead cycles, and, acting solo, is usually sufficient for protecting sensitive devices -- see "Plan A" below.
But AFAICT the 65C265 isn't capable of outputting VDA and VPA... nor, I'm guessing, does it have the protective features offered by the 65C02! This means we're thrown back into the dark days of NMOS 6502.
But with careful coding and an awareness of how the hardware behaves, it's possible to avoid the maddeningly misleading bugs I mentioned. (For more on dead cycles, including some workarounds, see Drass's highly detailed document
here.)
Hmmm... does the IO of the
65C265 include read-sensitive registers? I haven't checked. But certainly an externally attached VIA will be vulnerable...
-- Jeff
