Is it possible to manually push and pop the PC with the 65816?

I need to do PC relative jumps but can't really think of a reasonable way to jump back. Any ideas?

PER?

Instructions that come to mind for pushing the program counter are PEA (push 16-bit effective absolute address, although it can also be data, or it can be the address of the PC if it's known at assembly time), PER (push 16-bit effective relative address, and can be your actual address if you don't give it an offset), PHK (push program-bank register), and of course JSR and JSL. Instructions that pull the PC off the stack are RTS, RTL, RTI. (Be careful about the one-byte difference between return-from-interrupt and return-from-subroutine.) There are more ways to skin this cat, but these are the main ones that immediately come to mind. Other members who have more '816 experience than I have will undoubtedly chime in with more ideas.

Chapter 13 of the 6502 stacks treatise, "65816's instructions and capabilities relevant to stacks, and 65c02 code which partially synthesizes some of them" http://wilsonminesco.com/stacks/816newinst.html addresses this kind of thing.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you!

I did it with the PER instruction. Took me a moment to figure out how to calculate the relative offset correctly.



The NOP is needed for a correct return address.

The NOP is one solution, but not the only solution.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

YES! That's even better, thank you!

I'm late to the party here, but what you want is the equivalent of the BSR instruction found in the Motorola 68K MPUs. It can be easily written as a macro:

Code:

;   BSR: Branch to Subroutine
;   ——————————————————————————————————————————————————————————————————————
;   This macro synthesizes the BSR instruction implemented in the Motorola
;   6800 & 68000 microprocessors.  Programs in which subroutines are call-
;   ed via BSR are fully relocatable,  as the target address is calculated
;   relative to the program counter at run-time.   The target address must
;   be within the range of a long relative branch, +$7FFF or -$8000 bytes.
;   ——————————————————————————————————————————————————————————————————————
;
bsr      .macro .sr            ;BSR <addr>
.mib     =$82
.mip     =$62
.na      =*+3
.ra      .set .na+2
.ba      =.ra+1
.ra      .set .ra-.na
.ta      .set .sr-.ba
         .byte .mip,<.ra,>.ra,.mib,<.ta,>.ta
         .endm

The above was written to synthesize BSR <ADDR> on the '816, using the Kowalski simulator to assemble the source code. It takes advantage of BRL (long relative branch) and PER.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks BDD. So, I think that's a variation with greater range than Jeff's:



versus

Had to use the BRL in the end, yeah... What I do not understand is: Why do I exit with RTS and not RTL after BRL?

Not all "xxL"s are created equal.

BRL is the "16-bit flavor" of the 8-bit BRA. BRL can't break out of the current code bank, so there's no need to save that bit of state (which is a good thing, since PER only pushes 16 bits of address). So RTS is the proper return instruction.

JSL is the "24-bit flavor" of the 16-bit JSR. It does need to save the code bank state, so it pushes a 24-bit return address, which is expected by RTL.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

If you need to emulate JSL, perhaps because you need a long-indirect (which JMP provides) rather than only a 16-bit indirect, then you can use the following: In that case you would return with RTL.

Why not just use the JSL instruction with the self-modifying code and let the '816 do the stack grunting?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!