SDCC Ejecutables con retorno a BASIC

[KaosOverride]

Muy buenas

Sigo trasteando con SDCC y tenia intencion de hacer "comandos externos" que hagan una funcion y vuelvan al BASIC.

¿Alguien se ha topado con esta situacion?

He llegado a este punto:

-Metodo LOAD:

Código: Seleccionar todo

MEMORY &progdir-1
LOAD"code.bin",&progdir
CALL &progdir

-Metodo RUN:

Código: Seleccionar todo

RUN"code.bin

El metodo LOAD" funciona genial, pero el metodo RUN" que es el que me interesa no... Probando con un "Hello world!" al usar LOAD me pone el Hello world!! y vuelve al BASIC perfectamente, el metoso RUN" borra la pantalla y pone el cursor en 1,1 (Como un CLS) muestra el Hello world!! y resetea el CPC

Por si fuera por el BASIC, he hecho un MEMORY &progdir-1 antes del RUN" y aun asi hace igual, ya que me estaba planteando enredar el codigo y manipular el valor de HIMEM desde el codigo binario, pero o bien el RUN" lo reinicializa o hace mas cosas que lo invalidan.

Entiendo que la diferencia entre el LOAD/CALL y RUN es que entre el Ready y la ejecucion en el primero es casi directa, en el segundo caso entre el Ready y la ejecucion esta el firmware tocando las narices con el acceso a ficheros.

[pacomix]

¡Hola!

Nunca lo he intentado ya que el código que he hecho es un bucle sin fin. Pero lo que puede estar pasando es que coloques el puntero de pila en otra parte en la rutina de inicialización de tu programa y machaques el que ya existe.
Prueba en tu programa a guardar el puntero de pila en otra parte antes de cambiarlo y luego restaurarlo al valor anterior. O mejor aún... ni lo toques. Tendrás que mirar también dónde estás cargando el binario y ver si estás machacando la pila.

Estoy hablando sin saber exactamente como el firmware lo maneja, lo mismo es incorrecto, pero todo apunta a que es algo relacionado.

¡Saludos!

[dinoneno]

Otra idea. ¿Te has asegurado qué dirección de ejecución tiene el archivo bin en el disco? Me refiero al que sería el tercer valor numéricos si lo hubieses grabado con el comando SAVE del Locomotive Basic.

[KaosOverride]

Buenas

Si, el ejecutable se compila con el CRT0 con entrada en &4000, el codigo MAIN en &4038 y el binario resultante lo inyecto en el DSK con las direcciones &4000 tanto de inicio como de ejecucion. Prueba de ello es que con el LOAD" funciona en esa direccion y retorna.

Tambien veo que las variables las maneja en &BFEx?? eso creo que es espacio de pila... para manejar un buffer de 512 bytes he tenido que definirlo como datos incrustados en un segmento ASM como con los tiles y sprites en la cpcrslib...

Lo que me mosquea es que con el RUN" borra la pantalla y con el LOAD" no, y yo en mi codigo no pongo ni que borre pantalla o cambie de modo...

[pacomix]

KaosOverride puedes poner el código fuente de SDCC como archivo adjunto? Podría luego echarle un vistazo.

[KaosOverride]

No es algo del codigo fuente ya que hasta con un hola mundo me pasa. Con LOAD/CALL retorna y con RUN no.
Las variables las he agregado al hola mundo y con unos printfs de sus direcciones con &var y demas

Luego cuando tenga un rato igual me pongo a cotillear la pila con los dos casos LOAD y RUN, y busco las diferencias. Igual puedo falsear la pila y retornar por fuerza bruta... benditos emuladores con sus debugs ingegrados...

[FloppySoftware]

Hola.

Lo mío es el PCW, así que poco sé de CPC, pero si el BASIC de ambos se parece algo, entiendo que RUN elimina el programa actual de la memoria, mientras que LOAD (especificando una dirección de memoria) no lo hace.

Yo creo que el problema estará ahí, y una consulta al manual de BASIC de CPC resolvería la duda.

Buscando en la red, encuentro que:

RUN <alphanumeric chain>

RUN "disc"

COMMAND: Load and run a program BASIC or a program-object located on the diskette. Any program present in memory is automatically crushed.

Mientras que:

LOAD <filename>[,<adress>]

LOAD"fichdisc.xyz",&2AF8

COMMAND: Load a BASIC program in memory, and crunch any other one in place. With the adress option, load a binary file with the address indicated instead the address where it was at the time of the safeguard.

Saludos.

[pacomix]

Supongo que entonces el CALL guarda automáticamente el SP y la dirección por la que tiene que seguir ejecutando y luego la recupera y el RUN evidentemente pasa de todo eso.

