6502.org

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.

The easiest way I've found when designing a Forth-83 system is to have LOAD save BLK and >IN on the return stack and restore them after.
Fleet Forth's parsing word, WORD uses 'STREAM . If BLK is not zero, 'STREAM calls BLOCK so it doesn't matter if a block load is interrupted by another block access and the original block is read into a different buffer. Every time WORD executes, BLOCK is executed. This is why Fleet Forth's BLOCK (and BUFFER ) starts out as a CODE word. If the requested block is the most recently used, BLOCK is screaming fast.

By allowing the number of buffers to be altered on the fly, it is possible to set the number of buffers to zero in Fleet Forth with:

Just don't try to use blocks with zero buffers!

Yes, blocks are not just for source code. When metacompiling, I use some blocks in the C64's REU (ram expansion unit) for virtual memory.

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.

If your source was in a text file rather than blocks, the functionality for your Forth's LOAD sounds like the Ans Forth word INCLUDE , which makes a text file the input source and interprets/compiles from the file until the end of file.

I have a word IN-NAME that shows all word in the context vocabulary that have a specific string.

will show all words with 'sp' in the name.

will show all words that begin with 'sp'.

will show all words that end with 'sp'.


I find it helps with development, especially on the C64, with the editor and assembler as part of Forth.



I like to have the Forth system available. It's useful when the "application" is an extension of Forth to control an electronics project connected to the C64, like I did back when I had a real one. Although I build my kernel with a metacompiler, which is now written in Fleet Forth, I have an idea for another project if more room is ever needed. A target compiler, an adaptation of the metacompiler for building stand alone applications that do not need the Forth system.
No headers, no unneeded words, but I need to give this idea some more thought.

No. Since I wrote Fleet Forth, I already have the source available and I include the source with the system. My implementation of SEE does exactly what I want it to. It shows me what actually got compiled, not what the original source code was. I started a thread on SEE.
Here is an example:

and the source:

Here is an example with branches:

and the source:

If you do not have an assembler included with your Forth then how do you write CODE words?

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

If entering a definition from Forth's command line then yes the source for the colon definition will be in the TIB. If loading a block, the source will be in whatever buffer is assigned to that block. The colon definition is built at HERE .
Your word SCAN looks odd. I see DO but no LOOP . I believe I see what you are doing and I cleaned up the code. I used the word 'STREAM because it returns the address of the text stream and a count of the remaining size. In Fleet Forth, WORD uses 'STREAM for parsing.

This will allow it to work for the text input buffer and loading blocks (and when evaluating strings). I also changed the name to PROBE . Fleet Forth already has a word named SCAN . It is used by WORD and (CHAR) . I also rewrote the DO LOOP to make it faster.

Rather than build a new system, I hot patched ALLOT to redefine it as:

by doing this:

and I defined the following:

and a few redefinitions

I have a disk (image) of Blazin' Forth's utilities modified to work with Fleet Forth. I copied the blocks from that disk to some of the blocks used by the REU (Commodore's Ram Expansion Unit) so the drive access speed would not be a consideration.
Here are my results:
Fleet Forth with ?MEM takes 3% longer to load blocks in REU than Fleet Forth with no 'out of memory' protection.
Fleet Forth with PROBE instead of ?MEM takes 23% longer to load blocks in REU than Fleet Forth with no 'out of memory' protection.
using PROBE before INTERPRET adds more overhead than having ?MEM in ALLOT. Almost eight times more.
PROBE is bigger.
PROBE is inaccurate but ?MEM is dead on. If alloting a large data buffer, it is possible to exhaust the free memory and PROBE will not catch the problem. For example:

?MEM only aborts if too much memory is to be alloted. The command line can still be used to INTERPRET commands to free some memory.

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.

?MEM is only used in ALLOT and words that store a string at PAD . For example, the word " ( quote ) will, if interpreting, store a string at PAD and return the address of PAD . If compiling, it will compile the word (") and an inline string.

You're welcome.