JSR - NESdev BBS

JSR
by WedNESday on 2006-12-23 (#20596)

Code:

JSR

        #  address R/W description
       --- ------- --- -------------------------------------------------
        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

Does anyone know what actually happens on the third cycle? What gets read into the databus?

by Quietust on 2006-12-23 (#20597)

It isn't known what it's trying to do, but it's probably safe to just do the stack access and ignore it.

Re: JSR
by tepples on 2006-12-23 (#20598)

WedNESday wrote:
Code:
JSR

# address R/W description
--- ------- --- -------------------------------------------------
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

Does anyone know what actually happens on the third cycle? What gets read into the databus?

According to the table, the CPU reads and discards the memory or I/O location whose address is (0x0100 plus the stack pointer). In the NES, this is always RAM[0x0100 + regS].

by WedNESday on 2006-12-23 (#20599)

It must have some purpose. I mean, I know that the 6502 can waste some cycles, but never in this manner. It just seems to bear no resemblance to the rest of the opcode, bearing in mind that saving the one cycle would mean a lot for the programmer for such a speed restricted CPU.

by blargg on 2006-12-23 (#20600)

It doesn't make sense, as the stack pointer is immediately available at all times, and (for example) the absolute addressing mode is able to put the just-read 16-bit address on the bus immediately after it's read, without a one cycle delay. The 6502 manual doesn't offer help either:
6502 Manual wrote:
During the third cycle, the microprocessor puts the stack pointer onto the address lines and on the fourth writes the contents of the current value of the program counter high into the memory location indicated by the stack pointer address.

The folks on 6502.org might have more insight.

by dvdmth on 2006-12-24 (#20604)

If I were to venture a guess, I'd guess that the extra cycle is necessary to avoid a clash between the byte just read (lower 8 bits of new PC) and the byte about to be written (upper 8 bits of old PC). There are no other opcodes that write to the stack immediately after an important read operation.

by Bregalad on 2006-12-25 (#20616)

Just a guess - It was originally to put the status register on the stack like interrupts does, and was tricky disabled.

by blargg on 2006-12-25 (#20617)

Quote:
I'd guess that the extra cycle is necessary to avoid a clash between the byte just read (lower 8 bits of new PC) and the byte about to be written (upper 8 bits of old PC). There are no other opcodes that write to the stack immediately after an important read operation.
But there are instructions which write to memory immediately after reading the high byte of the address to write to.

Quote:
Just a guess - It was originally to put the status register on the stack like interrupts does, and was tricky disabled.
If this were the case the status would probably be pushed last, like in an interrupt.