I actually enjoy using screens more and more all the time.
Setting up a file structure is easier than I thought it would be.
With 16384 screens available per virtual file on a hard drive gives lots of room to be creative.

My first screen is set up as a directory and looks something like this:

SCRN #1
: MAIN 1 LIST ;
: GRAPHICS C00 LIST ;
: GAMES D00 LIST ;
: APPLICATIONS A00 LIST ;
: OSCMDS B00 LIST ;
: HELP E00 LIST ;
: QUICKREFCARDS F00 INDEX ;
: EDITOR 18 1F THRU ;


The go-to screens list the file names and the screens to load.

SCRN #C00
( GRAPHICS )
: TURTLEGR C01 C08 THRU ;
: KALEIDOSCOPE C09 C0B THRU ;
: PICTURES C10 INDEX ;

SCRN #D00
( GAMES )
: CHECKERS C01 C09 THRU ;
: CHESS C10 C30 THRU ;
: OTHELLO C40 C50 THRU ;
etc ...


SCRN #A00
( APPLICATIONS )
: ASSEMBLER A01 A0F THRU ;
: FILE2DISK A10 A1F THRU ;
: WORDPROC A20 A40 THRU ;
etc …


SCRN #B00
( OPERATING SYSTEM COMMANDS )
: TLOAD
: TTYPE
: BLOAD
: BSAVE
: BLK2TFILE
etc …


And the list goes on.

_________________
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?

I did. The biggest drawback is the screen would have to scroll left to view the rest of the line if set at 128 characters, or scroll up if more lines are allowed. There are a couple of text editors out there that do that, and I have to say, that annoys the heck out of me. I probably wouldn't use the screens method on any computer other than an 8-bit machine. Larger machines tend to have more screen real-estate and would greatly benefit from having multiple text files open instead.

And the 64 character limit is not actually a limit that has to be enforced. Each line is only viewed with the 64 character limit as a guideline to give the total of 1024 characters but is only for viewing purposes. It is the best fit for a screen that can only view 80 columns by 24 lines. All 16 lines are actually contiguous in memory, and code can overlap the end of the 64 character limit from one line to the next line and still compile properly.

The only real thing a person has to watch is if using the 64 character limit as a stopping point, that if the last character of a word is in the 64th position, then the first position of the next line must be a space. Words can be split across the end of one line and onto the next (without a space at the beginning of the next line) and still be recognized as a complete word.

Defining words in a horizontal fashion instead of a vertical one (with a comment after each word) can save a lot of space. Once a person gains more experience and really begins to understand Forth, then it becomes beneficial to remove all the clutter and focus on efficiency and compaction. A comment at the beginning of a word definition is all that is needed to understand what the word does. There are a few complex words that benefit from having a comment after each word, to help a person follow along to see what the definition does. But I believe that is why it is recommended to keep each definition as short as possible and give each word a very simple task.

I created a slightly better version of the LIST definition that shows where each line would end and the next one begins. And as you can see, some lines extend onto the next line, but for readability I try not to break any words at the end of a line.

_________________
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?

There should be no compatibility issue if \ is defined correctly using the C/L definition as it still should only skip comments up to the end of the current line since the line length is defined by C/L. I take it to mean there are no word definitions after the \ on the current line.

If comments carry over to the next line, then that line too should begin with a \. I guess that is one good reason to see where one line ends and the next one begins.

Another idea I started programming into some of my words is to, check for the RETURN char. Although I don't, as of yet, insert any RETURN characters in my screens, I am playing with the idea of viewing more lines, but still use the 1 kb screen block, to save space at the end of some word definitions, so it doesn't go to waste.

The \ definition could also do this. Check what comes first. The end of a line or a RETURN character.

I don't know if that would work, as how would the interpreter know if ;COMMENT itself is not part of the comment, since commented words are skipped over and not interpreted.

How about this instead. The same as the parenthesis works, the interpreter searches for the ending parenthesis to signal the end of a comment, one can use the backslash or dbl-forward-slash to signify the end of the comment as well. But there would be no need to use an ending back-slash as that is the same as using the parenthesis.

