you can find it here.
https://www.thefuturewas8bit.com/shop/c ... w1EALw_wcB




This is a big thread and haven't read it from start to finish yet. But yes, I can see how that works.



I have to think this through some more. This BLK, SCRN, LOAD and LINE method still seems quite cumbersome.




I would like to convert that to
OPEN filename




I think four buffers is almost the minimum. I will need 2 buffers to OPEN files and another 2 buffers for working on those files. I see now I can't get away from all those buffers. The first buffer houses the error messages, but since am working on a 128kb machine, I have some room to spare and might make the errors part of the system.



Fleet Forth is quite large and a C64 only has 64 kb memory? Is memory constraints so tight that it would be difficult to use graphics or write large applications with Fleet Forth?

It's possible to do more than you think with a single buffer. I was also trying to figure out what the minimum number of buffers was for TaliForth2, and I ended up trying to make it work with a single buffer and it actually worked! I can load a screen that has other LOAD or THRU commands in it. The trick is to put back whatever was in the buffer if it was in use before (and you can check that by looking in BLK). This is horribly inefficient time-wise, but makes it so only 1K is needed.

The single buffer actually made some of the coding easier because I didn't have to deal with a buffer that was being used for interpretation being re-loaded into a different location (which might happen if the code being interpreted touched enough different blocks to cause a round-robin or LRU-type replacement algorithm to reuse the buffer the code was in, and then reload it in a different buffer when it was time to resume processing). As long as the original screen being interpreted is put back into memory and the pointers/indices are pointing at the next word to process, you can just resume interpreting as if the buffer contents were always there.

More buffers, of course, makes it so the system doesn't have to thrash around trying to restore what used to be in a buffer if it still has a copy. Tali2 is designed for systems with 32K or less of RAM and some folks won't use the block words at all, so it made sense to have it use as little RAM as possible.

I use the block words for storing forth code and data on an I2C EEPROM and it works very well for that. Emacs has a special forth mode to save the code in block format that I use.

Under Prodos, the minimum would be 2 buffers. The OPEN file command needs 1 buffer reserved for information about the file. The 2nd buffer is needed for the READ command which reads the actual data of the file. I can read 1024 bytes at a time and compile a line at a time that ends in a CR delimiter.

With a text file, each line gets moved into PAD and the CR gets converted to a zero before compiling. When the end of the buffer is reached, then the next block is read in and compiling continues until the end of the file is encountered.

This idea will be similar in use to the SCRN# LOAD and SCRN# LIST words, but won't need the "-->" at the end of each 1024 byte block. The new word definition for loading text file getting compiled is with "LOAD filename" (without the quotes). This way I can have as many text file applications, utilities and games all on hard drive all at the same time and swap between them easily with LOAD TEXTFILE and FORGET TASK.

Both. But blocks are not padded with spaces like in screens. The idea is to load a text file which requites 2 buffers. One for the OPEN command and one for the READ command. Prodos requires the OPEN file buffer for information about the file. The READ buffer is for the actual data. A block (1024 bytes) of text gets read in at a time. Each line delimited by a CR is moved to PAD and the CR converted to a zero. That line gets compiled, then the next line gets read in. If the end of the buffer is reached and a line is cut off when being moved to PAD, then the next block gets read in. This continues until the end of the file is reached. The RUN word launches the last word that gets loaded and launches the application. This makes it easy to have all the applications, games, and utilities stored in text files and can be swapped easily between them with LOAD TEXTFILE and FORGET TASK.




I need a minimum 2 buffers for Prodos. The first one is reserved for information about the file and used by the Machine Interface and the second one is used to load the actual data.




In ProForth, LIMIT is pointing at the USER area with the buffers just underneath. FIRST is used to designate the start of the buffers. But I would prefer to have LIMIT designated to be the upper limit of free memory.




ProForth errors are actually part of a screen file. The screen file is a file on disk that houses 16 screens of 1024 bytes and takes up 1 constant buffer. But there is a lot of waste with the screens as every line is padded with spaces. Thus I want to make the errors part of the system and convert everything else to text file delimited by a CR to eliminate all the wasted space.




I am trying to weed the kernel down to being just the primitives required to compile a colon definition and code words. Everything else can be added through text file loading as required.




If all goes well, I believe I can get the bare kernel down to under 5 K. The system loader will move all the actual names and their CFA's of the words to Auxiliary memory along with a sorting algorithm. This sorter will cut compiling time down into a fraction of the time and also eliminates a lot of words when they are with their description. LFA, NFA, PFA, TRAVERSE, COUNT are no longer needed. And the dictionary of words can be listed in alphabetical order or just the words that are part of a VOCABULARY, which makes words easier to find in the list. I can also just list words that start with the first letter. Really nice not to have the entire word library listed every time.




I already have very nice system applications of these three, even though I have to leave FORTH. But I am not ready to re-invent the wheel right now.





Graphics is on my to-do list




I also have turtle graphics in an ML program. It wouldn't take much to separate the code and make word definitions for each turtle command.





This is where my theory of loading text files for an application can benefit. It can load larger programs in memory than can fit when creating them, as the editor and assembler are also in memory when creating applications. I will have the ability to clear the first words create and then append extra words to a text file.




I call my word decompiler DECODE and it does a pretty good job at decoding everything. The one problem I have to rectify yet is that -FIND returns the PFA of a word. The problem with that is that some words do not have a PFA. The CFA points somewhere else in memory. Then comes the big crash to the monitor.

Can your SEE decode BRANCH and 0BRANCH back into IF-ELSE-THEN or BEGIN-UNTIL (REPEAT or AGAIN) statements? I think I have it figured, but just when I think I have it figured out, I question my logic.

Oof ... that does seem like a tough nut to be able to reliably crack.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

manually using the left and right brackets

: test ;code [ 20 c, fc58 , 00a0 , ... etc ] ;

When a colon word is being defined, it is stored in TIB, correct?

How about just scanning TIB and counting the number of spaces? Each word in TIB basically gets reduced to its 2-byte CFA. So # of spaces times 2 plus the word length basically gives a very close approximation to the space needed to create and compile that word.

Therefore the memory available only needs to be checked once at the beginning by INTERPRET or even in QUIT. In my Forth QUIT calls QUERY then INTERPRET. SCAN can be put between the two and INTERPRET will not even be called if low on memory.

This word might do it:

0 VARIABLE CNTR
: SCAN 0 CNTR ! TIB @ DO DUP C@ 0= IF LEAVE ELSE DUP C@ 20 = IF 1 CNTR +! THEN 1+ THEN UNTIL CNTR 2* MEM - 5 - 0< # ?ERROR ;

# - is a real number assigned to the "Out of Memory" message
The 5 is just an average word length but can be changed to calculate the actual length of the word

I am actually surprised by the poor results as the only difference is that PROBE only does the memory calculation of LIMIT PAD - once compared to ?MEM has to do it at every word being interpreted, but PROBE did have the overhead of probing each character for a space to be counted. I was sure the math overhead would be more time consuming.

PROBE was only meant to determine if memory was running out before words were added tot he dictionary and not when variables, arrays, strings and space were allotted. Which would mean that ALLOT should definitely have its own memory test.

But thanks for testing PROBE for me. I was going to use it when LOADing words from the Virtual disk to create programs.