6502.org • View topic - Fleet Forth design considerations

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Forth

All times are UTC

Fleet Forth design considerations

Page 21 of 24

[ 354 posts ]

Go to page Previous 1 ... 18, 19, 20, 21, 22, 23, 24 Next

Previous topic | Next topic

Author

Message

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Tue Aug 15, 2023 11:46 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

Forth source kept in blocks (called screens) is usually formatted as 16 lines of 64 characters. I've heard of one Forth system which showed a screen as 25 lines of 40 characters. To the interpreter, a screen is just a text stream of 1024 bytes.
The Commodore 64's 40 column screen makes it tempting to go with the 25 line by 40 character option (even with the inability to edit those last 24 bytes) but source from such a system would not display properly on a system displaying a screen as 16 lines of 64 characters and vice versa.
I posted the following about five years ago.

JimBoyd wrote:

Garth suggested an editing keyhole into the source.
I should be able to modify the editor to show a 36 column window into the block so I can see and edit just part of a source block without line wrapping on the C64 screen. Since it will be easier to add comments, there won't be so much wasted space.

I kept putting it off, until now. Here is my initial attempt.
First, I should mention that Fleet Forth's EXPECT uses the Commodore 64's screen editor. This means that I can cursor up to a line of text on the screen and press the return key. The line of text will be received by EXPECT just as if it had been typed.
SCR is a variable in the EDITOR vocabulary. It is set by LIST and used by all the editor words for the current block to edit.
The words 0: through F: in the EDITOR vocabulary are the child words of XED . 0: reads the entire text input buffer and copies the first 64 bytes (after 0: and a space) to line zero of the current block.
There are some new versions of LIST in the FORTH vocabulary and L in the EDITOR vocabulary.
LIST and L display the entire screen.
<LIST and <L display the first 36 characters of each line.
LIST> and L> display the last 36 characters of each line.
Each version of L fetches the current screen (for editing) from the variable SCR and calls its respective version of LIST .

Code:

: L   SCR @ LIST ;
: <L   SCR @ <LIST ;
: L>   SCR @ LIST> ;

I added more comments to one screen for the assembler. This is what each version of LIST shows.

Code:

0 FH LIST 
SCR# 2056  1 8 
0: // SYSTEM CONSTANTS
1: 
2: $85 CONSTANT N   $8D CONSTANT XSAVE  // THESE CONSTANTS WERE
3: $8E CONSTANT UP  $FB CONSTANT IP     // SET BY DESIGN
4: $FE CONSTANT W                       //
5:       ' NOOP @ CONSTANT NEXT         // THESE CONSTANTS DEPENDED
6: ' FILL @ 3 + @ CONSTANT SETUP        // ON THE LOCATIONS OF
7:      ' 2DROP @ CONSTANT POPTWO       // VARIOUS PRIMITIVES
8:      POPTWO 2+ CONSTANT POP          // IN THE SYSTEM
9:       ' 1 @ 2+ CONSTANT APUSH        //
A:       APUSH 2+ CONSTANT AYPUSH       //
B:      AYPUSH 2+ CONSTANT AYPUT        //
C: 
D: 
E: 
F: 
 OK
<L 
SCR# 2056  1 8 
0[ // SYSTEM CONSTANTS
1[ 
2[ $85 CONSTANT N   $8D CONSTANT XSAVE
3[ $8E CONSTANT UP  $FB CONSTANT IP
4[ $FE CONSTANT W
5[       ' NOOP @ CONSTANT NEXT
6[ ' FILL @ 3 + @ CONSTANT SETUP
7[      ' 2DROP @ CONSTANT POPTWO
8[      POPTWO 2+ CONSTANT POP
9[       ' 1 @ 2+ CONSTANT APUSH
A[       APUSH 2+ CONSTANT AYPUSH
B[      AYPUSH 2+ CONSTANT AYPUT
C[ 
D[ 
E[ 
F[ 
 OK
L> 
SCR# 2056  1 8 
0] 
1] 
2] T XSAVE  // THESE CONSTANTS WERE
3] T IP     // SET BY DESIGN
4]          //
5]          // THESE CONSTANTS DEPENDED
6] P        // ON THE LOCATIONS OF
7] WO       // VARIOUS PRIMITIVES
8]          // IN THE SYSTEM
9] H        //
A] SH       //
B] T        //
C] 
D] 
E] 
F] 
 OK

