Wilson wrote: ↑Sat Oct 07, 2023 2:04 pm
chysn, does your assembler JSR to the PC instead of RTI'ing to it as Mike said? I guess based on your question regarding RTS behavior that your assembler returns to the monitor in such a scenario? I've been working on my own assembler and went with the push PC, P, Y, X, A, RTI approach as well.
Some monitors offer a separate command for the JSR behavior (usually J IIRC), but AFAIK GO typically behaves as Mike described.
I do not use RTI. I'm basically enclosing execution in the SYS code, retrieving register and PC values from SYS's storage locations and then setting those locations upon both RTS and BRK. I see how RTI is the best choice for a self-contained monitor, as you have total control over what's left when control is handed over to user code.
However, wAx is a BASIC extension, which complicates that a little. There are actually two sets of return addresses that get added to the stack. When user code returns via RTS, it returns from SYS, then from the GO tool, then jumps to the warm start vector at $0302 (if in direct mode)
or to the interpreter inner loop (if within a BASIC program). RTS doesn't "return to the monitor" because you're never "in" a monitor. Even BRK returns to BASIC. In direct mode, it puts the wedge prompt in the keyboard buffer so that it
seems like you're still "in" the monitor.
Because BASIC is involved, I don't have much control over what BASIC puts on the stack. But I can take BASIC's stuff
off the stack, and whittle it down to where it was before the BRK. At this point, I'm relying on the notion that the aforementioned return addresses are already on the stack, a bit further down*, so that a program continued from breakpoints can eventually exit gracefully.
* My mental model of the 6502 stack is backwards.
Further up is arguably more accurate.