durexforth
durexforth copied to clipboard
jkotlinski
Idea: Tiny text editor
v is bloated, code is over 4 kb. Another problem is that text buffer grows unbounded.
I propose to remove v from default included modules and replace it with t, tiny text editor.
The vision for t is that memory consumption will be no more 1 kb, including text buffer, and never exceed this fixed size.
@Whammo I haven't thought it through properly. But it would be nice to have the regular Forth "virtual memory" setup, where you have maybe three 1 kb-blocks mapped to RAM, that are swapped in/out to disk as needed.
One problem is that random access is not possible with regular PRG/SEQ files. But I think it should probably work fine to use REL files for Forth source code instead.
In short, I think I'd like a more block-like setup for source code, just to avoid the practical problems that come with having files of unlimited length. Of course, this is a very big and deep change so I'm not even sure if I'd ever get started with this one :-)
One problem is that random access is not possible with regular PRG/SEQ files. But I think it should probably work fine to use REL files for Forth source code instead.
Yes it is. See U1 aka BLOCK-READ. You need to navigate the blocks by yourself but you can read a PRG file a block at a time.
I prefer the REL approach. You don't have to manage the disk structure yourself, but let the DOS do it :-)
That would be my hope, too, that REL files would require less and more simple code. But there could be drawbacks with that approach that I’m not aware of.
On Sat, 26 Dec 2020 at 02:13, Stefan [email protected] wrote:
I prefer the REL approach. You don't have to manage the disk structure yourself, but let the DOS do it :-)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jkotlinski/durexforth/issues/311#issuecomment-751306333, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY34O22AYQX5QL4R5Y7HVDSWU2DFANCNFSM4VBXO3UA .
Copying screens to memory seems to be the key to swift pagination, and reading the screen as a file seems to be the key to saving. Perhaps if the compiler were interfaced as a device it would be interesting?
If you use REL the DOS seeks the record, but raw sectors require your own calculation.
So a line-length record REL file created on the fly by reading the PRG, edited by inserting and deleting records then saved to PRG.
Although, maximum record size is 254 bytes. Four of these make one screen with four bytes left over for each record. These four bytes could be logical forward and backward links for out-of-sequence inserts to be justfied at save. For a continuous scroll you would only need 1500 bytes in RAM
Each sector has a track and sector pointer to the next sector in the file. It also points out when it is the last sector in the file.
This feels like the most important remaining improvement.. Hope to find time and energy to start working on it this year.
I have been thinking about how to do file access, especially SEQ versus REL files. The pros and cons are pretty deep.
The main benefit with plain SEQ files, without any extras, is that it is minimally complicated. Especially when transfering to/from PC.
I think a way forward might be to add some of the File word set, enough to allow random read/write/append access to SEQ files. Under the hood, it would read and write sectors directly.
This setup is not super efficient. Maybe the worst is when inserting or erasing space in the start of a file, then the old file contents would need to be completely re-written, to handle the move to a new position.
A way to mitigate this problem is to do screen-based editing. Inserting/erasing screens is not something that one would do all the time, so it is kind of OK if it is slow.
Navigating between screens might be slow, as disk i/o happens as a result of navigating. But that is probably livable and hard to avoid.
Pygmy Forth has been mentioned as an elegant model for block-based file editing: https://github.com/utoh/pygmy-forth/blob/master/pygmy.txt
gforth also has block-based text editing: https://stackoverflow.com/questions/48837115/does-gnu-forth-have-an-editor
I've mentioned before that durexForth is my first time touching the C64. I've never written any programs that touch the disk yet, but in the Forth spirit of keeping things simple how about saving each block in a separate file named, say, "b001" "b002" etc.? Probably a bit wasteful of disk space, but if I understand saveb and loadb correctly it seems like the simplest reasonable thing. I wonder if that's what you meant when you said
But I think it should probably work fine to use REL files for Forth source code instead.
saving each block in a separate file named, say, "b001" "b002" etc.?
Technically, that would work just fine. And you are right, it would be the simplest reasonable thing. Maybe it is really the best idea. The files that comes with durexForth would stay as is, but the blocks created by the tiny text editor would be stored like "b001" "b002".
What I had in mind with REL files was more like how Gforth is described in the link two comments above. You create a file "mygame" and that file internally has 1024 byte big blocks.
I'm working on this "simplest" thing right now, a block with a single buffer. I think it's debugged now? Scratching files in VICE is sometimes flaky for me when I'm using snapstates (maybe I'm doing it wrong).
Some edit history of this post:
- Forgot the scratch the file first, fixed the code.
- Several trivial code edits. Now moved to a gist.
I have some idea to create Block wordset, that a future editor can be built on. I should just get working on it.
Some functionality for an editor could be:
F1=previous block F3=next block F5=save F7=execute F8=exit
Maybe that is all functionality needed.
About that. I might have written one (z: a block editor) as an exercise to see if I could, over the last week.
It's not quite as small as you wanted. 5.3K of source compiles to 2058 bytes. But it's rather well-featured. Only thing I've left to add really is line join. I didn't really want to make a repo because then I'd have to take responsibility for it :P
Though now I want to write one without any interactivity at all, just commands at the interpreter using the C64 screen editor. I'm sure it'll be a lot smaller. It was a fun exercise though.
Well, I think I wrote it. Less than 400 bytes compiled :tada:.
require block
marker -- \ -tt--
create scr 1 ,
: edit dup scr ! block drop ;
: line 32 * scr @ block + ;
: wipe 0 line 1024 bl fill ;
: scrub 0 line dup 1024 + swap
DO i c@ bl max 'Z' min i c! LOOP ;
\ [u-] ttype [-] llist aa bb cc dd
: 00. 0 <# # # #> type space ;
: tt dup 00. ." rr " line 32 type cr ;
: ttt DO i tt LOOP ;
: aa 8 0 ttt ;
: bb 16 8 ttt ;
: cc 24 16 ttt ;
: dd 32 24 ttt ;
: ll aa bb key drop cc dd ;
\ "[u-] wwhiteout rreplace
: in- source >in ! drop ;
: in/ source >in @ /string 32 min in- ;
: blf 32 bl fill ;
: ww line blf in- ;
: rr line dup blf in/ rot swap move ;
\ "[u-] iinsert xxdelete
: xx >r r@ 1+ line r@ line
992 r> 32 * - move 31 ww ;
: ii >r r@ line r@ 1+ line
992 r@ 32 * - move r> rr ;
Would have preferred bblank and ddelete, but aa bb cc dd are good listing names.
Either it needs a load word that patches 32-character lines into \ or you just use ( comments in your blocks :stuck_out_tongue:
vs buffer is a good source of text to play with. $a001 0 line 1024 move ss. aa bb cc dd ll type lines with rr already on them so you can screen edit and press enter as though you were using the basic editor. Or you can replace the rr with ww ii xx.
With parse in durexForth v5 I think you could rewrite in- in/:
: in/ $d parse ;
: in- in/ 2drop ;
The interpreter's ok prompt does like to overwrite line numbers. I could at-xy after an rr but that's also slightly inconvenient to use, having to cursor back to where you were.
I haven't dug into those editors of yours yet, but I really like the code!
I'm still noodling around with z, I'll never be satisfied with good enough. Latest revision just now is at least copypasted from the C64 so I know it compiles.
A new idea about Blocks, and how it could work with least code and maximum efficiency.
9 USEwill open device 9 for exclusive use by the Blocks word set.- All block access will use direct 256-byte sector access.
This means, all file access stay working exactly as is. But those who would like to write a program for fun, on the C64, can do that using a block editor. This means durexForth system disk, and block-based user code disk, would be two different disks, perhaps inserted in different drives.
I like it! I got a couple editors and a dumb block word that does saveb and loadb. If you want write a better block that's alright with me! :P
That is also a nice approach. Like, I have not fully thought through everything. But I think a major reason to use sector-based blocks access would be speed. I have not measured, but I assume sector-based blocks would be a lot faster. Especially if using true-drive emulation (or a real disk-drive).