JSR high byte issue about processortests HOT 3 CLOSED

This definitely puzzled me, but I think I've figured it out: the stack is stomping upon the instruction mid-flight.

The cycle breakdown for JSR per 64doc is:

    1    PC     R  fetch opcode, increment PC
    2    PC     R  fetch low address byte, increment PC
    3  $0100,S  R  internal operation (predecrement S?)
    4  $0100,S  W  push PCH on stack, decrement S
    5  $0100,S  W  push PCL on stack, decrement S
    6    PC     R  copy low address byte to PCL, fetch high address
                   byte to PCH

So in this case:

PC is initially 0x17B; S is initially 0x7D so the stack pointer is currently at 0x17D.

1. fetch opcode from 0x17b, which is 0x20;
2. fetch low byte of target address from 0x17c, which is 0x55;
3. read from the stack, by coincidence address 0x17d, doing absolutely nothing with the result;
4. write the current high byte of the PC, which is value 1, to the stack at 0x17d;
5. write the current low byte of the PC, which is 0x7d, to the stack at 0x17c;
6. fetch high byte of target address from 0x17d, which is now 1, because it was written there back in cycle 4.

from processortests.

WAIT. Wow. This test is executing instructions INSIDE of the stack. I didn't even think about that!

This is both the best and worst test ever written.

You, my friend, have won the internet.

from processortests.

Just to follow up, I implemented that order of operation and that passed the test, thank you so much!

        var addressLow = readByte();
        pushWord(state.pc);
        var addressHigh = readByte();
        state.pc = (addressHigh << 8) | addressLow;

from processortests.