Bet you didn't think you'd see a topic from me.

In any case, we just discussed it on IRC, and there's a pretty simple way to call one axe program from another.

Copy("prgmNAME",33912,9
asm(EF7C4E)

This will work as long as prgmNAME is in ram, so if it's not, you'll have to unarchive it first. Hopefully someone has fun with this.

Edit:
   And here's how you do Basic programs.

Nice, I totally forgot about the BASIC one until it was linked to on IRC earlier. Glad to see an Axe one. Can conflict happen between programs?

can you call the program within the program that is being called?

Does this work with any ASM program or just ones compiled with Axe?

If you want a program to call itself, just put a label at the beginning of the program and call it using a normal subroutine, I'd say.

It doesn't work... it always crash.

Make sure the Asm program is compiled for No Shell, or else it will crash

Yes, it's OP1. Yes, control is returned the caller. This code just calls the OS routine that runs assembly programs. You can even run unsquished programs this way. (Ignore the last statement if you don't know what a squished program is.)

However, keep in mind a few things:

• Just like running programs with the Asm( token from the homescreen, you need a quantity of free RAM equal to the size of the program being run.
• Because the OS has to shuffle RAM around for this to work, it takes a split second for the new program to start. So if you do this a lot, it'll be really slow.
• If you call yourself like this, the OS will make yet another copy of yourself. Duh.
• Instant quit will return control to the calling program, not the homescreen or the shell. This is because the error handlers get nested. (The good news is that if the calling program throws an OS error, control is returned to the calling program, but I don't believe any Axe programs use error handlers.)
• By extension, do not call a shell's instant quit routine, or the memory used by caller won't get freed.
• Assuming Axe just makes a stub ISR that jumps to the real ISR, you're going to get a crash if you have an interrupt running and you try this, because your ISR just got moved.
• L1 through L6 will not be modified by the OS, neither during calling nor returning. The OP registers, however, will be corrupted.

Huh. . . . it looks like you're doing nothing wrong. I wrote a test program myself and found a problem in the disassembly:

prgmA
.AAA
Disp "ONE...",i
Copy("prgmAAAA",33912,9
Asm(EF7C4E
Disp "...ONE.",i
Pause 2000
prgmAA
.AAAA
Disp "TWO",i
Disassembly:
prgmAAA
9D95: ld hl, 9DC3 ; Disp "ONE...",i
bcall(_450A)
bcall(_452E)
ld hl, 9DCAh ; Copy("prgmAAAA",33912,9
push hl ; Load arguments in a complicated fashion
ld hl, 8478h
ld bc, 0009
ex de, hl
pop hl
ldir ; Copy the data
ldir ; Clobber all of RAM
ld c, (hl) ; ???
ld hl, 9DD0h ; Disp "...ONE.",i
bcall(_450A)
bcall(_452E)
ld hl, 07D0h ; Pause 2000
9DBB: djnz 9DBB
dec hl
ld a, l
or h
jr nz, 9DBB
ret ; End of program code
9DC3: .db "ONE...", 0
9DCB: .db ProgObj, "AAAA", 0
9DD0: .db "...ONE.", 0
prgmAAAA
9D95: ld hl, 9D9F ; Disp "TWO",i
bcall(_450A)
bcall(_452E)
ret ; End of program code
9D9F: .db "TWO", 0
For some reason, Axe 1.1.2 is inserting the ldir twice, clobbering all of RAM. NOPing one of the ldirs out fixes it.


EDIT: Runer112 has a workaround for you:

(6:43:18 PM) DrDnar: Runer112: I found an Axe bug, see http://ourl.ca/15239/286978
(6:43:32 PM) Runer112: I saw
(6:43:39 PM) DrDnar: k
(6:43:53 PM) Runer112: I can tell you it's a peephole optimizer problem
(6:44:00 PM) Runer112: so you can fix it by compiling without peephole opts [Use ZOOM---DrDnar]
(6:44:08 PM) Runer112: but I can't tell you why it's happening
(6:44:48 PM) Runer112: I'm sure Quigibo will know it's a peephole optimizer problem too
(6:44:51 PM) Runer112: it's pretty clear