Campus LIsP (32K)
Re: Campus LIsP (32K)
I think you misunderstand.
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:
(LOAD HANOI.I)
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.
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:
(LOAD HANOI.I)
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.
Re: Campus LIsP (32K)
Ja, wäre schön wenn die Befehle für ZXPand auch funktionieren würden.
Gruss
Gruss
Re: Campus LIsP (32K)
Followup on the file topic. I recently worked with ZEDIT and I finally understood your suggestions.
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 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.
Re: Campus LIsP (32K)
Hi Stefano
the memory map of ZEDIT (while running) is:
8-16: unused
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)?
Siggi
PS: reading a file seqentially is possible using ZxPand or USB-Stick, but not in a standard C compatible way
the memory map of ZEDIT (while running) is:
8-16: unused
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)?
Siggi
PS: reading a file seqentially is possible using ZxPand or USB-Stick, but not in a standard C compatible way
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
http://zx81.ddns.net/ZxTeaM
Re: Campus LIsP (32K)
First of all let me answer to your last question: I already provided a CLISP version for the 32K expansion which does not initialize the data structures. Such structures are statically placed in the memory region over 32768, and can be saved/restored at your convenience, e.g. after exiting with "(quit)".
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):
"<", "and","divide","lambda","while",">=","<=","comment","zerop","atom","random","rem","1+","1-","equal","="
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.
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):
"<", "and","divide","lambda","while",">=","<=","comment","zerop","atom","random","rem","1+","1-","equal","="
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.
Re: Campus LIsP (32K)
I thought to provide also a similar version for those models with 32K only.
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.
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.
Re: Campus LIsP (32K)
Variant for ZEDIT with parted structure initialization.
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 !
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 !
Re: Campus LIsP (32K)
One more example, with zero termination for ZEDIT:
Re: Campus LIsP (32K)
I did this (56K Zeddy, ZEDIT version):
load TURTLE.TXT to 32768
run "clisp-init"
run "clisp"
Result is
Siggi
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
load TURTLE.TXT to 32768
run "clisp-init"
run "clisp"
Result is
Siggi
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
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
http://zx81.ddns.net/ZxTeaM