This is what it looks like on the Commodore 64.

Attachment:

original LIST.png [ 23.09 KiB | Viewed 14938 times ]

Attachment:

begin LIST.png [ 22.75 KiB | Viewed 14938 times ]

Attachment:

end LIST.png [ 20.29 KiB | Viewed 14938 times ]

Notice each version of LIST appends a different character to the line number. This is to support the new screen editing words.
The words 0[ through F[ only alter the first 36 characters of a line and the words 0] through F] only alter the last 36 characters of a line.
The original version of LIST which shows everything on each line is acceptable and the version which shows the first 36 characters of each line is acceptable. The version which shows the last 36 characters on a line doesn't show enough of the beginning of each line. It's almost like editing the end of the line blind. The block could initially be displayed with the original LIST and the source typed in using the screen editing words 0: through F: . The other versions of LIST and the screen editing words 0[ through F[ and 0] through F] could be used to edit the existing source.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Sun Aug 20, 2023 8:50 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

I'm not satisfied with the editor extension I mentioned in my last post.
My current screen editor, one I've used for years, uses a modified LIST which displays all the line numbers as hexadecimal numbers, regardless of base, with a colon appended to the number. These are editor words which parse the rest of the line where they occur and copy that text to the corresponding line of the current screen, the block number stored in SCR .

Code:

SCR# 2056  1 8 
0: // SYSTEM CONSTANTS
1: 
2: $85 CONSTANT N   $8D CONSTANT XSAVE
3: $8E CONSTANT UP  $FB CONSTANT IP
4: $FE CONSTANT W
5:       ' NOOP @ CONSTANT NEXT
6: ' FILL @ 3 + @ CONSTANT SETUP
7:      ' 2DROP @ CONSTANT POPTWO
8:      POPTWO 2+ CONSTANT POP
9:       ' 1 @ 2+ CONSTANT APUSH
A:       APUSH 2+ CONSTANT AYPUSH
B:      AYPUSH 2+ CONSTANT AYPUT
C: 
D: 
E: 
F: 

Fleet Forth's EXPECT uses the Commodore 64's screen editor. I can scroll up to a line, alter that line or not and press the return key. That line will be what EXPECT returns.
A very plain and simple screen editor. It does have it's limitations. This is what it looks like if a line (including line number, colon and space) is longer than (or even equal to) 40 characters.

Code:

