Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3302 > unrolled thread

running programs in aux memory

Back to article view | Back to comp.sys.apple2.programmer

Contents

  running programs in aux memory Mark Lemmert <mark.lemmert@gmail.com> - 2017-03-02 12:10 -0800
    Re: running programs in aux memory "Mark D. Overholser" <marko@markoverholser.com> - 2017-03-02 14:18 -0800
      Re: running programs in aux memory Mark Lemmert <mark.lemmert@gmail.com> - 2017-03-03 11:08 -0800
    Re: running programs in aux memory roger.shimada@gmail.com - 2017-03-02 20:41 -0800
      Re: running programs in aux memory Mark Lemmert <mark.lemmert@gmail.com> - 2017-03-03 11:18 -0800
        Re: running programs in aux memory roger.shimada@gmail.com - 2017-03-05 09:13 -0800
          Re: running programs in aux memory 6502workshop@gmail.com - 2017-03-05 20:11 -0800
    Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-03 00:50 -0800
      Re: running programs in aux memory qkumba <peter.ferrie@gmail.com> - 2017-03-03 08:47 -0800
        Re: running programs in aux memory Mark Lemmert <mark.lemmert@gmail.com> - 2017-03-03 11:08 -0800
          Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-03 12:55 -0800
            Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-03 13:00 -0800
              Re: running programs in aux memory Antoine Vignau <antoine.vignau@laposte.net> - 2017-03-03 19:53 -0800
                Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-03 20:41 -0800
                  Re: running programs in aux memory qkumba <peter.ferrie@gmail.com> - 2017-03-03 21:43 -0800
                    Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-04 08:37 -0800
                      Re: running programs in aux memory Antoine Vignau <antoine.vignau@laposte.net> - 2017-03-04 11:02 -0800
                        Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-04 13:54 -0800
                        Re: running programs in aux memory gids.rs@sasktel.net - 2017-03-05 15:58 -0800
                          Re: running programs in aux memory John Brooks <jbrooks@blueshiftinc.com> - 2017-03-05 20:16 -0800
                            Re: running programs in aux memory qkumba <peter.ferrie@gmail.com> - 2017-03-06 09:30 -0800
                      Re: running programs in aux memory qkumba <peter.ferrie@gmail.com> - 2017-03-04 22:11 -0800
              Re: running programs in aux memory Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-03-15 19:06 -0700
      Re: running programs in aux memory Benoit0123 <bgilon@free.fr> - 2017-03-06 00:20 +0000
    Re: running programs in aux memory 6502workshop@gmail.com - 2017-03-05 20:13 -0800
    Re: running programs in aux memory laseractiveguy@gmail.com - 2017-03-08 16:33 -0800
    Re: running programs in aux memory laseractiveguy@gmail.com - 2017-03-08 17:04 -0800

Page 1 of 2  [1] 2  Next page →

#3302 — running programs in aux memory

I’m about to do some experimenting (for the first time) with using XFER ($C314) to pass control to a subroutine in AUX memory. I’m planning having my main program (in main memory) and the aux subroutine share the main memory stack and zero page 


In this scenario, the material on this subject in “Inside the Apple IIe” recommends saving the stack before passing control to the aux program and restoring the before returning control to the main memory program.  

I’m guessing that this is a safety net recommendation rather than a requirement and would like to double check. 

As long as the subroutine in aux memory removes all the bytes from the stack that it adds (and doesn’t remove more bytes than it adds), wouldn’t the stack contents and stack pointer be in the exact same state as when control was transferred to the aux subroutine?

 
Thanks much for any advice anyone has!


Mark

[toc] | [next] | [standalone]

#3303

On 02-Mar-17 12:10, Mark Lemmert wrote:
> I’m about to do some experimenting (for the first time) with using
> XFER ($C314) to pass control to a subroutine in AUX memory. I’m
> planning having my main program (in main memory) and the aux
> subroutine share the main memory stack and zero page
>
>
> In this scenario, the material on this subject in “Inside the Apple
> IIe” recommends saving the stack before passing control to the aux
> program and restoring the before returning control to the main memory
> program.
>
> I’m guessing that this is a safety net recommendation rather than a
> requirement and would like to double check.
>
> As long as the subroutine in aux memory removes all the bytes from
> the stack that it adds (and doesn’t remove more bytes than it adds),
> wouldn’t the stack contents and stack pointer be in the exact same
> state as when control was transferred to the aux subroutine?
>
>
> Thanks much for any advice anyone has!
>
>
> Mark
>


