izaya
/
collapseos
mirror of https://github.com/hsoft/collapseos.git
1
0
Fork 0
Code Issues Releases Wiki Activity
collapseos/apps/ed/io.asm

64 lines
935 B
NASM
Raw Normal View History

apps/ed: start implementing I/O
2019-07-14 01:29:06 +10:00
; io - handle ed's I/O
; *** Consts ***
;
; Max length of a line
.equ IO_MAXLEN 0x7f
; *** Variables ***
ed: take filename as an argument This hard-binds ed to the filesystem (I liked the idea of working only with blockdevs though...), but this is necessary for the upcoming `w` command. We need some kind of way to tell the destination to write to truncate itself. This only has a meaning in the filesystem, but it's necessary to let the file know that its registered file size has possibly shrunk. I thought of alternatives that would have allowed me to keep ed blkdev-centered, but they were all too hackish to my own taste. Hence, this new hard-bind on files.
2019-07-21 09:35:19 +10:00
; Handle of the target file
.equ IO_FILE_HDL IO_RAMSTART
; block device targeting IO_FILE_HDL
.equ IO_BLK IO_FILE_HDL+FS_HANDLE_SIZE
apps/ed: start implementing I/O
2019-07-14 01:29:06 +10:00
; Buffer for lines read from I/O.
ed: take filename as an argument This hard-binds ed to the filesystem (I liked the idea of working only with blockdevs though...), but this is necessary for the upcoming `w` command. We need some kind of way to tell the destination to write to truncate itself. This only has a meaning in the filesystem, but it's necessary to let the file know that its registered file size has possibly shrunk. I thought of alternatives that would have allowed me to keep ed blkdev-centered, but they were all too hackish to my own taste. Hence, this new hard-bind on files.
2019-07-21 09:35:19 +10:00
.equ IO_LINE IO_BLK+BLOCKDEV_SIZE
apps/ed: start implementing I/O
2019-07-14 01:29:06 +10:00
.equ IO_RAMEND IO_LINE+IO_MAXLEN+1 ; +1 for null
; *** Code ***
ed: take filename as an argument This hard-binds ed to the filesystem (I liked the idea of working only with blockdevs though...), but this is necessary for the upcoming `w` command. We need some kind of way to tell the destination to write to truncate itself. This only has a meaning in the filesystem, but it's necessary to let the file know that its registered file size has possibly shrunk. I thought of alternatives that would have allowed me to keep ed blkdev-centered, but they were all too hackish to my own taste. Hence, this new hard-bind on files.
2019-07-21 09:35:19 +10:00
; Given a file name in (HL), open that file in (IO_FILE_HDL) and open a blkdev
; on it at (IO_BLK).
ioInit:
call fsFindFN
ret nz
ld ix, IO_FILE_HDL
call fsOpen
ld de, IO_BLK
ld hl, .blkdev
jp blkSet
.fsGetC:
ld ix, IO_FILE_HDL
jp fsGetC
.fsPutC:
ld ix, IO_FILE_HDL
jp fsPutC
.blkdev:
ed: make scratchpad memory only The dual scraptchpad thing doesn't work. Things become very complicated when it's time to write that back to the file. We overwrite our contents and end up with garbage.
2019-07-21 22:47:42 +10:00
.dw .fsGetC, unsetZ
ed: take filename as an argument This hard-binds ed to the filesystem (I liked the idea of working only with blockdevs though...), but this is necessary for the upcoming `w` command. We need some kind of way to tell the destination to write to truncate itself. This only has a meaning in the filesystem, but it's necessary to let the file know that its registered file size has possibly shrunk. I thought of alternatives that would have allowed me to keep ed blkdev-centered, but they were all too hackish to my own taste. Hence, this new hard-bind on files.
2019-07-21 09:35:19 +10:00
ioGetC:
push ix
ld ix, IO_BLK
call _blkGetC
pop ix
ret
ioPutC:
push ix
ld ix, IO_BLK
call _blkPutC
pop ix
ret
ioSeek:
push ix
ld ix, IO_BLK
call _blkSeek
pop ix
ret
ioTell:
push ix
ld ix, IO_BLK
call _blkTell
pop ix
ret