Some computers have the ability to use the backslash character, so a backslash can signify to ignore all text to the end of the line and a dbl-forward-slash can signify to ignore all comments until another dbl-forward-slash is encountered, even across multiple lines.

One approach used for extensive comments are shadow blocks. A shadow screen is based on a set of blocks for source and an equal number for comments, so that a single offset value allows you to "flip" between the source and the shadow block. In the day, this would often be tied to a function key, where the block display function would have the offset built in and the function key would XOR the value of the offset with the stored value, so toggle between an offset of 0 and the shadow screen offset.

A useful word in that context is \\ which is "end of source in file" when interpreting a file, and and "end of source in block" when interpreting a block. Starting the index line of a shadow block with \\ rather than \ (or in a C64th, /// rather than //) ensures that the comments are never accidentally interpreted.

When I was working on the "no function key text file editor" BMW (Bruce McFarling's Writer), I would put the \\ at the start of a decorative line:

\\ // \\ // \\ // \\ // \\ // \\ // \\ // \\ //

... where everything but the first pair of character is just decoration, since the \\ ends interpretation of the file.

I very much like the 64 character wide block versus a 128 character or (to fit a C64 display) a 40 or 32 character wide block, and adopted 63 character plus a return key as the width of my text files, for easier porting of individual sets of words to blocks if need be. As far as the "problem" of losing useful space when indenting, I would indent by three spaces, which worked for me.

However, my C64 Forth back in the day used 40 wide blocks, and for 64 wide blocks, I would want a bitmapped text display with a 5 bit wide font.

However, I could see using a 32 character wide block in a context where of using a small enough LCD display for a target board that 32x8 is substantially easier to read than anything more ... to avoid left-write scrolling. If you use the bottom line for entering commands, scroll up at the second line except when at the top of the block, and down at the sixth line except when at the bottom of the block, it is reasonably easy to have a feel for where you are in the block, and the command prompt can be X> where "X" is the base 32 of the row number.

In that context, if I was using shadow screens, I would have a load screen that loads the offset into a variable. However, IIRC, shadow screens really became popular when hard drives and their "massive" 10MB or 20MB capacity came into use ... IOW, my guess is they tended to be from a slightly later vintage than the pure floppy disk based systems. I am not sure I would try them with anything smaller than a 1581 (or SD2IEC with 1581 images), so I'd go with an offset of 400.



Yes, that is also an objective of xForth ... indeed, until I got so busy with the new job, I was planning to tackle the INCLUDE system first.

But I do now intend to have // as a synonym of \ and /// as a synonym of \\

I've have been reading some of these posts and found some of the comments interesting as I had written a screen editor a couple of years ago that used the ANSI terminal. More recently however I enhanced it greatly to allow full ANSI key operation, highlighting, and multiple file tabs etc. At present this version operates with my Tachyon extensions including the filesystem running on top of Mecrisp on the RP2040 chip. I am using this editor to develop a full suite of dev tools to run on any Forth system that has maybe about 8k of RAM or more (the RP2040 has 264kB internally). Power to the Forth!

The editor has become more of an IDE since I can compile and run code and invoke the logic analyzer module etc. I still need to finish a multipass macroassembler which will produce a clean and flat listing and output file. While this is geared for the RP2040 I see no reason why I can't backport it to some of my older 65xx systems including the M37702 etc where I had lots of RAM.

BTW, rather than raw blocks, I handle a standard FAT32 file in pages of 32 lines of 128 characters and terminate each line with a CR. This makes the file compatible with PC text editors but makes it possible to edit the file in 4k pages although the page length can be adjusted up to 64 lines. The clipboard is in RAM but I may make it hybrid with a file to allow for systems to use less RAM. ^F10 will compile code from the clipboard or if empty then from the current page rather than F10 which compiles the whole file. A null terminator(s) marks the logical end of a file.

Normally I use VScode but I am loving the ease of use of this editor with intuitive controls. Plug my board in, type ED and it restores the last multi-tab session complete with cursor position and theme etc.