izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
105acedab8
collapseos/apps/shell/fs.asm

76 lines
1.4 KiB
NASM
Raw Normal View History

Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
; *** SHELL COMMANDS ***
fsOnCmd:
.db "fson", 0, 0, 0
jp fsOn
; Lists filenames in currently active FS
flsCmd:
.db "fls", 0, 0, 0, 0
Make the shell a userspace app 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.
2019-11-15 15:37:49 -05:00
ld iy, .iter
call fsIter
ret z
Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
ld a, FS_ERR_NO_FS
ret
Make the shell a userspace app 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.
2019-11-15 15:37:49 -05:00
.iter:
ld a, FS_META_FNAME_OFFSET
call addHL
call printstr
jp printcrlf
Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
; Takes one byte block number to allocate as well we one string arg filename
; and allocates a new file in the current fs.
fnewCmd:
.db "fnew", 0b001, 0b1001, 0b001
push hl
ld a, (hl)
inc hl
call intoHL
call fsAlloc
pop hl
xor a
ret
; Deletes filename with specified name
fdelCmd:
.db "fdel", 0b1001, 0b001, 0
push hl
call intoHL ; HL now holds the string we look for
call fsFindFN
jr nz, .notfound
; Found! delete
Make the shell a userspace app 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.
2019-11-15 15:37:49 -05:00
call fsDel
jr z, .end
; weird error, continue to error condition
Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
.notfound:
ld a, FS_ERR_NOT_FOUND
.end:
pop hl
ret
; Opens specified filename in specified file handle.
; First argument is file handle, second one is file name.
; Example: fopn 0 foo.txt
fopnCmd:
.db "fopn", 0b001, 0b1001, 0b001
push hl
push de
ld a, (hl) ; file handle index
Make the shell a userspace app 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.
2019-11-15 15:37:49 -05:00
call fsHandle
; DE now points to file handle
Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
inc hl
call intoHL ; HL now holds the string we look for
call fsFindFN
jr nz, .notfound
; Found!
; FS_PTR points to the file we want to open
fs: standardize file handle routine argument to IX Using HL/DE was awkward and error-prone.
2019-05-31 14:06:24 -04:00
push de \ pop ix ; IX now points to the file handle.
Extract fs_cmds.asm from fs.asm
2019-05-16 13:13:46 -04:00
call fsOpen
jr .end
.notfound:
ld a, FS_ERR_NOT_FOUND
.end:
pop de
pop hl
ret
Reference in New Issue Copy Permalink