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

+Lee Stewart · February 9

Here is the promised build H: fbForth300_8_Ha.bin

@Reciprocating Bill, please note that RL has been changed from 60 ticks to 100 ticks. You may, of course, prefer it slower yet. Let me know.

...lee

+Lee Stewart · February 10

It was never clear to me why the TI programmers of TI Forth defined the word DSRLNK to presume its use for only Level 3 file handling. I am seriously considering changing the fbForth word DSRLNK (inherited from TI Forth) to require an argument of 8 for Level 3 file handling and 10 for Level 1 and 2 subprograms, just as its ALC counterpart. This will obviously require any TI Forth code ported to fbForth to put 8 on the stack before DSRLNK is executed. Thoughts?

...lee

+TheBF · February 10

9 minutes ago, Lee Stewart said:

It was never clear to me why the TI programmers of TI Forth defined the word DSRLNK to presume its use for only Level 3 file handling. I am seriously considering changing the fbForth word DSRLNK (inherited from TI Forth) to require an argument of 8 for Level 3 file handling and 10 for Level 1 and 2 subprograms, just as its ALC counterpart. This will obviously require any TI Forth code ported to fbForth to put 8 on the stack before DSRLNK is executed. Thoughts?

...lee

I think it's a great idea. I have been meaning to do something like that for a long time.

I just hate touching the DSRLNK because my life goes on hold for awhile when I do.

+Lee Stewart · February 14

I have changed the word DSRLNK to expect 8 or 10 on the stack rather than presuming 8. This breaks DIR and CAT and “TI Forth disk browser/copier” on FBLOCKS, which I will correct in the next rewrite of FBLOCKS.

After a confab with @atrax27407, I have added the option of toggling case sensitivity for (FIND) with a new word: CSEN

0 CSEN      \ sets case sensitivity OFF
1 CSEN      \ sets case sensitivity ON (this is the default)

Current beta: fbForth300_8_Ia.bin <<====faulty case-insensitive function...see next beta posted later!!

...lee

Edited February 15 by Lee Stewart
corrections

atrax27407 · February 14

Thanks, Lee😄

+Lee Stewart · February 15

The last beta had a faulty case-insensitive function—too quick on the draw, alas. :dunce:

Here is a better beta: fbForth300_8_Ja.bin

Here is the ALC of (FIND) for the terminally curious (see an example of X usage):

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
;]*

*++ <<<<<<<<<In low RAM >>>>>>>>>>
*++ Convert lowercase character to uppercase
*++  Input: R0 MSB = character to test
*++ Output: R0 MSB = uppercase character
CASEUP CI   R0,>6100       ;compare to 'a'
       JLT  CASEXT         ;if < 'a', it's not a lowercase char
       CI   R0,>7A00       ;else compare to z
       JGT  CASEXT         ;if > 'z', it's not a lowercase char
       ANDI R0,>DF00       ;to uppercase
CASEXT RT                  ;return with char in uppercase

...lee

+TheBF · February 15

How do we enable/disable case insensitivity?

I see the CASENS flag in the code but it's not a variable name.

+Lee Stewart · February 15

4 minutes ago, TheBF said:

How do we enable/disable case insensitivity?

I see the CASENS flag in the code but it's not a variable name.

