Finally got some word definitions created that helps edit screens and frankly now prefer editing screens over text files.

At first I thought screens would be just good for creating word definitions, but now am beginning to realize that it is quite easy to store data from everything from lists of words to binary data to spreadsheet data to text documents with Control characters, in each screen.

This gives much more flexibility than just plain text as one cannot store Control characters or memory pointers in a text file. Storing a zero as the first byte of the screen also prevents the screen from being accidentally loaded, but does not affect the screen being displayed, and the LIST command is modified to display Control characters in inverse video.

And if needed, a screen or series of screens, can easily be saved to a text file or binary file.

Forth is truly a blast and way more productive than Pascal or Basic.

_________________
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 thought of that too. Using a full screen of 80 cols by 24 lines. But 80 x 24 is only 1920 characters and the next step up for an even number of blocks is 2048 bytes. There would be some memory wastage then, so decided to stick with the 1024 byte screen.

But one would think it would be quite easy to implement a larger screen size just by changing a few constants.

In my Forth just 3 constants would need to be changed

C/L (characters per line)
B/BLK (bytes per block)
B/SCRN (blocks per screen)

B/BUF (bytes per buffer) should get calculated as: B/BLK x B/SCRN

I don't have a "# of lines" constant. But since I am currently updating my source anyways, I might just add this constant.

Or could just make #LINES a calculated variable.

#LINES = B/BLK x B/SCRN / C/L

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

At one time I had a Videx Ultraterm which offered 128x32 or 160x24, but no-one has implemented support for those screen sizes in any emulators yet. But yeah, I am envious of all that screen real-estate you have access to.

I haven't used screens since I first used Forth with my 6511AQ chips teamed up to a 3" floppy for development back in the 80's. However, I recently decided I needed config files in my Forth but I wanted an easy way to edit them on the target board via an ANSI terminal or via VGA. So I decided to write a simple screen editor that I called SED which just handled one sector at a time which in SD cards is 512 bytes. That worked well and I thought I can also edit raw sectors as well as memory and Flash etc. But then I thought I could also edit source code too if I made it larger than a sector, although 1k seemed a bit small, I settled with 2k display of 64 wide by 32 lines with an option for 4k buffers to handle the 4k page erase sizes of SPI Flash. When I edit memory or sectors it displays the hex bytes instead of characters.

This works really well over serial terminals or via VGA display on my embedded systems and I can toggle screen sizes for wider displays although there is no real need. Some mentioned having room for comments on the right but in recent years I have made a shift to having comments mostly on their own rows just above the code, since Forth source can have a line full of swaps and drops and other code, and it is handy to track this sometimes with positional comments.

So here are a few lines from a config file that I have added a few lines of source code to with comments just to illustrate that this is so much better for Forth vs the messy comment columns that only seem to line up for assembly code. The .< at the end of each indicates a CR is added, just to make it more text file like and easy to process as normal input. I use --- as a comment alias simply because it clearly separates code and comments and doesn't look like other non-comment symbols.

BTW - when it comes to "w i d e screens", I can set my target board's VGA mode to 1920x1080 and a 5x7 font can fit 320 characters on each line! But that is too wide.

I had experimented with storing arrays in BLOCKS and it worked reasonably well. I ended up with the following code (stored in blocks 1-2 with the data starting at block 3) to make it go. Pardon the excessive (what is the stack doing) comments on the first word as I was still learning Forth when I wrote this.

Code:

