@MSGID: <Yr-cnTfS6NJWfG35nZ2dnZfqnPGdnZ2d@giganews.com>
4a771cad
@REPLY: 1@dont-email.me> cd4f137d
@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>
<a8qdndVgG6oR33H5nZ2dnZfqnPWdnZ2d@giganews.com> 1@dont-email.me>
@RFC-Message-ID:
<Yr-cnTfS6NJWfG35nZ2dnZfqnPGdnZ2d@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-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.

It doesn`t. Note that all the hardware vectors--IRQ, RESET, etc. are the
actual service routine addresses, not the addresses minus one.  

This is in contrast with the ROM convention of "RTSing" to a routine whose
address is part of a table of "routine addresses -1" to work around the
lack of an indexed indirect JMP.  (RTS takes its time to increment the
return as it pops successive bytes from the stack.)

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

Right, but it matters a great deal to the implementor of SYSCALL, or any
other subroutine which uses in-line parameters. ;-)

-- 
-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