@MSGID: <a8qdndVgG6oR33H5nZ2dnZfqnPWdnZ2d@giganews.com>
3109eee3
@REPLY: 1@dont-email.me> decf1455
@REPLYADDR Michael J. Mahon <mjmahon@aol.com>
@REPLYTO 2:5075/128 Michael J. Mahon
@CHRS: CP866 2
@RFC: 1 0
@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>
@RFC-Message-ID:
<a8qdndVgG6oR33H5nZ2dnZfqnPWdnZ2d@giganews.com>
@TZUTC: 0000
@PID: NewsTap/5.5 (iPhone/iPod Touch)
@TID: FIDOGATE-5.12-ge4e8b94
Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> wrote:
> On 2023-08-24 2:06 a.m., Jerry Penner wrote:
>> Colin Leroy-Mira <colin@colino.net> writes:
>> 
>> The P8 tech-ref states:
>> 
>> ---------------------------------------- SYSCALL  JSR MLI       ;Call
>> Command Dispatcher DB CMDNUM     ;This determines which call is being
>> made DW CMDLIST    ;A two-byte pointer to the parameter list BNE
>> ERROR     ;Error if nonzero
>> 
>> Upon completion of the call, the MLI returns to the address of the 
>> JSR plus 3 (in the above example, the BNE statement); the call number
>> and parameter list pointer are skipped. 
>> ----------------------------------------
>> 
>> Where the CPU returns to is 6 bytes past the label SYSCALL, which is
>> the location of the "BNE ERROR" instruction.
>> 
>> I think I always read and understood the book the way I think Oliver 
>> does, but I think the book`s address arithmetic is wrong, looking at
>> it now.
> 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.  

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. ;-)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
--- NewsTap/5.5 (iPhone/iPod Touch)
 * Origin: usenet.network (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