( Block Binary Data Words  1/2                 SCC 2018-12 )
( Make a defining word to create block arrays. )
: BLOCK-ARRAY: ( base_block# "name" -- ) ( index -- addr )
  CREATE ,     ( save the base block# )
  DOES> @ SWAP ( base_block# index )
    CELLS      ( Turn index into byte index )
    1024 /MOD  ( base_block# offset_into_block block# )
    ROT +      ( offset_into_block real_block# )
    BLOCK      ( offset_into_block buffer_address )
    + ;
( Create the array starting at block 3           )
( With 4 blocks, max index is 2047 - not checked )
3 BLOCK-ARRAY: MYARRAY
( Some helper words for accessing elements )
: MYARRAY@ ( index -- n ) MYARRAY @ ;
: MYARRAY! ( n index -- ) MYARRAY ! UPDATE ;  ok

( Block Binary Data Words cont. 2/2            SCC 2018-12 )
( Note: For both words below, end-index is one past the )
( last index you want to use.                           )

( A helper word to initialize values in block arrays to 0 )
: ARRAY-ZERO ( end_index start_index -- )
    ?DO 0 I MYARRAY! LOOP ;

( A helper word to view a block array )
: ARRAY-VIEW ( end_index start_index -- )
    ( Print 10 values per line with 6 digit columns. )
    ?DO I 10 MOD 0= IF CR THEN I MYARRAY @ 6 .R LOOP ;

The only note I would add about doing this is to make sure you FLUSH or SAVE-BUFFERS before powering down your computer, but that's true any time when using blocks.

I believe that's FIG-FORTH type behavior with the null character being the magical word "X" that stops interpreting a block or line of text. That was handy for FIG where the buffers were often smaller than a block, so the end of a buffer did not mean the end of a block, and refill would just get the next buffer and continue interpreting. FIG also would put a null at the end of the input buffer as it read in lines, so it worked well there too.

The newer-ish forths (I think starting with '94) do input differently and process things with "address count" type strings/buffers that I believe can have null and other characters in there. DPANS94 states that control characters shall be treated as a space (verified on Tali2 which lets me type null characters inside strings, but I can't use it as part of a word name because it is treated like a space). A zero at the beginning of a block/screen would then just be treated like a space and the rest of the block would continue to be evaluated if LOADed.

The zero at the beginning of a screen seems like a nice trick for FIG based forths, though.

If that is the case, then that is one behavior I like above other Forths.

Also, if Control Characters are getting automatically converted to an Ascii displayable character, that takes away from the ability to use pointers and Control Characters in screen blocks.

I don't see the purpose of new Forths making Control Characters into printable ascii characters. Does that mean there will need to be different word definitions for different devices?

For example, displaying text to a display screen will display the Control Characters as an ascii character, but printing the text to a printer will print the Control Character as is.

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

If using the first "pseudo-line" of a block as an index, with supporting tools:

\ This block contains definitions supporting BMW style --[ comments

... would be a way to make sure the index line is not interpreted.

The "Comus" equivalent to \ for "end processing source in file" would be \\ ... and then if you have a version that ends processing of a block, an index line starting with \\ would be a block that is never interpreted.

\\ This block contains binary tables used for fast multiply.

Of course, the block is not printable if it is raw binary, and so if it is assumed that the index line listing word(s) require printable characters, that means that only 960 bytes is available for raw binary storage in a 1K block.

If the C64 equivalent for \ is // then an equivalent for \\ may be ///

If it is desired for the block to be printable or transmittable as text, 7 base-32 digits is a maximum of 35 bits, so can hold 32bits of data, so with a trailing space would be 2 printable characters per 1 byte of data ... so a binary block of all bits set (2^32-1) would be:

3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV
3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV 3VVVVVV
...

Note that allocating 32 bits with 35 available means the the most significant digit is 0-3.

As a raw block, that would be 512 binary bytes of data per printable block ... with index line, 480 binary bytes per printable block.

An advantage of the format for a 16bit Forth is that the leading digit is 0-3, and three base-32 digits is at most 32,767 (VVV), so it can be processed with the leading digit, the next trio, and the last trio. So suppose you have LEAD@+ ( addr1 -- addr2 n ) TRIO@+ ( addr1 -- addr2 n ), TOPBITS gets the bottom two bits of a cell into the top two bits, TOPBIT gets the bottom bit into the top bit, and PUT-DOUBLE ( n1 n2 -- ) puts a double into a target buffer, incrementing the buffer index by four.

HEX
LEAD@+ TOPBITS >R
TRIO@+ DUP 2/ >R TOPBIT >R
TRIO@+ R> OR
R> R> OR
PUT-DOUBLE
CHAR+
... and you are ready for the next chunk of data.