This is something I'm currently tinkering around with at the moment to make my future projects easier.
The runtime is based off of the C runtime, and will have at least these 7 functions:
Code:
When a program is linked with this, the main function will receive the number of arguments passed to the program in 'a', a pointer to a list of arguments in 'hl', and the magic number $7105 ("TIOS") in 'de'.
The way this works is pretty simple. The runtime pretty much hogs tempSwapArea for it's nefarious plot to the conquer the universe. When the execve function is called, it'll write the magic value $7105, the argument count, and the list of arguments to this area of memory before actually launching the program. If the program uses this runtime as well, the _start function will check tempSwapArea for these value, and pass them to the main function. The program itself will know it was called with execve because 'de' will be set to $7105.
Next is sbrk. The "legit" way to do this to extend the ram being used by the running program which I'm fairly certain is possible. If I'm wrong, I'll cut this one out and instead design the memory library to make use of saveSScreen, plotSScreen, statVars, and appBackUpScreen.
The use of overlays will be really helpful in working around RAM limitations. They'll all be stored in archive memory by default. When the user loads one, it's copied into ram and the loader performs relocations, imports, and exports on it. The overlay itself should only use short jumps and addresses that have been relocated
Code:
Working with them will be tricky, but worthwhile as you can make enormous programs that have full access to the DoorsCS api.
The runtime is based off of the C runtime, and will have at least these 7 functions:
Code:
_start - the entry point for the program
_exit - the exit point for the program
_execve - execute a program with arguments
_sbrk - set break value for program
_alloc - allocate memory
_realloc - reallocate memory
_free - free memoryWhen a program is linked with this, the main function will receive the number of arguments passed to the program in 'a', a pointer to a list of arguments in 'hl', and the magic number $7105 ("TIOS") in 'de'.
The way this works is pretty simple. The runtime pretty much hogs tempSwapArea for it's nefarious plot to the conquer the universe. When the execve function is called, it'll write the magic value $7105, the argument count, and the list of arguments to this area of memory before actually launching the program. If the program uses this runtime as well, the _start function will check tempSwapArea for these value, and pass them to the main function. The program itself will know it was called with execve because 'de' will be set to $7105.
Next is sbrk. The "legit" way to do this to extend the ram being used by the running program which I'm fairly certain is possible. If I'm wrong, I'll cut this one out and instead design the memory library to make use of saveSScreen, plotSScreen, statVars, and appBackUpScreen.
The use of overlays will be really helpful in working around RAM limitations. They'll all be stored in archive memory by default. When the user loads one, it's copied into ram and the loader performs relocations, imports, and exports on it. The overlay itself should only use short jumps and addresses that have been relocated
Code:
; Program Name: testovl
; Author: DaemonR
; Version: 1.0
; Date: 9/6/2014
; Written for Doors CS 7.0 and higher (http://dcs.cemetech.net)
;
; This is a test of the overlay system
.nolist
#include "ti83plus.inc"
#include "../source/overlay.inc"
.list
.org $0000
.db $BB,$6D
init:
xor e
jr _start
.dw RelocationTable ; Pointer to relocation table
.dw ImportsTable ; Pointer to imports table
.dw ExportsTable ; Pointer to exports table
_start:
printEntrypointAddr:
xor a
call GetOverlayReloc ; get first relocation address in hl
push a ; push 'a' for imported function
call ImportFunction ; execute import function #1
ret
RelocationTable:
.dw 1 ; Number of relocations
.dw _start ; address
ImportsTable:
.dw 1 ; Number of imports
.db $0A ; id (eg. "_VDispHL")
.dw $0000 ; address
ExportsTable:
.dw 1 ; Number of exports
.db $F7 ; id
.dw printEntrypointAddr ; address
Working with them will be tricky, but worthwhile as you can make enormous programs that have full access to the DoorsCS api.