[ LOL! I see Garth's a faster typist than I am. Also he touches on a point I overlooked -- namely, that merely reading can change status in some cases. The IFR of a 6522 is one example -- reading that register can change its contents. My comments are more general. Vladimir's post raises other questions worth examining.]
Most computers have address decode logic which, for any particular address, will activate
only one memory / IO device -- or possibly none, but never
more than one. OTOH other computers use decode logic which, for cost or space reasons, is simplified, and the "one device at a time" rule has exceptions. For example, supposing there are two IO devices, you might find there's...
- a portion of the CPU address range in which neither IO device activates
- a portion of the CPU address range in which device A activates
- a portion of the CPU address range in which device B activates
- a portion of the CPU address range in which device A and B both activate
Code that's written specifically for accessing these devices won't use the "neither" range or the "both" range. But other, more general code (like your examples) might.
A read or write access to the "A" or to the "B" range is what you'd call business as usual. The only caveat is the one Garth raised.
A write access to the "neither" range produces no effect, and is harmless. A read access is harmless for hardware, but the data returned is somewhat unpredictable. Presumably the software won't succeed or fail based on such an access, so there's no harm there, either.
A
write access to the "both" range is "heard" by both devices, and that could even be useful! But a
read access to the "both" range is the problem we need to discuss. When two devices are simultaneously commanded to drive the data bus, the result (ignoring the unlikely case where both devices happen to read identical data) is bus contention.
Vladimir wrote:
Is it dangerous for soft- and hardware?
The data returned is undefined, so the software mustn't succeed or fail based on such an access. But it's not worth worrying about, since in these circumstances it's impossible to define success! As for the hardware, nobody will
recommend bus contention. It's guaranteed to result in an abnormally high current flow from the outputs of the two devices involved. Nevertheless, the probability of damage is small. If you don't notice the chips getting hot then you're probably OK. I realize that doesn't sound very scientific!
Remember the excess current flow occurs only during cycles for which the devices are accessed. Because those cycles are typically very much in the minority the heating effect will be small -- IOW the
average dissipation is tolerable.
Two final notes. Modern, CMOS devices are capable of higher output current than older devices -- especially NMOS. So if you're using only NMOS I wouldn't worry at all about contention causing permanent hardware damage.
The other issue is VCC supply noise resulting from the excess current associated with contention -- especially in the absence of adequate decoupling capacitors. This won't cause any permanent damage, but it can be enough to upset the software.
-- Jeff
Login
Register
FAQ
Search
. 
!