SCR# 2083  1 35 
0: // S  DISPLAYS ALL OCCURRENCES OF TEX
T FROM SCR TO BLK#-1
1: : S  ( BLK# -- )
2:    >FBUF  SCR @ OVER U< IF
3:       SCR @ TUCK
4:       DO
5:          I SCR ! R# OFF
6:          BEGIN
7:             SEEK
8:          WHILE
9:             POINT SCR @ U.
A:          REPEAT
B:       LOOP
C:    THEN
D:    SCR ! ;
E: 
F: 

Sure, the editor words will still work because the Commodore 64 links the two physical lines for the comment line into one logical line. If there are too many long lines the top of the listing will scroll off the screen.
LIST includes ?DONE so the listing can be stopped before all the lines are displayed. This makes it possible to edit the top lines if there are many long lines.
There is another problem with long lines. If the long lines are in a definition, they make the source more difficult to follow. That line wrapping makes it harder to notice the source indentation at a glance.

As I said, my current screen editor is the one I've been using for years. I remember one forum member mentioning although my source is in blocks, it has a very vertical format with a great deal of white space to the right. The Commodore 64's 40 column screen is the reason.

In spite of my dissatisfaction with my latest editor extension mentioned in the previous post, I like the idea of a secondary set of screen editor words which use an edit window into the text; however, I would like an edit window which can scroll. I'd also like to keep the editor extension simple. I do not at this time want to duplicate the functionality of 64Forth's screen editor.

I did find a solution which seems satisfying. Only time and use will tell. A modification to EXPECT enhances it further.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Sun Aug 20, 2023 10:03 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

I may have given Fleet Forth's EXPECT nonstandard behavior.
The Forth-83 Standard states the following concerning EXPECT .

Code:

          9.5.2     EXPECT

          Control characters may be processed to allow system dependent
          editing of the characters prior to receipt.  Therefore, a
          Standard Program may not anticipated that control characters can
          be received.

It doesn't seem to say anything about intercepting function keys; however, I thought such a capability would be useful. In Fleet Forth, EXPECT is a DEFERred word. It is normally set to (EXPECT) .
The high level portion of (EXPECT) reads the keyboard and echoes the characters back to the screen. If a carriage return is detected in the keyboard buffer, it is not read. Control flow passes to the low level portion of (EXPECT) which uses the Commodore 64's screen editor, kernal routine CHRIN , $FFCF.
The word which echoes keys to the screen is DEMIT . It is a primitive which uses the same C64 kernal routines as (EMIT) . As the leading 'D' in the name implies, it is normally used to send a character to a disk drive, but can also send a character to the screen. The difference with (EMIT) , the vector for EMIT , is DEMIT does not update the variables CHARS and LINES . These variables are used for 'print formatting'. They keep track of the number of characters emitted since the last carriage return or page and the number of lines since the last page.
DEMIT was replaced with the following:

Code:

         7 OVER #133 - U<   \ is this not a function key?
         IF                 \ if it is not
            DEMIT           \ echo to the screen as usual
         ELSE               \ else
            #63 +  4 /MOD SWAP 2* +   \ convert PETSCII code
            " F0" TUCK 2+ C!          \ insert digit character into string
            CONTEXT @ (FIND)          \ and search CONTEXT vocabulary
            IF  DUP EXECUTE  THEN     \ if found, execute
            DROP                        
         THEN

The search of the CONTEXT vocabulary will include the parent vocabularies.

The Commodore 64's function keys are a little different. There are only four actual function keys: F1, F3, F5 and F7. F2 is obtained with shift-F1, F4 with shift-F3 and so on.
The PETSCII codes are as follows:

Code:

in function key order:

Code:

This line:

Code:

#63 + 4 /MOD SWAP 2* + \ convert PETSCII code

performs the following conversion:

Code:

=> 49
=> 50
=> 51
=> 52
=> 53
=> 54
=> 55
=> 56

An eight byte look-up table could have been used, but this was smaller.

If function key F1 is pressed and there is no word by that name, it's the same as if the function key was not pressed. If the name exists, it is executed.

I've notice the function key names could be confused with hexadecimal numbers. I've gotten too used to using $F1 for a hexadecimal number. I could change this line:

Code:

" F0" TUCK 2+ C! \ insert digit character into string

to this:

Code:

" FKEY0" TUCK 5 + C! \ insert digit character into string

Or something similar.

Code:

" FKEY0" [ HERE 1- ] SWAP LITERAL C! \ insert digit character into string

or even

Code:

   [ HERE 2+ ] $FFFF    \ compile a literal
   C!
   " FKEY0"  [ HERE 1- SWAP! ]  \ patch literal with address of 
                                \ last character in string.

To use function key F1 with this change there would need to be a word with the name FKEY1 .

Top

GARTHWILSON

Post subject: Re: Fleet Forth design considerations

Posted: Mon Aug 21, 2023 12:49 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8534
Location: Southern California

I've only used code page 437, which clearly the C64 doesn't use. I haven't thought about how I'd use the C64 character set (including function keys), but CP437 is sure nice for the special characters, drawing boxes, and the Greek letters we use all the time in engineering (since that's what I'm always using Forth for). The Epson dot-matrix impact printers, which Epson is still making about nine models of, use the same character set, so I use it with the workbench computer too, although they don't display correctly in its small LCD unless I make custom characters in the LCD, which I've done before but is kind of a lot of overhead. My exception to the 437-only use is my HP-71B hand-held computer which defaults to the ROMAN8 set which is kind of similar but has different byte values for the special characters; but after the HP Thinkjet printer I was using with it went down and I started using the Epson printer, I loaded the CP437 character set into the HP71 computer so things would display correctly in its LCD. Here are a couple of examples of my uses of the box-drawing characters:

Attachment:

MultiEdit2.jpg [ 72.02 KiB | Viewed 14836 times ]

Attachment:

MultiEdit3a.gif [ 74.57 KiB | Viewed 14836 times ]

(although that last one was for a PIC16 project, not 6502). CP437 also lets me have Forth word names like ±½°C or 10KΩ or put Φ2 in the comments.

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

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Thu Aug 24, 2023 7:08 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

GARTHWILSON wrote:

I remember code page 437. I haven't seen it since my days of using DOS.
The visual appearance of text windows can be created on the C64 using reverse video. Ctrl-R on the C64 selects reverse video and Ctrl-0 ( control zero) selects normal video.
Here is were I selected a black background and white text and played around on the screen by selecting and deselecting reverse video. I typed the text with spaces to achieve the look of windows.

Attachment:

c64 text windows.png [ 16.65 KiB | Viewed 25799 times ]

I normally use reverse video on the C64 to highlight important information.

Attachment:

metacompiler status.png [ 19.33 KiB | Viewed 25799 times ]

Fleet Forth has the words RON to switch reverse video on and ROFF to switch to normal video. A carriage return also switches reverse video off.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Thu Aug 24, 2023 9:48 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

I've removed the words <LIST <L LIST> L> and their editor words 0[ through F[ and 0] through F] because they were unsatisfactory.
I also mentioned a solution which seems satisfactory.
A new LIST word which use an editing window VALUE for a displacement to the right, EW , and a corresponding set of editing words 0[ through F[ which also use EW.

I would like to mention that the word // is Fleet Forth's word to comment to the end of a line. It will also skip the rest of the line when used at the command line or in an EVALUATEed string.
The comments in the listing which have a backslash were added to this post for clarity.

Code:

0 VALUE EW
: LISTW  ( SCR -- )
   EW #28 UMIN (IS) EW              \ be certain EW is from 0 - 28
                                    \ inclusive.
   PAGE  EDITOR  R# OFF DUP SCR !   \ clear the screen, select EDITOR 
                                    \ vocabulary & misc. housekeeping.
   ." SCR# " DUP U. SPACE BLK> . .  \ show screen number.
                                    \ BLK> breaks that number down
                                    \ to a screen number relative to 
                                    \ the drive it is from and the
                                    \ drive number.
   10 SPACES EW .                   \ show displacement to the right
   #16 0  CR
   DO
      I 0 H.R ." [ "
      I LINE  EW /STRING #36 UMIN   \ only show 36 columns
      QTYPE CR                      \ type in 'quote mode'
      DONE? ?LEAVE
   LOOP ;

EDITOR DEFINITIONS
: XED2  ( N -- )
   CREATE  ( N -- )
      C,
   DOES>   ( -- )
      C@ LINE  0 TEXT PAD 1+  -ROT
      EW #28 UMIN /STRING  #36 UMIN
      MOVE UPDATE
      3 RC !  QUIT -;
: LW  ( -- )
   SCR @ LISTW ;


 0 XED2 0[    1 XED2 1[    2 XED2 2[
 3 XED2 3[    4 XED2 4[    5 XED2 5[
 6 XED2 6[    7 XED2 7[    8 XED2 8[
 9 XED2 9[   $A XED2 A[   $B XED2 B[
$C XED2 C[   $D XED2 D[   $E XED2 E[
$F XED2 F[
FORTH DEFINITIONS

LINE takes an number from 0 to 15 and returns the address, in the block buffer, of that line for the current screen, the one which has its block number stored in SCR .
0 TEXT reads the rest of the line in the text input buffer and stores it at PAD . After -ROT the stack has the following three parameters on top.
The address of the text to copy.
The address of the line of the current screen for this child word.
A count of 64.
The line

Code:

EW #28 UMIN /STRING #36 UMIN

increments the destination address by EW bytes and clips the length of the transfer to 36 bytes, the length of the edit window.
The string is MOVEd to the block buffer and the buffer updated.
Fleet Forth's EXPECT starts at the beginning of a line on the view screen and will perform a carriage return if necessary. Setting the variable RC to 3 will cause EXPECT to move the cursor right by three.

Attachment:

cursor.png [ 25.12 KiB | Viewed 25789 times ]

That reversed video colon after 2[ is a snapshot of the blinking cursor. It was placed there after pressing the return key anywhere on the previous line.

Fleet Forth's EXPECT was modified to test for function keys. The function key words can be executed without the need to scroll down from the text being edited.

Some sample function key words I was trying. This is how the screen appears when listing with LISTW and EW is zero. The listings are sent to a printer, or in my case, a print.dump file.

Code:

\       ----------------------- actual screen number 
\      |    ------------------- drive number
\      |   |   ---------------- screen number relative to drive
\      v   v   v
SCR# 4719  2 623           0 -- editor window displacement
0[ // EDITOR FKEYS                     
1[ EDITOR DEFINITIONS                  
2[ : F1KEY  ( -- )               // MOV
3[    0 TO EW   [ HERE >A ]            
4[    XY 1 MAX 16 MIN LW AT-XY ;       
5[ : F3KEY  ( -- )               // MOV
6[    EW 7 - 0 MAX TO EW               
7[    BRANCH [ A@ , ] -;               
8[ : F5KEY  ( -- )               // MOV
9[    EW 7 + #28 MIN TO EW             
A[    BRANCH [ A@ , ] -;               
B[ : F7KEY  ( -- )  #28 TO EW    // MOV
C[    BRANCH [ A> , ] -;               
D[ : F2KEY  ( -- )               // MOV
E[    0 18 AT-XY ;                     
F[ FORTH DEFINITIONS                   

And when EW is 14.

Code:

SCR# 4719  2 623           14 
0[ S                                   
1[ IONS                                
2[ )               // MOVE EDIT WINDOW 
3[  HERE >A ]                          
4[  MIN LW AT-XY ;                     
5[ )               // MOVE WINDOW LEFT 
6[ X TO EW                             
7[  , ] -;                             
8[ )               // MOVE WINDOW RIGHT
9[ MIN TO EW                           
A[  , ] -;                             
B[ )  #28 TO EW    // MOVE EDIT WINDOW 
C[  , ] -;                             
D[ )               // MOVE CURSOR TO BE
E[ ;                                   
F[ ONS                                 

When listing with LIST .

Code:

SCR# 4719  2 623 
0: // EDITOR FKEYS
1: EDITOR DEFINITIONS
2: : F1KEY  ( -- )               // MOVE EDIT WINDOW TO BEGINNING
3:    0 TO EW   [ HERE >A ]
4:    XY 1 MAX 16 MIN LW AT-XY ;
5: : F3KEY  ( -- )               // MOVE WINDOW LEFT 7 COLUMNS
6:    EW 7 - 0 MAX TO EW
7:    BRANCH [ A@ , ] -;
8: : F5KEY  ( -- )               // MOVE WINDOW RIGHT 7 COLUMNS
9:    EW 7 + #28 MIN TO EW
A:    BRANCH [ A@ , ] -;
B: : F7KEY  ( -- )  #28 TO EW    // MOVE EDIT WINDOW TO END
C:    BRANCH [ A> , ] -;
D: : F2KEY  ( -- )               // MOVE CURSOR TO BELOW EDIT AREA
E:    0 18 AT-XY ;
F: FORTH DEFINITIONS

And with what I normally use to list screens to a print.dump file, PLIST , plain list.

Code:

SCR# 623 
// EDITOR FKEYS
EDITOR DEFINITIONS
: F1KEY  ( -- )               // MOVE EDIT WINDOW TO BEGINNING
   0 TO EW   [ HERE >A ]
   XY 1 MAX 16 MIN LW AT-XY ;
: F3KEY  ( -- )               // MOVE WINDOW LEFT 7 COLUMNS
   EW 7 - 0 MAX TO EW
   BRANCH [ A@ , ] -;
: F5KEY  ( -- )               // MOVE WINDOW RIGHT 7 COLUMNS
   EW 7 + #28 MIN TO EW
   BRANCH [ A@ , ] -;
: F7KEY  ( -- )  #28 TO EW    // MOVE EDIT WINDOW TO END
   BRANCH [ A> , ] -;
: F2KEY  ( -- )               // MOVE CURSOR TO BELOW EDIT AREA
   0 18 AT-XY ;
FORTH DEFINITIONS

Although with the last two, there will be a line wrap on the Commodore 64's video screen.

F1KEY moves the editing window all the way to the left by setting EW to zero. XY returns the X (from left to right) and Y (from top to bottom) coordinates of the text cursor. AT-XY sets the coordinates, which places the cursor at those coordinates.
Suppose I wish to add a comment for the definition of F1KEY . While in the editor vocabulary, I press the F1 key and scroll up to the line with the name F1KEY . I press the F7 key and the listing is updated to show the last 36 columns of the screen, but the cursor is on the same line as it was before pressing the F7 key. I can now add a comment knowing it is on the correct line.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Tue Sep 12, 2023 5:26 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

In the Fleet Forth kernel there are eighteen headerless words. Words like the one formerly named TRAVERSE or some of the words used by the sector read/write word, SR/W . These headerless words have no use outside the kernel, which is why they are headerless. There is another group of words which are not directly used outside the kernel, the run-time words of other words.
Here are some of the compiling words and associated run-time words

Code:

DO     (DO)
?DO    (?DO)
LOOP   (LOOP)
+LOOP  (+LOOP)
"      (")
."     (.")
ABORT" (ABORT")
IS     (IS)
TO     (IS)

I may change the names of some of these run-time words but these words will not be made headerless. The few dozen bytes saved would not justify the increased complexity in the design of the decompiler, SEE .

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Tue Sep 26, 2023 6:38 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

I've mentioned Fleet Forth's TRACE and the ability to change what information is displayed by setting the DEFERred word .STEP to a step display word more appropriate for the trace.

Here is yet another example of how TRACE's step display can be customized. I recently made a modification to Fleet Forth's metacompiler. One of the words copies a string to HERE and modifies it, if necessary. The reason PAD isn't used is because Fleet Forth has the word >HERE in the kernel.
I wanted to see what was happening at HERE when tracing that word.

Code:

: .STMETA 
   (.ST1) CR HERE $10 DUMP ;
' .STMETA IS .STEP

(.ST1) is the default step display word. .STMETA calls (.ST1) for the usual display for the current step and then dumps the first sixteen bytes at HERE .

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Sun Oct 01, 2023 8:18 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

JimBoyd wrote:

I may have given Fleet Forth's EXPECT nonstandard behavior.
The Forth-83 Standard states the following concerning EXPECT .

Code:

          9.5.2     EXPECT

          Control characters may be processed to allow system dependent
          editing of the characters prior to receipt.  Therefore, a
          Standard Program may not anticipated that control characters can
          be received.

It doesn't seem to say anything about intercepting function keys; however, I thought such a capability would be useful.

I have found nothing in the Forth-83 Standard for or against this extra functionality in EXPECT .
The closest I've seen is this excerpt for the Forth 2012 Standard's ACCEPT .

forth-standard.org wrote:

It is recommended that all non-graphic characters be reserved for editing or control functions and not be stored in the input string.

Fleet Forth is a Forth-83 Standard Forth for the most part; however, when there is something not covered in the Forth-83 Standard I will check the other standards for the least objectionable approach to minimizing divergent behavior in my Forth when adding new functionality to the kernel. One such example is renaming Fleet Forth's UNDO to UNLOOP .
ACCEPT is the Forth 2012 Standard version of EXPECT with slightly different behavior. As such, where the Forth-83 Standard is quiet concerning the use of function keys in EXPECT , I'll accept the Forth 2012 Standard's recommendations for ACCEPT . The relevant phrase describing ACCEPT is "or control functions" which would indicate that it is acceptable for ACCEPT , and therefore EXPECT , to intercept function keys and use them for control purposes.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Tue Oct 24, 2023 9:25 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

FSAVE is Fleet Forth's word to save the Forth system as a Commodore program file. FSAVE would prompt for a file name and use EXPECT to read in the file name to use; however, I have found that I would occasionally type a file name right after FSAVE when I already had a file name in mind and I was in a hurry. This made me wonder if having the file name inline was a more natural way to do things. The file name used by FSAVE now follows it in the text stream. FSAVE uses 0 WORD so file names with spaces can be used.

Top

BruceRMcF

Post subject: Re: Fleet Forth design considerations

Posted: Wed Oct 25, 2023 3:29 pm

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217

JimBoyd wrote:

I may have given Fleet Forth's EXPECT nonstandard behavior.
The Forth-83 Standard states the following concerning EXPECT .

Code:

          9.5.2     EXPECT

          Control characters may be processed to allow system dependent
          editing of the characters prior to receipt.  Therefore, a
          Standard Program may not anticipated that control characters can
          be received.

It doesn't seem to say anything about intercepting function keys; however, I thought such a capability would be useful.

I have found nothing in the Forth-83 Standard for or against this extra functionality in EXPECT .
The closest I've seen is this excerpt for the Forth 2012 Standard's ACCEPT .

forth-standard.org wrote:

It is recommended that all non-graphic characters be reserved for editing or control functions and not be stored in the input string.

Forth-94 slightly generalized the Forth-83 EXPECT specification by specifying that author of Forth-94 source could not depend on being able to receive non-graphical characters, which is more explicit about setting aside what is returned by a function key unless it returns one or more graphical characters.

However, function keys themselves do not come into scope until Forth-2012, which is also when "a source cannot depend on non-graphical characters being stored" was strengthened to "it is recommended that a system refrain from storing non-graphical characters".

Quote:

I'd say it is good for sanity if EXPECT is implemented in a way that allows a set of Forth-94 / Forth-2012 portability screens to define ACCEPT as "EXPECT SPAN @".

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Tue Nov 07, 2023 11:42 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

One feature of VICE I have used in moderation is the ability to paste text into the simulator. Fleet Forth behaves as though the text is typed in. This does introduce a problem. When loading source from screens on blocks or even from a Commodore sequential file, an ABORT stops the load and returns control to Forth's QUIT loop. When text is pasted into the simulator the QUIT loop still has control. an ABORT stops interpreting text which has already been EXPECTed, or ACCEPTed; however, the simulator continues to fill the keyboard buffer until all pasted text has been inserted into the keyboard buffer. The behavior is exactly as if a programmer typing in source ignores errors and continues typing.
Fleet Forth's ABORT , which is called by ABORT" , is extensible.

Code:

: ABORT  ( -- )
   SINGLE ERR SP! AP! QUIT -;

SINGLE switches off multitasking.
SP! and AP! clear the data and auxiliary stacks.
ERR is a deferred word which normally executes NOOP a Forth no-op.
I set ERR to the word PURGE when I wish to paste Forth source from a Linux text file.

Code:

: PURGE           // EMPTY KEYBOARD
   BEGIN          // BUFFER
      BEGIN
         KEY?     // ANY KEYSTROKES?
      WHILE
         KEY DROP
      REPEAT
      1 JIFFIES   // WAIT 1/60 SEC
      KEY? 0=     // BUFFER EMPTY?
   UNTIL ;

KEY? is an AnsiForth word which returns TRUE if a character is available.
The 1 jiffy delay is to give VICE time to refill the keyboard buffer. The inner loop empties the keyboard buffer fast enough that without the delay, PURGE returns before VICE is finished adding pasted text to the buffer.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Sun Nov 12, 2023 8:01 pm

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

I should have mentioned that keyboard input in Fleet Forth causes the cursor to blink while waiting for input. When PURGE is used to purge the pasted text after an error occurs, I know it is done when the cursor resumes blinking at a steady rate.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Thu Nov 23, 2023 4:55 am

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

JimBoyd wrote:

Some of the run-time words now have the same name as the associated compiling word.

Code:

DO     DO
?DO    ?DO
LOOP   LOOP
+LOOP  +LOOP
"      "
."     ."
ABORT" ABORT"

(IS) is still the run-time for IS and TO .
The run-time words are defined before the word FORTH-83 and the compiling words are defined after. This made updating the source for SEE easier.
To find the run-time words, the FORTH vocabulary is set as both the CONTEXT and CURRENT vocabularies. Create a false vocabulary on the auxiliary stack with FORTH-83 as the latest word with the following:

Code:

0 ' FORTH-83 >LINK 2>A

and make it the CONTEXT vocabulary.

Code:

AP0 @ @ CONTEXT !

The false vocabulary, the portion of the FORTH vocabulary from FORTH-83 to the beginning is searched. If the sought word is not found in this false CONTEXT vocabulary, the CURRENT vocabulary, which is all of the FORTH vocabulary, is searched.

Code:

 OK
SEE DO 
DO IMMEDIATE
 2DA2 20A6 COMPILE
 2DA4  912 DO
 2DA6 2CAE >MARK
 2DA8 12E6 2+
 2DAA 2CC2 <MARK
 2DAC 12E6 2+
 2DAE  9A8 EXIT
E 
 OK
0 ' FORTH-83 >LINK 2>A AP0 @ @ CONTEXT !  OK
SEE DO 
DO
  914         INY
  915   FB )Y LDA IP
  917         PHA
  918         DEY
  919   FB )Y LDA IP
  91B         PHA
  91C         CLC
  91D    3 ,X LDA
  91F   80  # ADC
  921         PHA
  922    3 ,X STA
  924    2 ,X LDA
  926         PHA
  927         SEC
  928    0 ,X LDA
  92A    2 ,X SBC
  92C         TAY
  92D    1 ,X LDA
  92F    3 ,X SBC
  931         PHA
  932         TYA
  933         PHA
  934         INX
  935         INX
  936         INX
  937         INX
  938  8ED ^^ BPL ' ?BRANCH >BODY 8 +
  93A  839    JMP ' ! >BODY 14 +
29 
 OK
CONSOLE 

[Edit: Corrected explanation of the vocabulary search.]

Last edited by JimBoyd on Wed Dec 20, 2023 11:55 pm, edited 1 time in total.

Top

JimBoyd

Post subject: Re: Fleet Forth design considerations

Posted: Fri Nov 24, 2023 12:30 am

Joined: Fri May 05, 2017 9:27 pm
Posts: 894

JimBoyd wrote:

Leo Brodie introduced the word \S in his book Thinking Forth. \S stops the rest of a screen from loading.

The Forth-83 Standard has the uncontrolled reference word ;S which does the same thing.

Code:

          ;S           --                            Interpret only"semi-s"
               Stop interpretation of a block.

Top

Page 21 of 24

[ 354 posts ]

Go to page Previous 1 ... 18, 19, 20, 21, 22, 23, 24 Next

Board index » 6502.org Users Forum » Forth

All times are UTC

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum