Difference between revisions of "Incomplete Address Decoding"
m (Protected "Incomplete Address Decoding" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)))
Latest revision as of 01:38, 4 December 2010
To say that a particular hardware unit does not completely decode the address is to imply that that hardware unit is addressable in more than one range of memory locations. The manufacturer typically only documents the "official" location where that device is addressable. Any other memory ranges where the device also appears to be accessible due to incomplete address decoding are sometimes referred to as "shadows", "mirrors", or "aliases".
Exactly why incomplete address decoding creates these memory aliases requires a bit more explanation. Basically, what's going on is that the device in question, the device with the memory aliases, is not paying any attention to the value of some of the bits in the address, and it is thus responding to read or write requests regardless of the values contained in those ignored address bits.
Programmer-types often have a difficult time understanding this concept because they try to imagine the memory bus as a big array of bytes, and when a CPU asks for the value at a particular location, programmers imagine the memory bus indexing the array of bytes to retrieve the correct value for the CPU. In reality, this is not at all how the actual hardware functions. In real hardware, the memory bus is more like a location where the CPU "broadcasts" an address to all the memory units on the bus. Every addressable device connected to the bus then decides for itself whether or not it should respond to the address in question and what value it should return. Ideally, only one device will respond to a particular address. It is entirely possible, however, for more than a single device to respond to the same address, in which case the CPU will receive a logical combination of the responses from every device that responded to the request. Combine this general behavior of the memory bus with the fact that each device on the memory bus makes it's own decision about when to respond and take into account that some devices do not pay attention to every bit of the address request, and you get the resulting memory aliasing effect.
Now let's look at a simple example unrelated to the actual Intellivision hardware. Let's say there is a 4K ROM unit attached to a 16-bit address bus, and this particular ROM unit's "official" memory location is from $1000-$1fff. If the CPU makes a request at address location $1000, the ROM unit should respond with the value at the first location in the ROM unit.
However, what if the ROM unit ignores the most significant bit of the address? In other words, this ROM unit does not care whether the most significant bit is either a one (1) or a zero (0). The ROM unit will still respond properly to a request at address $1000, but it will also respond to a request at address $9000, because it does not even consider the upper bit of the address, thereby creating an alias of the ROM unit from $9000-$9fff.
The situation is even more complex with RAM and other read/write units. These devices can ignore different bits on reads than they do on writes! That means that although they will respond to reads and writes at the published address location, the aliases for the device may be different for reads than for writes. This can create a lot of confusion if you are trying to write an emulator for such a system.
To document the incomplete read/write behavior of the various devices contained in the Intellivision Master Component and related peripherals, you will notice references throughout this site to "Read Address Masks" and "Write Address Masks". These are indicators of which address bits the various hardware devices are ignoring, and which memory locations will alias those devices as a result.