LOAD and SAVE are commands for BASIC.
Noone have implemented them in CLIsP.
That is why we suggest someone implements "(READ_SRC mem-loc)", but it's not implemented yet.
And if you know LISP you would know to call a command would be:
But this won't work as mentioned as noone has implemeted it. This would be a much larger task than implementing READ_SRC. That's why it was suggested that someone implemented READ_SRC instead.
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
The problem is that my LISP implementation on the ZX81 uses the exact same system used by ZEDIT: the way the LISP works is to "learn" the text sentences loading the logic into its data structures. To keep the text version in memory would halve the available memory for the programs, moreover ZEDIT requires 48K of memory, and couldn't live together with the LISP interpreter.
I rather hoped to find a way to read the text sequentially from a file, char by char.
the memory map of ZEDIT (while running) is:
16K-32K: ZEDIT program
32K up to 48K: ASCII text (created by ZEDIT)
48K-64K: ZEDIT workspace, stack and clipboard
After ZEDIT is stopped, the 16-32K and 48-64K regions may be used by other programs, while the text (CLISP program) is still at 32K.
Thus by running a BASIC or C program, the text (at least the first 8K) could be copied from 32K to unused region 8K-16K.
Then if CLISP is running (now having free ram from 16K-64K), it could fetch the text from 8K and handle it like input from keyboard (building up its internal tables in CLISP ram 16-64K).
So ZEDIT may be used to create the program, but is no more in memory while CLISP is running.
A different question is: can a CLISP "program" be saved from and reloaded back into the internal data tables (as binary file, using ZXPAND or USB-stick)?
PS: reading a file seqentially is possible using ZxPand or USB-Stick, but not in a standard C compatible way
By the way, here's what I could do for ZEDIT: I shifted such hardcoded structures towards the 48K memory bottom thus leaving about 16K of memory space for the text. On start, CLISP will pick the text from memory starting at 32768 and will get back to the normal interactive mode when chr(0) or chr(26) are found.. in this way the text can be fed by ZEDIT.
For the sake of simplicity it initializes the memory structures rather than expecting a pre-loaded block, so there was no space in the 16K area for the full command set: it is provided in "MINIMALISTIC" mode, which means that the following functions won't be available unless they'll be re-written in LISP (see minimalistic.l for some possible workaround):
The following turtle graphics functions are available in low resolution mode: cls, penu, pend, left, right, fwd.
This version REQUIRES an initial LISP code portion properly terminated @32768, the interpreter will crash otherwise.
The configuration is similar, full sized integer types, minimalistic function set, lo rez graphics..
The differences are on the memory structure position (here it is at 32768) and on the fact that in this case the initialization is provided by a different program block to save memory.
It should be possible to do the same for the ZEDIT version, this could make it more practical, I'd wait for your comments before providing too many variants which can be confusing.
Read the two posts before, this CLISP version mixes them all: you can save the memory area between 32768 and 65535 to keep both the text area and the 'live' LISP memory, or only the bottom part (starting at 49151) to keep only the live program memory, which the first time MUST be initialized with clisp-zedit-init.p.
The text area could hold new commands only or resubmit edited versions of the commands already in memory.
Calling the garbage collector "(gc)" should wipe the previous version.
I repeat: this ZEDIT dependent version MUST have also some valid text @32768, so before running clisp-zedit you must initialize both the memory structure AND the text area !
load TURTLE.TXT to 32768
BTW: for WIN systems the termination char 26 is better than char 0: some text editors handle a \0 terminated file as binary data, but accept char 26 as well-known EOF since CP/M times