fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/05/2024]

[+TheBF]

13 hours ago, Lee Stewart said:

 

OK—It took a little longer than I anticipated! All necessary files are near the top of the first post.

 

Now—On to updating the manual.

 

...lee

I don't know if you changed anything in this area, but I notice the compile times are really fast. 

That makes for a great system. 

[+Lee Stewart]

16 hours ago, TheBF said:

I don't know if you changed anything in this area, but I notice the compile times are really fast. 

That makes for a great system. 

 

I did some work on (FIND) (used in dictionary search when compiling cfas), but I don’t think it was dramatic. Here is the code:

 

Spoiler

;[*** (FIND) ***     ( addr nfa --- false | pfa b true ) 
* String at addr should be padded with at least 1 blank at the end!!
*
*
*        DATA DIGI_N
* PFIN_N .NAME_FIELD 6, '(FIND) '
*
* PFIND  DATA $+2
*        BL   @BLF2A
*        DATA _PFIND->6000+BANK2  
*
* This part must remain in bank 2 with headers to accommodate
* searching without bank-switching!
*
*     Register usage:
*        R0: work..argument to subroutines
*        R1: work..nfa running pointer
*        R2: work
*        R3: string buffer running pointer
*        R4: nfa pointer (constant per name)
*        R5: string buffer pointer (constant)
*        R6: work
*        R7: object of "X" instruction
*   W (R10): nfa count byte management
*  
_PFIND MOV  *SP,R4          ; nfa to R4
       JEQ  PFIND4          ; top of dictionary?

*++ Set up R7 for case sensitivity jump...
*++ "X    R7" = "JMP  PFIN2B" = "JMP  PFIND1"
       LI   R7,PFIN2B-PFIN2A/2-1+>1000   ;assume case sensitive search
       MOV  @CASENS,R0     ;case sensitive?
       JNE  PFIND0         ;yup.."JMP  PFIN2B"
       LI   R7,>1000       ;nope...."JMP  $" = "NOP"

*++ Copy search string to CHRBUF (>83A0)
PFIND0 MOV  @2(SP),R0      ;string source address
       LI   R1,CHRBUF      ;destination buffer address
       MOV  R1,R5          ;save buffer address
       LI   R2,32          ;unconditionally copying 32 bytes (max nf size)
PFIN0A MOVB *R0+,*R1+      ;copy next byte
       DEC  R2             ;done?
       JNE  PFIN0A         ;not yet

*++ Set CHRBUF address for PFIN0B to avoid unnecessary NOP at PFIN2A
       MOV  R5,R1          ;buffer address to R1

*++ "JMP  PFIND1" /must/ be same distance as "JMP  PFIN2B"!!!
       X    R7             ;jump to PFIND1 if case-sensitive..else NOP

*++ Make CHRBUF string uppercase if case-sensitivity is off
PFIN0B MOVB *R1+,R2        ;string length to counter
       SRL  R2,8           ;get to LSB, clearing MSB       
PFIN0C MOVB *R1,R0         ;get current char to R0 for CASEUP
       BL   @CASEUP        ;char to uppercase (code in low RAM)
       MOVB R0,*R1+        ;store possibly converted char..inc to next char
       DEC  R2             ;done?
       JNE  PFIN0C         ;not yet

PFIND1 MOV  R4,R1          ;not top of dictionary..copy nfa to R1
       MOV  R5,R3          ;str buffer addr ptr to R3
       MOVB *R1+,W         ;copy nfa count byte to W; inc R1 to 1st char
       ANDI W,>3F00        ;mask out non-count bits, except smudge bit
       CB   W,*R3+         ;compare char counts; inc R3 to 1st str char
       JNE  PFIND3         ;counts the same?
       SWPB W              ;yes..get count to LSB
PFIND2 CB   *R1+,*R3+      ;compare chars, incrementing nfa and str
       JEQ  PFIN2C         ;we have a match

*++ "JMP  PFIN2B" /must/ be same distance as "JMP  PFIND1"!!!
PFIN2A X    R7             ;jump to PFIN2B if case-sensitive..else NOP

*++ Case-insensitive comparison
       CLR  R0             ;insure LSB is >00 for CASEUP
       MOVB @-1(R1),R0     ;re-get character from name field
       BL   @CASEUP        ;convert case (code in low RAM)
       MOVB @-1(R3),R6     ;re-get character from string buffer
       CB   R0,R6          ;compare the two characters
PFIN2B JNE  PFIND3         ;if not equal then check next dict entry

*++ We have a match
PFIN2C DEC  W              ;decrememnt char count
       JNE  PFIND2         ; if not 0 then check next character
       INC  R1             ;all chars match!..insure address..
       ANDI R1,>FFFE       ;..is on a word boundary

*++ R1 now points at cfa in RAM or pfa ptr in ROM
       INCT R1             ; increment R1 to pfa in RAM or pfa ptr+2 in ROM

*++ Change to accommodate headers not in bank 2 (pfa ptr in R0)
       MOV  R1,R0          ;for GETPFA
       BL   @GETPFA        ;check for ptr in ROM
       MOV  R0,@2(SP)      ;leave pfa on stack at same position as addr
       CLR  *SP            ;clear top stack position
       MOVB *R4,@1(SP)     ;copy length byte to right byte of top of stack
       DECT SP             ;make room on stack for 3rd cell
       MOV  @CON01,*SP     ;put >0001 on stack (true)
       JMP  PFINDX         ;return to inner interpreter
PFIND3 MOV  @-2(R4),R4     ;not = or counts different; get prev word's nfa
       JNE  PFIND1         ;if not top of dictionary, try again
PFIND4 INCT SP             ;no match; top of dictionary; pop top of stack
       CLR  *SP            ;return false on top of stack
PFINDX B    @RTNEXT        ;return to inner interpreter

 

 

...lee

[Reciprocating Bill]

Lee -

 

I must have missed a turn somewhere. 

 

I successfully installed FBforth onto my FinalGrom99.  On my TIPI, I created a folder called "FBFORTH," designated it as DSK1. vis the TIPI and placed FBLOCKS in that folder.

 

Upon starting FBforth 3.0 I am greeted with "FBLOCKS?" So, apparently FBforth has found my new FBLOCKS file (and the editor can display the screens), but the first word on the first screen of FBLOCKs is "FBLOCKS," which is not a FBforth word. 

 

Secondly, no change I make to any screen of FBLOCKS persists. "FLUSH" doesn't do it, nor does navigating five or six screens to flush the buffer.  Returning to any screen on which I've made a change finds the original content, unchanged. 

 

I'll happily wear the dunce cap - what am I missing?

Edited June 6 by Reciprocating Bill

[+Lee Stewart]

1 hour ago, Reciprocating Bill said:

Upon starting FBforth 3.0 I am greeted with "FBLOCKS?" So, apparently FBforth has found my new FBLOCKS file (and the editor can display the screens), but the first word on the first screen of FBLOCKs is "FBLOCKS," which is not a FBforth word.

 

The error message, “FBLOCKS?”, means that FBLOCKS is not the current blocks file. This usually happens when MENU is executed and the 3^rd and 4^th characters in block #1 are not “fb”. The fact that you see “FBLOCKS” as the first word on block #1 implies to me that the VIB file header, which leads with the filename, is being read. This may mean that TIPI does not properly read V9T9-format files or is not configured to read them. @jedimatt42? If this is the case, try converting FBLOCKS to TIFILES format with TI99Dir.

 

1 hour ago, Reciprocating Bill said:

Secondly, no change I make to any screen of FBLOCKS persists. "FLUSH" doesn't do it, nor does navigating five or six screens to flush the buffer.  Returning to any screen on which I've made a change finds the original content, unchanged. 

 

This may be due to the first problem. Let’s see if fixing that fixes this.

 

...lee

Edited June 6 by Lee Stewart
correction

[+Lee Stewart]

For the fbForth 3.0 manual, I am debating on whether to remove the words for the stack-based string library from the glossary. They are listed in the relevant chapter and they do bloat (clutter?) the glossary. I can make sure they are in ASCII collating order, as with the glossary, to make them easier to find. @TheBF? @jedimatt42? @Willsy? @Vorticon? @FarmerPotato? @Reciprocating Bill? @dhe? @atrax27407? @GDMike? @arcadeshopper? @InsaneMultitasker? @OLD CS1? @Ksarul? @wolhess? @RickyDean? @Switch1995? @SteveB? @pjduplooy? @idflyfish? @HOME AUTOMATION? Anyone I missed?

 

...lee

[wolhess]

Thank You for the new fbForth version 3.0

 

Now I have to find out how I can update my fbForth 2.0 cartridge to the new one.

 

 

[+TheBF]

30 minutes ago, Lee Stewart said:

For the fbForth 3.0 manual, I am debating on whether to remove the words for the stack-based string library from the glossary. They are listed in the relevant chapter and they do bloat (clutter?) the glossary. I can make sure they are in ASCII collating order, as with the glossary, to make them easier to find. @TheBF? @jedimatt42? @Willsy? @Vorticon? @FarmerPotato? @Reciprocating Bill? @dhe? @atrax27407? @GDMike? @arcadeshopper? @InsaneMultitasker? @OLD CS1? @Ksarul? @wolhess? @RickyDean? @Switch1995? @SteveB? @pjduplooy? @idflyfish? @HOME AUTOMATION? Anyone I missed?

 

...lee

I think if you have a glossary for the words in the cartridge it would be fair to document library blocks  separately with their own mini-glossaries.

A one-liner explanation of how the docs are organized would cover that for the reader I should think. 

 

[+Vorticon]

Agree with @TheBF

[+Lee Stewart]

1 hour ago, wolhess said:

Thank You for the new fbForth version 3.0

 

You are most welcome.

 

1 hour ago, wolhess said:

Now I have to find out how I can update my fbForth 2.0 cartridge to the new one.

 

You or a friend can

1. Swap out the 27C256 EPROM with one (EPROM or PROM) that has the new version (fbForth300_9.bin) burned in or
2. Remove the EPROM. UV erase the current version. Burn in the new version (fbForth300_9.bin). Re-install EPROM.

 

...lee

[atrax27407]

Way back when fbFORTH Vn 2.0 came out, I decided that, since I only use it in 80-column mode I would like an 80-column MENU screen. So, I calculated the text, headers, and gutters and came up with a two-column 80-col display. Reasoning that I might need it at some later time, once it was installed and working, I used BLK>FILE (with HDR turned off) to copy BLOCKs 2 and 3 into a text file. Not being satisfied with the size of the FBLOCKS file (I needed space for future expansion), using MKBFL DSKx.filename n to create a much larger FBLOCKS file on a different drive. I arbitrarily chose 250 blocks as the size which created a 1000 sector FBLOCKS file (4 sectors per block). I changed the FBLOCKS file used with USEBFL DSKx.filename to swap to the new FBLOCKS.

 

Once that was done, I used CPYBLK to copy the orginial FBLOCKS 1 - 80 to the new FBLOCKS. Then using FILE>BLK, I copied my 80-col MENU backup into block 2 and 3 in the new FBLOCKS file. Since BLOCK block #57 in Vn 3.0 is empty, I edited the last several menu entries by simply typing over the text keeping the individual entry lengths the same. The only menu-display block that I actually needed to change was BLOCK #3.

 

Oh yes, if you wish to boot from a drive other than DSK1 (it is in the third file), simply search for "DSK1" with a hex editor and replace it with your preferred drive (mine boots from DSKD). Here is my 80-col MENU:

Edited June 7 by atrax27407

[+OLD CS1]

4 hours ago, TheBF said:

I think if you have a glossary for the words in the cartridge it would be fair to document library blocks  separately with their own mini-glossaries.

A one-liner explanation of how the docs are organized would cover that for the reader I should think.

@Lee Stewart One thing I have lamented in other systems is when I need a function but have no idea in what library that function exists.  I am fighting with this with my new email server system and its poor API documentation.  The glossary occupies 1/4 of the printed fbForth book, and it appears to supplement Chapter 2 with additional detail.  Retaining and maintaining Chapter 2 as a sort-of index of included words and dividing out the glossary to each library seems a reasonable approach.

[Reciprocating Bill]

8 hours ago, Lee Stewart said:

If this is the case, try converting FBLOCKS to TIFILES format with TI99Dir.

Worked like a charm! Thank you! And thank you for your astounding work on this Forth!

[wolhess]

22 hours ago, Lee Stewart said:

 

You are most welcome.

 

 

You or a friend can

1. Swap out the 27C256 EPROM with one (EPROM or PROM) that has the new version (fbForth300_9.bin) burned in or
2. Remove the EPROM. UV erase the current version. Burn in the new version (fbForth300_9.bin). Re-install EPROM.

 

...lee

Hi Lee,

if it is easy an EPROM change, I will test it next week.

Again Thank You!

wolhess

[+arcadeshopper]

https://www.arcadeshopper.com/wp/store/#!/fbForth-3-0/p/670284800/category=0

[+arcadeshopper]

13 hours ago, wolhess said:

Hi Lee,

if it is easy an EPROM change, I will test it next week.

Again Thank You!

wolhess

Depending on what board you have you may find that the file needs to be inverted..   if you have a green or black board in your cart it's the file with a 9 at the end, if its a red board it needs to be the one with the 8

[+Lee Stewart]

3 hours ago, arcadeshopper said:

Depending on what board you have you may find that the file needs to be inverted..   if you have a green or black board in your cart it's the stock file, if its a red board it needs to be inverted.

 

There is both an inverted binary (fbForth300_9.bin) and a non-inverted binary (fbForth300_8.bin) in fbForth300_20240604.zip in the first post.

 

In the batch directory, there is also a system and directions (readme.txt) for building inverted/non-inverted ROM binaries of any necessary size with a batch file (fbForth300BinPack.bat).

 

...lee

[+arcadeshopper]

corrected my previous post with the correct filenames

 

[+dhe]

Does this version include all the work you put in for Better DSR handling?

[+Lee Stewart]

Just now, dhe said:

Does this version include all the work you put in for Better DSR handling?

 

Yes, it does.

 

...lee

[+TheBF]

1 hour ago, Lee Stewart said:

 

Yes, it does.

 

...lee

I forgot about that. Perhaps that is speeding up the compile times as well. 

[+Lee Stewart]

1 hour ago, TheBF said:

I forgot about that. Perhaps that is speeding up the compile times as well. 

 

Definitely so for LOADing blocks. Each block is eight 128-byte-record reads. After the first access to a given blocks file, all subsequent accesses bypass the device search.

 

The relevant PPB call flag(s) is(are) only zeroed when

• A never-before-opened/created file is first accessed in a given Forth session
• USEBFL and MKBFL are executed
• COLD is executed (all three system PABs)
• A graphics mode change causes relocation of system PABs

 

...lee

Edited June 9 by Lee Stewart
additional info

[+TheBF]

2 hours ago, Lee Stewart said:

 

Definitely so for LOADing blocks. Each block is eight 128-byte-record reads. After the first access to a given blocks file, all subsequent accesses bypass the device search.

 

The relevant PPB call flag(s) is(are) only zeroed when

• A never-before-opened/created file is first accessed in a given Forth session
• USEBFL and MKBFL are executed
• COLD is executed (all three system PABs)
• A graphics mode change causes relocation of system PABs

 

...lee

I am jealous. That's a great improvment.

[Switch1995]

On 5/25/2024 at 10:05 PM, Lee Stewart said:

Then, of course, the real fun begins—yeah, I am going to embark upon the manual rewrite! Misguided though they be 🤪, suggestions for inclusion in the new manual are welcome. 

@Lee Stewart Congrats on this release!  I have a copy of fbForth 3.0 cartridge on order.  One suggestion that you could take or leave:  I really like how @matthew180 used a simple BASIC program to help teach Assembly in his thread.  Your manual (2.0) has sections 6.2 Graphics Words; 6.3 Color Changes; 6.4 Placing Characters on the Screen; 6.5 Defining New Characters; 6.6 Sprites; 6.8 Using Joysticks; etc. 

 

What would be really cool would be a VERY simple demo program tying all of these concepts together that the reader could type in/ learn from.  A Forth game loop shell….

[+TheBF]

Hi @Switch1995.   I made a large number of demos for my system but Forth like BASIC has a lot of dialects. 

FbForth is based on the Forth Interest Group dialect (FigForth)  and my system is based on the Forth 1994 standard dialect.

Both systems have different names and methods for connecting to the TI-99 hardware.  

 

The good news it is not too hard (he said nervously) to translate one to the other and between Lee and myself any questions are fair.

(our regular rates however do apply)  

 

So here is a demo I just translated that is not a "game loop" per se but it demonstrates some Forth ideas in how one uses this beast.

(translating from BASIC to Forth in a literal fashion will usually make one unhappy)

 

I would recommend reading the first few chapters of Starting Forth as an intro.

Forth is odd and it is important to have a firm understanding of the foundations. 

Starting FORTH - FORTH, Inc

 

This was tested on FbForth 3.0 by pasting it into Classic99 with FbForth running.

\ screen thing for FbForth 

\ demonstrates some Forth ideas
\ 1. Using named constants for ascii character
\ 2. Breaking programs up into small words
\    Test each word at the console before going on
\ 3. How to make a BREAK key
\ 4. Using your words to built a final program 
\ 5. How to make stack diagrams to document inputs/outputs
\ 6. You don't need HCHAR to write to the screen <wink>

DECIMAL
ASCII * CONSTANT '*'
ASCII ! CONSTANT '!'
768 1-  CONSTANT N  \ chars per screen - 1

\ compute the correct color set number for any ASCII char 
: SET#  ( ascii -- color_set) 8 / ; 

\ cause a delay in milliseconds (or so)
: MS    ( msdelay -- ) 0 DO  9 0 DO LOOP LOOP ;

: GRAPHICS-STUFF ( -- )
    GRAPHICS
\   FG BG  colorset    
    13  1  '*' SET# COLOR
    7   1  '!' SET# COLOR
;

\ thething uses VDP SINGLE BYTE WRITE (VSBW)
\ to write a character to the screen
\ The stack diagram for VSBW is ( char VDPaddr --)
: THE-THING ( -- )
    PAGE
    N 0   \ loop from 0 to screen size - 1 
    DO    \ I becomes the VDP screen address 
       '!'  I     VSBW      \ write directly to VDP screen memory 
       '*'  N I - VSBW      \ write to bottom of screen
        25 MS
        ?TERMINAL ABORT" *BREAK*" 
    LOOP
    DROP
;

: RUN ( -- )
    GRAPHICS-STUFF 
    BEGIN 
      THE-THING 
    AGAIN 
    TEXT 
;

CR ." **Type RUN start"
CR  ." FNCT 4 to stop "

 

 

[+TheBF]

DELETED. 

Site went down as I saved.