En tu main que ejecutas con run intenta simplemente guardar todos los registros y el puntero de pila en algún lugar y luego a la salida de tu programa recupéralo y luego recuperas todos los registros. Supongo que eso es lo que hará el CALL (pero sin modificar los registros). Lo que no sé luego es a dónde tendrías que saltar una vez termines la ejecución de tu programa.
Mírate la guía del firmware.

CALL supongo que guarda la dirección actual de ejecución y luego vuelve a ella una vez que se termina de ejecutar tu programa.
RUN hará un salto absoluto a la dirección de ejecución y una vez que tu main() termina el puntero PC seguirá ejecutando basura hasta que llega al final y se resetea al llegar a la dirección 0.

supongo...

[KaosOverride]

Resuelto el averiguar como sucede:

De http://www.cpcwiki.eu/index.php/BIOS_Ca ... _Functions

Machine Pack Boot Program

BD13 MC_BOOT_PROGRAM ;in: HL=loader_callback, out: starts program

Loads and starts a BINARY program, typically used when typing RUN"filename.bin" under BASIC. The callback should load the program from whatever source (CAS, DISK, or elsewhere), and should then return CY=1=okay & HL=entrypoint (or HL=0000h to reboot the BASIC ROM), or CY=0=failed. If the callback returns CY=1 then the program (or BASIC ROM) is started via MC_START_PROGRAM, otherwise, when CY=0, "*** PROGRAM LOAD FAILED ***" is displayed, and the OS (ie. typically BASIC) is restarted.
Machine Pack Start Program

BD16 MC_START_PROGRAM ;in: HL=entrypoint (0000h=BASIC), C=ROMcfg

Starts a BINARY program, typically used when typing RUN"filename.bin" under BASIC (expecting that the file is already loaded into memory). The function resets all BIOS memory, sets SP=C000h, DE=LORAM=0040h, HL=BAS_HIRAM=ABFFh, BC=BIN_HIRAM=B0FFh, and does then call the entrypoint (incoming C:HL) via RST 18h, if incoming HL was zero then it calls 0:C006h (ie. reboots the BASIC ROM). Observe that the program is started with only the raw BIOS initialized; but without extensions like AMSDOS. To install them (if needed), the entrypoint function should set HL=BC (to deallocate BASIC RAM), then call KL_ROM_WALK (to install all extension ROMs) or, set C=07h and call KL_INIT_BACK (to install only AMSDOS).

Estas dos funciones se llaman secuencialmente desde la orden RUN"code.bin". La primera carga y la segunda lo ejecuta, pero antes de hacerle el call, nos lia esto:

The function resets all BIOS memory, sets SP=C000h, DE=LORAM=0040h, HL=BAS_HIRAM=ABFFh, BC=BIN_HIRAM=B0FFh, and does then call the entrypoint

Vamos, que resetea la pila y deja en DE, HL y BC parametros para saber el HIMEM del BASIC, y otro ¿himem de binarios? Y de paso desactiva todas las ROMS (Amsdos entre ellas) por lo que da mas o menos por hecho que el ejecutable es para no volver de el salvo que sea por un hard reset Va a tocar hacer demasiado para currarse un "retorno" limpio... En el peor de los casos deberia ser un KL_ROM_WALK de esos y reejecutar BASIC (perdiendo el programa BASIC en RAM, pero eso lo podemos dar por hecho al usar el BASIC como una especie de shell)

[pacomix]

Bueno... y pa qué quieres hacer eso?

[KaosOverride]

Pues para compilar cualquier tonteria que mas adelante pueda necesitar en ese formato xD

Estoy haciendo algunos programas que hacen pruebas IO en puertos, pero me parece una tonteria el andar reiniciando el CPC cada vez que hago un RUN"CODE.BIN"

Por ejemplo si me sale adelante el clavarle el WizNET al CPC me parece absurdo un RUN"PING", me pregunte la IP y que despues del ping me tenga que resetear el CPC

[pacomix]

A ver... Yo veo la cosa clara... Si quieres usarlo desde BASIC y con retorno para eso esta el CALL

[dinoneno]

Visto lo que hay, o por cada programa creas un binario y un cargador BASIC que use tu método LOAD, o empaquetas todos los programas en un grupo de RSX, que además le puedes pasar parámetros.

[KaosOverride]

Tambien puedo indagar un poco en los compactados de CngSoft, ya que es un basic con binario pegado que despues le hace un call... Igual no necesito siquiera que vaya compactado...

[pacomix]

Tal vez no he entendido exactamente el por qué del RUN.

Si necesitas mezclar rutinas de CM en Basic para eso está el CALL.
O como bien han dicho te lo puedes crear como rutinas residentes (comandos externos?). Aquí tienes un link con código fuente explicado:

http://www.cpcwiki.eu/index.php/Program ... fine_a_RSX