Executing Action! commands from within an Action! program

[+slx]

Is there an - even "illegal" (or at least non-portable) way to execute Action! commands (e.g. loading a file into an editor window) from within an Action! program. I suppose it must somehow be possible to fill the command into where Action! has the respective buffer and then call the correct subroutine but I don't understand the source code enough to look for that myself.

 

 

[Rybags]

I'd highly doubt it - it's a compiled language so there's distinct entities in program editor, compiler, runtime libraries.

 

Though you could possibly do it by a program which keeps a VBlank routine running then feeds keystrokes to E:

[ricortes]

I am not sure exactly what you are asking. Generally Action is so loose you can do just about anything if you know the internals. More then one way to do it, for instance you can just compile everything under a DOS with a high LOWMEM and it will be backwards compatible or you can set the start of your program high enough so it will be compatible with all DOS's. Doing this on the fly so expect pseudo code and mistakes.

 

SET $E=$2000

SET $491=$2000

INCLUDE "D:RUNTIME.ACT"

Proc Main()

;Bunch of your mainline code here

;and call to your multiple modules after they are loaded

RETURN

You compile that and write to disk. The entire runtime and program will be contiguous. Now for your first overlay you do something like

SET $E=$2000

SET $491=$2000

INCLUDE "D:RUNTIME.ACT"

SET $E=$5000

SET $491=$5000

Proc Cute()

Poke(82,0)

RETURN

Now compile that and save from the monitor. The only part that will be saved is after the second SET directives i.e. only the Poke. The magic is in the symbol table locations are the same between the two programs. That is, the location of the Poke() routine is going to be the same between the main and the overlay. From the Monitor, you can determine where the Cute() procedure is located using the X<ecute> or dump commands.

 

You add this to your program with something like

Cute()*=$5003 <or whatever the address and formats for declaring the memory locations of a subroutine are>

 

You load the overlays into memory by whatever method you want i.e. simple get byte routine or binary load, then call it from your mainline code.

 

There may be other ways of doing it. Like starting with runtime, then multiple Cute() type routines all resetting the compile location to $5000, followed by Main() with the set directives at $2000 + space for run time package so the symbol table does all the manual work for you, just that I never tried them.

[Alfred]

No you can't do it, because the compiler reuses many of the variables for the editor. If you were to do so, it would blow up execution of the program, most especially because of the zero page variables.

[ricortes]

More confusion about what is being said and attempted me thinks.

 

This works fine. Probably should do a set before the first run as it may mung the editor buffer, but anyway.

SET $E=$5000

SET $491=$5000

PROC CUTE()

POKE(82,0)

RETURN

SET $E=$2000

SET $491=$2000

PROC MAIN()

PRINTCE(CUTE)

PRINTCE(MAIN)

RETURN

Output is

20483

8196

=> hex $5003 and $2004

Of course you couldn't run it or even compile it to disk and have it work with multiple overlays, just that MAIN() will end up with the right entry points and subroutines contained therein. You would still have to compile each overlay and save to disk separately for later loading. Otherwise, it works exactly as I expected it to work for keeping track of procedure locations. Do you need a more detailed explanation to understand what I am saying and doing? Not a complete or workable program as is, just shortens the task of finding entry points and should eliminate the need for the

Cute()*=$5003

type method of getting them into MAIN().

[+slx]

Thanks for the vectors. Will try to comprehend

[ricortes]

Just a BTW: If you really want to damage some brain cells, down load the official OSS run time disk and documentation. Every other run time is easier to understand, just include it, but the docs that come with the official release are pretty much invaluable. They have suggestions in there like e(x)ecute an immediate command in the monitor to expand your symbol table rather then use the one that loads from disk. Really informative IMHO.