@MSGID: <ugfisj-ut1.ln1@hendrix.foo> 8a20c17d
@REPLY: <Yr-cnTbS6NJRfG35nZ2dnZfqnPEAAAAA@giganews.com>
0e16b721
@REPLYADDR Peter `Shaggy` Haywood
<phaywood@alphalink.com.au>
@REPLYTO 2:5075/128 Peter `Shaggy` Haywood
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <ugfisj-ut1.ln1@hendrix.foo>
@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> <q3e5sj-8q1.ln1@hendrix.foo>
<Yr-cnTbS6NJRfG35nZ2dnZfqnPEAAAAA@giganews.com>
@TZUTC: 1000
@PID: KNode/0.10.9
@TID: FIDOGATE-5.12-ge4e8b94
Groovy hepcat Michael J. Mahon was jivin` in comp.sys.apple2.programmer
on Fri, 1 Sep 2023 04:54 am. It`s a cool scene! Dig it.

> Peter `Shaggy` Haywood <phaywood@alphalink.com.au> wrote:
>> Groovy hepcat Michael J. Mahon was jivin` in
>> comp.sys.apple2.programmer on Mon, 28 Aug 2023 04:45 pm. It`s a cool
>> scene! Dig it.
>> 
>>> Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> wrote:
>>> 
>>>> 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.
>> 
>>   Not quite. What happens is that the first byte of the instruction
>>   (the
>> op code) is read and, depending on the particular code, either 0, 1
>> or 2 operand bytes are read in. In the case of a JSR, 3 bytes are
>> read in total, the op code and a 2 byte address operand. The program
>> counter is updated as each byte is read in.
>>   Next, the operation is carried out. For JSR that means the current
>> value of the PC, which now contains the address of the next
>> instruction (or whatever occupies the memory following the JSR,
>> including operand) is pushed on the stack before execution branches
>> to the new location.
>>   An RTS instruction just pulls the address off the stack and bungs
>>   it
>> into the PC so that execution can take up 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.
>> 
>>   No, it is the address of the next instruction. You`re right about
>>   not
>> changing the need to add 3 to the address. It`s just that the address
>> is that of the following op code..., which before 3 is added, in this
>> case, isn`t an op code but data.
>>   
> 
> Before posting, you should have RTFM. ;-)
> 
> That is NOT how JSR/RTS works.
> 
> You can "pretend" that it works like that as long as you never use (or
> create) the return data that is pushed on the stack.

  After doing some reading, I see that you are quite correct. I bow to
superior knowledge and would like to say, in the words of Maxwell
Smart, "Sorry about that, Chief!"

-- 


----- Dig the NEW and IMPROVED news sig!! -----


-------------- Shaggy was here! ---------------
              Ain`t I`m a dawg!!
--- KNode/0.10.9
 * 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