Dr Jefyll wrote:
Maybe [a memory that needs protection from dummy cycles] exists and I just haven't heard about it yet.
BigDumbDinosaur wrote:
Slow memory might have a problem with the effects of a momentarily "bad" address on the bus that causes selection of one cell, followed in very rapid succession by the selection of a different cell
Momentarily bad addresses are routine; they can occur early in any Phi2-low period. So, if the memory you mention has trouble with dummy cycles then it'll also have trouble with non-dummy cycles, whose timing is just the same. As I noted
above, "The dummy aka dead aka invalid cycles are proper, fully formed bus cycles. It's just that their actions are not productive."
So, thanks for the remark but I don't feel it sheds any light on WDC's recommendation that VDA and VPA should be used to qualify all memory cycles. I'll bet that recommendation is just an instance of sloppy or at least overly-cautious, CYA doc. But caution isn't a bad thing, and I hate losing bets
so I'll stop short (but just barely) of saying, "All memories are immune to dead cycles."
[Edited to insert a more detailed elaboration:]
Alright, so,
are all memories are immune to dead cycles? If any exceptions exist,
here's the identifying feature.
Earlier I mentioned that some
I/O devices don't simply take a read or write at face value. For example, when you read the Interrupt Flag Register of a 6522 VIA, the chip does read the IFR. But, as an "extra," it also goes one step further and resets any IFR bits which were set. That's why havoc can result if a VIA's IFR should happen to get touched by an unintended read such as that which might result from a dummy cycle. Reading the IFR carries a meaning beyond its face value. The datasheet mentions this.
In the realm of
memory, is there anything comparable? ie, is there any kind of memory which, as a legitimate feature, attaches extra, implicit significance to being accessed? I've pondered at length; but, try as I might, I only came up with two candidates, as follows:
Some EEPROMs require a certain period to complete a write operation, and they include a feature that allows the CPU to determine when the period has completed. If the CPU reads back the data just written, the EEPROM deliberately returns incorrect data if the time delay is still in progress. All the CPU has to do is repeatedly read the device until correct data appears. As memory behavior goes, this is kinda wonky, but the scheme is effective. But can it tolerate an extra, unintended read resulting from a dummy cycle? With a moment's thought it becomes clear the answer is yes.
Less clear is the case of a certain category of specialized memories which have paging features built in. I haven't used these, but it's my understanding that manipulation of the features involves a specific "knock" sequence. That is, the memory performs normally but also is designed to "listen" for a certain sequence of accesses which, if detected, will update the paging feature. The question arises, could an unintended access from a dummy cycle corrupt the sequence and prevent its recognition? I don't know, but certainly this device can't accidentally be mistaken for an ordinary, everyday memory. If you read the datasheet you'll surely realize there's some "more than face value" significance to an access.
Now I've given the background that explains my (cautious) advice, already posted
upthread: Just do a quick sanity check. "Will a fully formed but unexpected access as described
here cause trouble with the memory I'm using?" If the memory you're using has any unusual, "more than face value" features they'll surely be detailed at length in the datasheet.
Now. Surprisingly, perhaps, the "should I protect" determination is the same for I/O as it is for memory -- it's just that the "more than face value" features are comparatively common in I/O devices...
far more so than in memory devices, where they're very rare (and, as we've seen, may not constitute a vulnerability anyway).
Here are the cases in which you needn't worry about protecting a memory or I/O device from dummy accesses during dead cycles:
- the device has no features that attach extra, implicit significance to an access
- it does, but you've been able to satisfy yourself that no problem will result.
In all other cases you'll want to protect the device from dummy accesses, and the question becomes "
how can I protect"? It's worth mentioning that problems can be avoided simply by observing certain coding practices (and, by necessity, legions of 6502 users got by in this fashion). But, protection based on the 65816's VPA and VDA signals involves keeping the vulnerable device disabled during dead cycles (while of course also ensuring it
is enabled during cycles which require it to respond).
Presumably any access to an I/O device will pertain to data (not code), and that makes protection pretty simple. Just arrange things so the device is only enabled when VDA is high. (See the diagram and The Truth Table
here.) And if the I/O device doesn't require protection, just ignore VDA.
But a memory device can contain both data and code, which means it must be enabled if VDA goes high or if VPA goes high, or both. Again, refer to the Truth Table. And if the memory device doesn't require protection (this will be all of them except perhaps a tiny minority with wonky features) just ignore VDA and VPA.
-- Jeff
Login
Register
FAQ
Search
Now we have a modest 65C02 running as fast.
