019d05f64c
That's my mega-commit you've all been waiting for. The code for the shell share more routines with userspace apps than with kernel units, because, well, its behavior is that of a userspace app, not a device driver. This created a weird situation with libraries and jump tables. Some routine belonging to the `kernel/` directory felt weird there. And then comes `apps/basic`, which will likely share even more code with the shell. I was seeing myself creating huge jump tables to reuse code from the shell. It didn't feel right. Moreover, we'll probably want basic-like apps to optionnally replace the shell. So here I am with this huge change in the project structure. I didn't test all recipes on hardware yet, I will do later. I might have broken some... But now, the structure feels better and the line between what belongs to `kernel` and what belongs to `apps` feels clearer.
36 lines
669 B
C
36 lines
669 B
C
.equ SHELL_RAMSTART 0x4100
|
|
.equ USER_CODE 0x4200
|
|
|
|
; *** JUMP TABLE ***
|
|
.equ strncmp 0x03
|
|
.equ upcase @+3
|
|
.equ findchar @+3
|
|
.equ blkSelPtr @+3
|
|
.equ blkSel @+3
|
|
.equ blkSet @+3
|
|
.equ blkSeek @+3
|
|
.equ blkTell @+3
|
|
.equ blkGetB @+3
|
|
.equ blkPutB @+3
|
|
.equ fsFindFN @+3
|
|
.equ fsOpen @+3
|
|
.equ fsGetB @+3
|
|
.equ fsPutB @+3
|
|
.equ fsSetSize @+3
|
|
.equ fsOn @+3
|
|
.equ fsIter @+3
|
|
.equ fsAlloc @+3
|
|
.equ fsDel @+3
|
|
.equ fsHandle @+3
|
|
.equ printstr @+3
|
|
.equ printnstr @+3
|
|
.equ _blkGetB @+3
|
|
.equ _blkPutB @+3
|
|
.equ _blkSeek @+3
|
|
.equ _blkTell @+3
|
|
.equ printcrlf @+3
|
|
.equ stdioGetC @+3
|
|
.equ stdioPutC @+3
|
|
.equ stdioReadLine @+3
|
|
|