_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

My UNUSED is also used in , (comma). My ALLOT uses it too, but in looking at it again now, I think I could simplify it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

, uses 2 DP +! instead of ALLOT. Yeah, 2 ALLOT would be more efficient.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for delving into BLOCK and BUFFER for Fleet Forth.

I was in the process of deciphering what they do and how they work in ProForth. ProForth is a Forth for the Prodos OS on an Apple II. ProForth also has 2 buffers laid out as blocks. A ProForth block is 1024 bytes which happens to also be 16 lines of 64 bytes. The same as Fleet Forth's line limit.

Because of the great similarities between ProForth and FleetForth, I have taken a great interest in a lot of your improvements for FleetForth, and hope to adapt many of them to ProForth.

Just a couple of quick questions.

How does FleetForth set a device # to know which device to read from or write to before using BUFFER and BLOCK?

Under ProDOS, the BLOCK parameter list contains a device #. So far this has been hard coded into ProForth. I would like to change that so I can load any text file from any slot/drive combination. Just seeing what else is out there for word primitives that may already exist. DR0 and DR1 were only meant to signify drives and were originally programmed for floppies. Under ProForth, they are not used at all but are still included in word definitions. What does the C64 have in the way of device types. I believe there was an add-on SD card for the C64 port? That would mean you would need a word under FleetForth to identify which Port to save to other than the floppy drive, would you not?

Is FleetForth reading text files as a sequential text file (one line at a time) or as a chunk of 1024 byte screen files? Proforth is set up to load 16 screens all at the same time and the text file is a fixed 16384 ($4000) = 16 screens of 1024 bytes. Then the screens are accessed with the LIST word from 0-15 and a screen is loaded using the LOAD word.

I hate this method and want to get away from it. Would simply like to use OPEN "textfile" and LOAD to load it.

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.