How are 6502 and 65C02 JMP(abs) processed internally

Question

An infamous "feature" of the 6502 is that the JMP(abs) opcode will fetch the lower byte of the jump target from the address in the instruction, and fetch the upper byte of the jump target from the address whose lower byte is one higher than the address in the instruction, wrapping after FF. Thus, JMP ($10FF) will fetch the target address from $10FF and $1000 (rather than $10FF and $1100). From my understanding, the 65C02 unconditionally inserts a cycle in which the ALU either increments or doesn't increment the upper byte of the address to fetch the PC.

Given that there is no other instruction that allows any kind of indirect memory operation from an absolute address, and given that the old program counter value will not be needed once the third byte of the instruction has been fetched, I'm curious how much circuitry was used to provide the instruction's unique operation sequence, and how that would compare with having JMP(abs) sequenced like JMP abs except that after the third cycle it would perform two more cycles which were just like the second and third (the second and fourth cycles would fetch a byte at PC, copy the bus to the data latch, and increment the PC; the third and fifth would fetch a byte at PC, and load PC from the data latch and the bus).

Does the 6502 and 65C02 manage to leverage other existing hardware in an interesting way so that their implementations of the instruction end up being surprisingly cheap, or is there something about the design of the 6502 and 65C02 that would make it impractical to change the PC mid-instruction (without e.g. risking having an incorrect PC value stored if an interrupt occurs at an inopportune moment).

Answer 1

I can't answer the question "why doesn't the 6502/65C02 use the PC to do the indirection to execute JMP (abs)", but I can answer some of the other points.

Visual6502 is the best site to find out about the inner workings of the 6502.

I'll be using the "Random Control Logic" signal names as used in the simulator, which are the same names used in Hanson's block diagram. If you rotate the diagram by 90 degrees, it roughly corresponds to the silicon (actual size used on silicon is different, so take it with a grain of salt). The block diagram is sufficient to understand what is going on, and easier to read than the silicon.

For the ROM decoder, I'll use the simulator names, which are different from the 6507 mnemonics.

You can follow both types of signals by adding a loglevel of at least 6 to the simulator URL, or by pressing Trace more often enough in the expert simulator mode. Decoding has "don't care" values, so some of the signals may be accidental.

How do JMP abs and JMP (abs) work internally?

(What circuitry is used? Is the implementation cheap?)

In general, instructions are executed through several states (numbered T0 to T6). The 6502 has a kind of two-stage pipeline, where the next instruction is already fetched and decoded while the last stage(s) of the previous instruction still executes. In T0, the next opcoded is prepared to be fetched, and in T1, the opcode is decoded, and the next byte after the opcode is prepared to be fetched. This is why every instruction execution ends with T0 and T1, and starts with T2 if more than two cycles are needed. (I'd assume T0 is also the phase where the 6502 checks for interrupts, and replaces the opcode with a BRK if it finds one, but I didn't verify this).

So beginning in the T2 cycle of JMP abs, the low byte of the destination address is fetched. It is output on the DB bus (DL/DB), then stored in the the B input register of the ALU (DB/ADD), added to a zero (SUMS, 0ADD) from the A input, and finally temporarily stored in the adder hold register. This is necessary because the T0 cycle already loads the high byte of the destination address onto the ADH bus, and both must be stored in PCL and PCH at the same time (ADD/ADL, ADL/PCL and DL/ADH, ADH/PCH).

For JMP (abs), the first cycles are very similar (the only different ROM signal is the absence of T2‑jmp‑abs), but in T3, the operand address is only output onto the address bus and not stored in the PC. The low byte of the final destination address that is fetched this way is eventually again stored in the B input register. But before that, the old value of the B input register is incremented by 1 using the carry, and this is used as the address of the high byte of the final destination address. Overflow for that is not handled, which explains the "infamous wrapping effect". The final transfer to the PC works similarly as for JMP abs.

So both jumps use the datapath circuitry just like every other instruction, it's neither particularly cheap nor expensive.

How could one test a JMP (abs) implementation using the PC?

(Is there anything that would prevent it from working?)

You could modify the decode ROM and decode logic in the simulator. The simulator uses three files to store the silicon data in a simple format, which are available on github. There are already special signals T3-jmp and T4-jmp for the "indirect" phase, and you may need an additional signal (or re-use one of those two) to ensure loading of the PC in the T2 phase in absence of T2-jmp-abs. And of course you need to rewire the T3 and T4 phase.

You'll likely need some more space for transistors, so a tool to create horizontal or vertical space (increment all coordinates greater than some threshold) in the data files would be helpful.

Answer 2

With regard to potential problems with changing PC in the middle of instruction execution, to my knowledge, interrupt generation, except for RESET, can only occur when the CPU receives a signal to reset the instruction timer, which typically happens during the final cycle of instruction operation. The only exception to resetting the timer would be the nefarious 'x2' instructions, in which no reset signal is ever sent because nothing triggers one, a behavior possibly also present in '80,' after which the timer 'expires' after cycle 6/7, thus leaving the CPU in virtual limbo.

If when the timer resets, ~IRQ|I*~NMI*~RST is low (I believe ~RST force resets the timer), normal execution is halted and BRK is executed without affecting PC, setting the B flag written to the stack to ~IRQ|I, I think, and setting A2 to ~NMI and A1 to ~RST, most likely (which would explain the behavior of all the hardware interrupts). I am mostly drawing this analysis from my limited examination of the 6502 schematic and the knowledgeable reports on 6502 behavior that I have read. I am not an expert on the actual functionality of the 6502. Note that there is no flip-flop for B in the CPU, its behavior is only present during interrupt execution (that is, B is always 'set' except when an IRQ is generated).

As for the behavior of JMP, I would guess that the signal line that is tied to JMP abs alone is the timer reset, which also loads the 16-bit address buffer to PC. It would then follow that the fourth cycle reads the low byte of the new PC value from that address and adds one to the buffer, but does so 8-bit only, then the cycle afterward, JMP timer cycle 5, behaves like the JMP abs only cycle. If this is the case, PC is still only changed when the instruction ends, probably because no one thought to change PC during instruction execution and using the natural behavior of PC to handle the indirect JMP memory read.

Answer 3

This is code of sim65:

/* Opcode $6C: JMP (ind) */
{
    unsigned PC, Lo, Hi;
    PC = Regs.PC;
    Lo = MemReadWord (PC+1);


if (CPU == CPU_6502)
{
     /* Emulate the 6502 bug */
    Cycles = 5;
    Regs.PC = MemReadByte (Lo);
    Hi = (Lo & 0xFF00) | ((Lo + 1) & 0xFF);
    Regs.PC |= (MemReadByte (Hi) << 8);

    /* Output a warning if the bug is triggered */
    if (Hi != Lo + 1)
    {
        Warning ("6502 indirect jump bug triggered at $%04X, ind addr = $%04X",
                 PC, Lo);
    }
}
else
{
    Cycles = 6;
    Regs.PC = MemReadWord(Lo);
}


}