Return to Answer

Applying the same decoding logic to $89 as is applied to $85, $A9, and $A5 would result in an instruction whose external behavior would match LDA #imm, but which doesn't update any registers or flags. Not coincidentally, an NMOS 6502 behaves in exactly that fashion.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that read to a write. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.

Applying the same decoding logic to $89 as is applied to $85, $A9, and $A5 would result in an instruction whose external behavior would match LDA #imm, but which doesn't update any registers or flags. Not coincidentally, an NMOS 6502 behaves in exactly that fashion.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that read to a write. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that read to a write. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.

Applying the same decoding logic to $89 as is applied to $85, $A9, and $A5 would result in an instruction whose external behavior would match LDA #imm, but which doesn't update any registers or flags. Not coincidentally, an NMOS 6502 behaves in exactly that fashion.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that read to a write. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that write to a read. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.

The 6502 generally decides what operation is going to be doing on each memory cycle before the end of the read of the previous cycle; the primary exception to this is that "perform an operation with a specified low address, along with a high address fetched from the data bus" and "perform an operation with a specified high address, along with a low address fetched from the data bus" are available as operation choices(*)

The distinctions among LDA #imm, LDA zp, and STA zp are all made while the second byte of the instruction is being fetched. This is fine for any instruction which would read an immediate operand, since the CPU will know what to do with the data by the time it arrives on the bus at the end of the second cycle. In order for STA #imm to work, however, the CPU would have to know before the beginning of the second cycle that it would need to perform a write. There's no way the CPU can go back in time after it has fetched the operand byte and retroactively change that read to a write. While it might be theoretically possible to have the instruction insert a write cycle, doing so would eliminate any benefit that STA #imm could have offered over STA zp. If STA #imm, STX #imm, and STY #imm could execute in two cycles each, that could reduce the cost of saving registers on interrupt entry by three cycles compared with using zero-page forms. If the instructions existed but took three cycles each, however, using zero-page forms would be just as fast but more convenient.

Another way of looking at things might be to say that immediate mode doesn't instruct the processor to fetch the byte after the opcode and do something with it, but instead instructs the processor that logic which would normally fetch a memory operand into a temporary register should instead do nothing, leaving that register holding a byte that was blindly fetched without knowing what if anything it would be used for. Store instruction piggy-back on the memory-access logic used for other instructions, except that they assert R/W during what would otherwise be the final memory fetch. Since the memory-access logic does nothing during LDA #imm, it likewise does nothing during STA #imm.

(*) These are, of course, fundamental to the efficient operation of the machine, since in most programs, the majority of cycles that aren't code fetches will fit one of those patterns. When processing LDA (zp),y, for example, the third cycle combines a zero high byte with a newly-fetched low byte, and the fifth combines a newly-computed low byte with a newly-fetched high byte). Of the cycles that aren't code fetches, only the fourth cycle and (if present) sixth cycle won't load half of the address bus with newly-fetched data.