@MSGID: 1@dont-email.me> cd4f137d
@REPLY: <a8qdndVgG6oR33H5nZ2dnZfqnPWdnZ2d@giganews.com>
3109eee3
@REPLYADDR Jeff Blakeney
<CUTjeffrey_blakeney@yahoo.ca>
@REPLYTO 2:5075/128 Jeff Blakeney
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: <20230822221945.4eb8a091@laptop-sigfox>
<yubzg2iicr9.fsf@jpen.ca> <20230823082311.3dc76fb1@laptop-sigfox> 1@solani.org>
<20230823152214.5e86230e@laptop-sigfox> <yubr0ntht3u.fsf@jpen.ca> 1@dont-email.me>
<a8qdndVgG6oR33H5nZ2dnZfqnPWdnZ2d@giganews.com>
@TZUTC: -0400
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.14.0
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-08-28 2:45 a.m., Michael J. Mahon wrote:
> Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> wrote:
>> As far as I remember my 6502 assembly, when you do a JSR, the processor
>> has already read the JSR byte and the two byte address so the PC is
>> pointing at the DB CMDNUM statement and that is what is pushed on the
>> stack.  The MLI pulls that address off the stack, adds 3 to it, pushes
>> it back on the stack and does an RTS so that the BNE ERROR statement
>> will get executed.
>>
>> In other words, the SYSCALL is the address of the JSR but it isn`t the
>> address that gets pushed onto the stack when the JSR is executed.
> 
> Well, the details are: JSR pushes the address of the JSR opcode plus *two*
> on the stack, and the RTS pops the address and adds *one* to get the return
> PC value.

I haven`t done any 6502 coding in a long time but my memory tells me the 
6502 did it this way:  PC has address of SYSCALL (or probably SYSCALL-1 
and increments the PC to get there), processor reads the byte there to 
see what opcode to execute, sees it is a JSR so increments the PC and 
reads the low byte of the address, increments the PC and reads the high 
byte of the address, pushes the current PC (SYSCALL +2) to the stack, 
changes the PC to the address it just read and continues execution from 
there.  When it hits an RTS it pulls the address off the stack, adds one 
to it and continues executing from there.

> This doesn`t change the need to add 3 to the stacked value to skip 3 bytes
> of in-line data, but it does mean that the stacked address points at the
> high byte of the JSR, not the first byte of the in-lined data.
> 
> Sometimes details matter. ;-)

Breaking it down above, I realized that I probably got it wrong in my 
original post and the stack gets the address of the high byte and not 
the address of the DB CMDNUM.  Also it makes me wonder if the 6502 
subtracts one from the JSR address when it puts it in the PC so that it 
can be incremented before reading the opcode at the JSR address.  It 
depends on whether the 6502 always increments the PC before reading the 
next opcode and my memory fails me on that point.

As to the original question, the 6502 pushes SYSCALL + 2 to the stack, 
the MLI needs to add 3 to the address pulled off the stack, the 6502 
adds 1 when it does the RTS so you end up continuing execution at 
SYSCALL +6 in the example.

Knowing the details of how the 6502 works in this case isn`t really 
necessary, you just need to know that your code will continue executing 
after the command block.  :)
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.14.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441