Tom Porter has a Sound Routine, SFX that runs from the Aux Memory...

I don't know if he follows c.s.a2.p, but I will give him a "heads up"....


MarkO

[toc] | [prev] | [next] | [standalone]

#3308

On Thursday, March 2, 2017 at 4:18:58 PM UTC-6, Mark D. Overholser wrote:
> On 02-Mar-17 12:10, Mark Lemmert wrote:

> Tom Porter has a Sound Routine, SFX that runs from the Aux Memory...
> 
> I don't know if he follows c.s.a2.p, but I will give him a "heads up"....
> 
> 
> MarkO

Thanks!

[toc] | [prev] | [next] | [standalone]

#3304

On Thursday, March 2, 2017 at 2:10:23 PM UTC-6, Mark Lemmert wrote:
> I’m about to do some experimenting (for the first time) with using XFER ($C314) to pass control to a subroutine in AUX memory. ...
> 
> In this scenario, the material on this subject in “Inside the Apple IIe” recommends saving the stack before passing control to the aux program and restoring the before returning control to the main memory program.  

The correct phrase should be "stack pointer."

From the Apple IIe Technical Reference Manual (includes ROM Listings) 1985 ISBN 0-201-17720-X (i.e., for the enhanced //e)

"Warning
It is the programmer’s responsibility to save the current stack pointer at $0100 in main memory and the alternate stack pointer at $0101 in auxiliary memory before calling XFER and to restore them after regaining control. Failure to do so will cause program errors."

This is likely due to interrupt based devices (notably the IIe workstation card).

This does not appear in the original IIe manual, or the first two editions of the //c Technical References.

I think that I disabled interrupts anytime I was doing something unusual like reading main RAM and writing to aux (or vice versa).

I found it convenient to have common code at the same address in both main and aux RAM.

[toc] | [prev] | [next] | [standalone]

#3309

On Thursday, March 2, 2017 at 10:41:44 PM UTC-6, roger....@gmail.com wrote:

> From the Apple IIe Technical Reference Manual (includes ROM Listings) 1985 ISBN 0-201-17720-X (i.e., for the enhanced //e)
> 
> "Warning
> It is the programmer’s responsibility to save the current stack pointer at $0100 in main memory and the alternate stack pointer at $0101 in auxiliary memory before calling XFER and to restore them after regaining control. Failure to do so will cause program errors."

Thanks for the reply. Is this in reference to a scenario where the program and main and aux memory are not using the same stack and zero page? In that case I see why the stack pointer must be saved.


The excerpt from "Inside the Apple IIe" (1985, Garry B. Little) that I saw was:

"if two programs are both using the same stack, care must be taken to avoid over-writing information that the other program has left on the stack. This is most easily done by saving the whole stack when control is transferred and then restoring it just before returning to the calling program" 

I did some testing since my OP yesterday and so far the copy/restore of the stack and/or the stack pointer has not been necessary when both programs are using the same zero page and stack but maybe there are issues with this approach that I've not yet encountered. 


Mark

[toc] | [prev] | [next] | [standalone]

#3323

On Friday, March 3, 2017 at 1:18:24 PM UTC-6, Mark Lemmert wrote:
> Is this in reference to a scenario where the program and main and aux memory are not using the same stack and zero page? In that case I see why the stack pointer must be saved.

When an interrupt occurs, the memory mapped softswitches must be saved and restored. Since using the alternate zero page/stack/language card is possible the interrupted code may use a different stack pointer.

My bad, a history gaffe: In 1985, the most likely source of interrupts would be the mouse card, not a IIe workstation card which didn't exist yet.
 
> The excerpt from "Inside the Apple IIe" (1985, Garry B. Little) that I saw was:
> 
> "if two programs are both using the same stack, care must be taken to avoid over-writing information that the other program has left on the stack. This is most easily done by saving the whole stack when control is transferred and then restoring it just before returning to the calling program" 

LOL. Nobody is going to save the entire stack. (Apparently ProDOS may save part of the stack if it's too low.)

And yes, you shouldn't muck around with the previous data on the stack unless you know exactly what you're doing.

> I did some testing since my OP yesterday and so far the copy/restore of the stack and/or the stack pointer has not been necessary when both programs are using the same zero page and stack but maybe there are issues with this approach that I've not yet encountered. 

Unlikely to be a problem unless you're using a lot of stack and using the notoriously stack heavy SmartPort calls.

Caution is advised when using the alternate zero page/stack/language card.

[toc] | [prev] | [next] | [standalone]

#3326

On Sunday, March 5, 2017 at 11:13:48 AM UTC-6, roger....@gmail.com wrote:
> > "if two programs are both using the same stack, care must be taken to avoid over-writing information that the other program has left on the stack. This is most easily done by saving the whole stack when control is transferred and then restoring it just before returning to the calling program" 
> 
> LOL. Nobody is going to save the entire stack. (Apparently ProDOS may save part of the > >stack if it's too low.)

Yeah, it seems kind of excessively cautious to me (to put it mildly) to me :-) 

Thanks for confirming.

Mark

[toc] | [prev] | [next] | [standalone]

#3305

On Thursday, March 2, 2017 at 2:10:23 PM UTC-6, Mark Lemmert wrote:
> I’m about to do some experimenting (for the first time) with using XFER ($C314) to pass control to a subroutine in AUX memory. I’m planning having my main program (in main memory) and the aux subroutine share the main memory stack and zero page 
> 
> 
> In this scenario, the material on this subject in “Inside the Apple IIe” recommends saving the stack before passing control to the aux program and restoring the before returning control to the main memory program.  
> 
> I’m guessing that this is a safety net recommendation rather than a requirement and would like to double check. 
> 
> As long as the subroutine in aux memory removes all the bytes from the stack that it adds (and doesn’t remove more bytes than it adds), wouldn’t the stack contents and stack pointer be in the exact same state as when control was transferred to the aux subroutine?
>  
> Thanks much for any advice anyone has!
> 
> Mark


My advice would be to not use $C314 (XFER).

Let me know when you get tired of experimenting with it

[toc] | [prev] | [next] | [standalone]

#3306

> My advice would be to not use $C314 (XFER).

I agree with this.  You can sta $c005, sta $c003 from either zpage or LC (*) and you're in aux memory with your stack and zpage still in main memory.  To switch back, sta $c004, sta $c002.

(*) technically, if you place your aux code to run immediately after the address of the sta $c003, you could switch seamlessly, but it's not easy to plan for that.

[toc] | [prev] | [next] | [standalone]

#3307

On Friday, March 3, 2017 at 10:47:07 AM UTC-6, qkumba wrote:
> > My advice would be to not use $C314 (XFER).
> 
> I agree with this.  You can sta $c005, sta $c003 from either zpage or LC (*) and you're in aux memory with your stack and zpage still in main memory.  To switch back, sta $c004, sta $c002.
> 
> (*) technically, if you place your aux code to run immediately after the address of the sta $c003, you could switch seamlessly, but it's not easy to plan for that.


qkumba and gid..@sasktel.net,

Thanks for the advice. 

I did some experimenting with $XFER last night before I saw your posts, and it seems to be working. However, maybe I got lucky :-)

What are the kinds of problems with using XFER that you are aware of?


Here is an outline of my use case, if helpful. 

My program takes up pretty much all of main memory and main BSR. I've been using AUX memory and AUX BSR memory exclusively as high-speed storage. I've got a little bit of AUX memory left and I'm trying to move subroutine from main memory to run in AUX memory so I can use the freed up main memory for other things. 


*various JSRs call COMBAT.DAMAGE.ROLL.AUX_JMP


====main memory ($9000)===

COMBAT.DAMAGE.ROLL.AUX_JMP
    *save COMBAT.DAMAGE.ROLL.AUX_JMP.RETURN address to main zero page as RETURN.ADDR
    *execute XFER to JMP to COMBAT.DAMAGE.ROLL.AUX (using main zero page and stack)

COMBAT.DAMAGE.ROLL.AUX_JMP.RETURN
   RTS

=====aux memory ($1000)====

COMBAT.DAMAGE.ROLL.AUX
   *subroutine code
   *set RETURN.ADDR as jump address for XFER 
   *execute XFER to return to main memory  (using main zero page and stack)


So far my original concern hasn't been an issue; I'm not saving the contents of the stack or the stack pointer and everything seems to work fine. 


Mark

[toc] | [prev] | [next] | [standalone]

#3310

> What are the kinds of problems with using XFER that you are aware of?
> 

Making ROM calls is the hardest with using XFER.  But making ROM calls from Aux mem also takes a little bit of pre-setup and knowledge of the call as well.

As long as you don't plan on making any ROM calls from Aux mem, then it is mostly  just the setup of registers and pointers you have to go through to make the call.

All you need is this simple little program to handle it all for you.  I don't recommend using zero-page for this code if making any ROM calls at all, even from Main memory.

$0100 is the best address to be at.

100:08 78 0A AA 8D 05 C0 8D
108:03 C0 20 15 01 8D 04 C0
110:8D 02 C0 28 60 7C 01 08

now just store the pointers to the calling routines at $800 in Aux memory.
LSB first then MSB, and the routines themselves at their appropriate addresses.

1/800:00 10  ; point this address to routine #1 in Aux memory
1/802:80 10  ; point this address to routine #2 in Aux memory
etc

To call Aux Mem routines, do this from main memory:

   LDA # (routine#)  - routine # to call
   JSR $0100
...

The y-reg is available to pass parameters.  If you need the Acc-reg to pass parameters as well, you can use the X-reg instead to call routines but it has to be a multiple of 2.

Just end each Aux Mem routine with an RTS, which will return automatically to Main.


You should disable the /RAM driver before using Aux mem as well.

[toc] | [prev] | [next] | [standalone]

#3311

On Friday, March 3, 2017 at 2:55:50 PM UTC-6, gid...@sasktel.net wrote:
> > What are the kinds of problems with using XFER that you are aware of?
> > 
> 
> Making ROM calls is the hardest with using XFER.  But making ROM calls from Aux mem also takes a little bit of pre-setup and knowledge of the call as well.
> 
> As long as you don't plan on making any ROM calls from Aux mem, then it is mostly  just the setup of registers and pointers you have to go through to make the call.
> 
> All you need is this simple little program to handle it all for you.  I don't recommend using zero-page for this code if making any ROM calls at all, even from Main memory.
> 
> $0100 is the best address to be at.
> 
> 100:08 78 0A AA 8D 05 C0 8D
> 108:03 C0 20 15 01 8D 04 C0
> 110:8D 02 C0 28 60 7C 01 08
> 
> now just store the pointers to the calling routines at $800 in Aux memory.
> LSB first then MSB, and the routines themselves at their appropriate addresses.
> 
> 1/800:00 10  ; point this address to routine #1 in Aux memory
> 1/802:80 10  ; point this address to routine #2 in Aux memory
> etc
> 
> To call Aux Mem routines, do this from main memory:
> 
>    LDA # (routine#)  - routine # to call
>    JSR $0100
> ...
> 
> The y-reg is available to pass parameters.  If you need the Acc-reg to pass parameters as well, you can use the X-reg instead to call routines but it has to be a multiple of 2.
> 
> Just end each Aux Mem routine with an RTS, which will return automatically to Main.
> 
> 
> You should disable the /RAM driver before using Aux mem as well.


My mistake, $110 should have been the address.  There is one Applesoft routine that uses $100.10F that could be called when control is in Main memory.

[toc] | [prev] | [next] | [standalone]

#3312

Hi,
At $115, you JMP,x from address $801 but your table is at $800.
Which one is correct?
av

[toc] | [prev] | [next] | [standalone]

#3314

On Friday, March 3, 2017 at 9:54:00 PM UTC-6, Antoine Vignau wrote:
> Hi,
> At $115, you JMP,x from address $801 but your table is at $800.
> Which one is correct?
> av


$800 is fine.  I was testing something with a ROM address and it kept storing something at $800.  I moved the pointers up one byte temporarily to isolate if the faulty byte was coming from my code or the ROM code and forgot to move it back.

$116 should be a zero.

Thanks for the catch.

[toc] | [prev] | [next] | [standalone]

#3315

Nox Archaist is 6502 only, so JMP,x is not available.  The code would need to dispatch differently, perhaps like this:

asl
tax
sta $c005
sta $c003
jsr +
sta $c004
sta $c002
rts
+lda table+1,x
pha
lda table,x
pha
rts

and the entries in table would be whatever address-1.

[toc] | [prev] | [next] | [standalone]

#3318

On Friday, March 3, 2017 at 11:43:25 PM UTC-6, qkumba wrote:
> Nox Archaist is 6502 only, so JMP,x is not available.  The code would need to dispatch differently, perhaps like this:
> 
> asl
> tax
> sta $c005
> sta $c003
> jsr +
> sta $c004
> sta $c002
> rts
> +lda table+1,x
> pha
> lda table,x
> pha
> rts
> 
> and the entries in table would be whatever address-1.

I try to avoid using the stack if possible

maybe this

 asl
 tax
 sta $c005
 sta $c003
 stx table+1
 sta $c004'
 sta $c002
 rts
table equ *
 jmp ($800)

[toc] | [prev] | [next] | [standalone]

#3319

asl
sta the two ss
sta table+1

why use X?

[toc] | [prev] | [next] | [standalone]

#3320

On Saturday, March 4, 2017 at 1:02:31 PM UTC-6, Antoine Vignau wrote:
> asl
> sta the two ss
> sta table+1
> 
> why use X?


no can do.  you have to pay your (TAX)es just like everyone else.

[toc] | [prev] | [next] | [standalone]

#3324

On Saturday, March 4, 2017 at 1:02:31 PM UTC-6, Antoine Vignau wrote:
> asl
> sta the two ss
> sta table+1
> 
> why use X?


Just trying to cover all the bases.  If you use the 65c02 mnemonic, you need the x-reg.

I mentioned in my first post that you can leave out the ASL and just use the X-reg, but the X-reg would need to be a multiple of 2.

And the same goes for here, you can use the x-reg for passing parameters and just use the accumulator for the routine #.  And change the "STX table+1" to a "STA table+1".

And as noted, the "JSR table" was missing

The choice is yours to what programming style you adopt.

[toc] | [prev] | [next] | [standalone]

#3328

On Sunday, March 5, 2017 at 3:58:02 PM UTC-8, gid...@sasktel.net wrote:
> On Saturday, March 4, 2017 at 1:02:31 PM UTC-6, Antoine Vignau wrote:
> > asl
> > sta the two ss
> > sta table+1
> > 
> > why use X?
> 
> 
> Just trying to cover all the bases.  If you use the 65c02 mnemonic, you need the x-reg.
> 
> I mentioned in my first post that you can leave out the ASL and just use the X-reg, but the X-reg would need to be a multiple of 2.
> 
> And the same goes for here, you can use the x-reg for passing parameters and just use the accumulator for the routine #.  And change the "STX table+1" to a "STA table+1".
> 
> And as noted, the "JSR table" was missing
> 
> The choice is yours to what programming style you adopt.

Here is a compact 6502 routine which uses 7 bytes of stack and can be used to run code in aux mem or return to code in main:

01F9:99 04 C0  STA $C004,Y
01FC:99 02 C0  STA $C002,Y
01FF:60        RTS

To call an aux function:

JSR to a helper routine in main memory which:
pushes the aux address-1 onto the stack
LDY #1
JMP $1F9

The aux function returns via:

LDY #0
JMP $1F9

The helper routine can use a main memory lookup table for the aux function address and push it onto the stack, or the helper routine can just push the constant address of a dispatcher function in aux memory which will use the A or X register and an aux-memory dispatch table to call the destination function.

The aux function return-to-main can be automated with two more bytes of stack page:

01F7:A0 00     LDY #0

The helper function pushes #$01F6 to the stack first, then the aux dest address-1, then LDY #1, JMP $1F9. With this approach, an RTS from the aux memory destination function will RTS to $1F7 and return to the caller in main memory.

Hope that helps,
-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web