New word CSEN (short for “Case SENsitivity”:

0 CSEN      \ sets case sensitivity OFF
1 CSEN      \ sets case sensitivity ON (this is the default)

The value for “Case Sensitivity ON” can be any non-zero value.

...lee

+Lee Stewart · March 1

While working on my new DSRLNK, I had improved (I think) VRAM reads to use fewer instructions than I had used previously, so I thought I should review other ALC in the fbForth kernel for the same improvements. While doing so, I discovered a bug I had introduced into SPRGET while trying to fix a previous bug related to how a sprite’s y value is stored in the Sprite Attribute Table. The bugs and their ultimate fix are described in the excerpt from my fbForth 3.0 TODO list in the spoiler:

Spoiler

++Fixed bug in SPRGET discovered while making changes to SPDST and SPDISTXY .
   If y=0, the value in SATR is >FF. After retrieving it and a logical 8-bit
   right shift, the value became >00FF (255). Incrementing by 1 to correct it 
   to actual screen position, which for >FF should be 0, obviously gives the
   wrong position! 
   **First solution created another bug!!:
         SRA  R0,8      ;to right byte, clearing left byte unless negative
         INC  R0        ;increment y
      --Works for >FF (-1): >FFFF + 1 = 0.
      --Fails miserably for >80..>FE (128..254): 
         ::>FF80 + 1 = >FF81 (-127) [should be >0081 (129)]
         ::>FFFE + 1 = >FFFF (-1)   [should be >00FF (255)]
   **Solution that works:
         AI   R0,>0100  ;increment y before shift to handle possible -1
         SRL  R0,8      ;move to LSB, clearing MSB

Here is the latest beta with the fix: fbForth300_8_Ka.bin <<< Happy now, Bob (@atrax27407)? >>>

...lee

atrax27407 · March 1

You're getting there! The "Wizard of Forth" strikes again. Busy putting the HSGPL version together.

+Lee Stewart · March 22

OK...

I now have the new DSRLNK working for all words/functions (blocks I/O, FILES word, Font Editor) except the high-level File words (Chapter 8 of the manual) and the alternate keyboard/display I/O. If you want to try it out, here is the beta: fbForth300_8La.bin

Oh...I should add that current free space is down to

bank 0: 116 bytes
bank 1: 92 bytes
bank 2: 172 bytes
bank 3: 118 bytes

...lee

atrax27407 · March 23

I haven't been able to uncover any gross errors so far.

+TheBF · March 23

Couple of things I just noticed but I may have an old version of FBLOCKS

I do 6 LOAD. The compile flag EDT in block 12. I changed it to EDIT and it seems fine.

Also the menu says "64 column editor"

Is the 64 column editor supposed to be the one in TEXT mode?

I always thought the 64 column editor was the one in SPLIT mode.

atrax27407 · March 23

There seems to be a problem with the latest FBLOCKS and the latest DSRLNK. I get errors when loading some of the BLOCKS (i.e., DIR) and some (but not all) others. I will have to go through the BLOCKS one by one to see which ones have load errors with the new DSRLNK.

Edited March 23 by atrax27407

+Lee Stewart · March 23

On 3/23/2024 at 10:44 AM, TheBF said:

Couple of things I just noticed but I may have an old version of FBLOCKS

The current version of FBLOCKS is 17LUL2023 and definitely not up to date. I have to update any blocks that use DSRLNK.

On 3/23/2024 at 10:44 AM, TheBF said:

I do 6 LOAD. The compile flag EDT in block 12. I changed it to EDIT and it seems fine.

EDT is the main word in the 64-column editor. EDIT is redefined to run EDT in the EDITOR2 vocabulary.

On 3/23/2024 at 10:44 AM, TheBF said:

Also the menu says "64 column editor"

Is the 64 column editor supposed to be the one in TEXT mode?

I always thought the 64 column editor was the one in SPLIT mode.

It does, indeed, run in SPLIT mode.

...lee

+Lee Stewart · March 23

5 minutes ago, atrax27407 said:

There seems to be a problem with the latest FBLOCKS and the latest DSRLNK. I get errors when loading some of the BLOCKS (i.e., DIR) and some (but not all) others.

Yeah...any blocks with DSRLNK calls must be updated before they will run properly. I am nearly done with DSRLNK updates to the fbForth 3.0 cartridge. I will then get after FBLOCKS.

Thanks to you and @TheBF for your tests!

...lee

+Lee Stewart · March 26

On 3/23/2024 at 11:39 AM, Lee Stewart said:

Yeah...any blocks with DSRLNK calls must be updated before they will run properly. I am nearly done with DSRLNK updates to the fbForth 3.0 cartridge. I will then get after FBLOCKS.

Thanks to you and @TheBF for your tests!

OK...I am pretty much done with the Chapter-8 File I/O changes for the new DSRLNK. I also have working DIR and CAT utilities for the new FBLOCKS.

I have been puzzling over what broke the 64-column editor and am reasonably sure it has to do with graphics mode switching and blocks I/O code. I did make changes to both and undoubtedly broke something. I did discover that, if I switch to Split mode before invoking the 64-column editor, it works. Exiting the editor shows issues, as well. I need to work through the mode-changing and blocks I/O code to shake out the bugs—too many balls in the air at once, I’m afraid!

Aside from bug fixing (may not get done until after return from Florida next week) and managing the DSRLNK changes for Alternate I/O (RS232 card) for KEY and EMIT (easy) , I am nearly done with the cartridge code for fbForth 3.0.

After I run down the bugs in recent code changes exposed by the 64-column editor, I will start knocking down the updates for FBLOCKS. Meanwhile, here is the current beta:

fbForth300_8_Ma.bin

Current remaining cartridge space (some improvement! )

bank 0: 162 bytes
bank 1: 102 bytes
bank 2: 184 bytes
bank 3: 118 bytes

...lee

RickyDean · March 27

22 minutes ago, Lee Stewart said:

OK...I am pretty much done with the Chapter-8 File I/O changes for the new DSRLNK. I also have working DIR and CAT utilities for the new FBLOCKS.

I have been puzzling over what broke the 64-column editor and am reasonably sure it has to do with graphics mode switching and blocks I/O code. I did make changes to both and undoubtedly broke something. I did discover that, if I switch to Split mode before invoking the 64-column editor, it works. Exiting the editor shows issues, as well. I need to work through the mode-changing and blocks I/O code to shake out the bugs—too many balls in the air at once, I’m afraid!

Aside from bug fixing (may not get done until after return from Florida next week) and managing the DSRLNK changes for Alternate I/O (RS232 card) for KEY and EMIT (easy) , I am nearly done with the cartridge code for fbForth 3.0.

After I run down the bugs in recent code changes exposed by the 64-column editor, I will start knocking down the updates for FBLOCKS. Meanwhile, here is the current beta:

fbForth300_8_Ma.bin 32 kB · 2 downloads

Current remaining cartridge space (some improvement! )

bank 0: 162 bytes

bank 1: 102 bytes

bank 2: 184 bytes

bank 3: 118 bytes

...lee

Enjoy your Florida trip, it's a bit rainy in this neck of the woods, but nice other wise.

atrax27407 · March 27

Downloaded, HSGPL-modified, and installed (and waiting for the next update 😁)

+Lee Stewart · March 27

12 hours ago, RickyDean said:

Enjoy your Florida trip, it's a bit rainy in this neck of the woods, but nice other wise.

We have enjoyed it since December 1. Returning to Maryland to, likely, rain April 2.

...lee

+Lee Stewart · March 28

The problem with invoking the 64-column editor does, indeed, involve graphics mode switching. When the graphics mode is switched from non-bitmap modes (TEXT,TEXT80,GRAPHICS,MULTI) to bitmap modes (GRAPHICS2,SPLIT,SPLIT2) or vice versa, the system PABs (1user font file, 2 blocks files) are moved. The problem with the move is that the VRAM buffer address in each PAB does not get updated, so all hell breaks loose when the EDIT word is invoked with no intervening USEBFL (Use Blocks File). There may be one other VRAM location change that needs to be made, as well.

I may be able to split COLD into more than one routine such that a part could be invoked by the mode change code to make everything better without too much code bloat. We’ll see ....

...lee

+Lee Stewart · March 29

Wow! This took a bit of head scratching and code wizardry(?). Everything related to graphics mode switching seems to be working now. The 64-column editor also works fine. Here is the current beta: fbForth300_8_Na.bin

Gettin’ tighter!:

bank 0: 162 bytes
bank 1: 112 bytes
bank 2: 118 bytes
bank 3: 118 bytes

...lee

fbForth300_8.bin

+TheBF · March 29

Could you fire over your most recent FBLOCKS file as well?

atrax27407 · March 29

OK. Once again downloaded, HSGPL-modified, installed and awaiting the corrected FBLOCKS file. Will the individual applications reside on the same block #'s?

+Lee Stewart · March 29

14 hours ago, TheBF said:

Could you fire over your most recent FBLOCKS file as well?

11 hours ago, atrax27407 said:

OK. Once again downloaded, HSGPL-modified, installed and awaiting the corrected FBLOCKS file. Will the individual applications reside on the same block #'s?

OK ... Here is a partially updated FBLOCKS: FBLOCKS

The utilities marked “...OK..” just before the block# on the menu have either been updated or shown to work with the current beta.

...lee

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members