Jump to content

Photo

fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 12/12/2018]

fbForth Forth TI Forth

1492 replies to this topic

#1476 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Tue Nov 27, 2018 7:35 AM

I think I get it now.  ?OF should actually find 2 numbers on the stack, viz., the number being tested by CASE and the flag.  I have not yet tested what follows, but I think it will work.  The idea of the code is to toggle the flag and add it to a duplicate of the test number before presenting it to OF .  A false flag will then force a mismatch, while a true flag will force a match.  It must be paired with ENDOF .

 

Here it is for Camel99 Forth:

: ?OF    \ compile-time: ( 4 -- here 5 )  run-time: ( n flag -- []|n)
      \ toggling flag will force proper match/mismatch for OF
      POSTPONE 0= POSTPONE OVER POSTPONE +         \ S:n flag'+n
      POSTPONE OF  ; IMMEDIATE 

Here is the equivalent fbForth version:

: ?OF    \ compile-time: ( 4 -- here 5 )  run-time: ( n flag -- []|n)
      \ toggling flag will force proper match/mismatch for OF
      COMPILE 0= COMPILE OVER COMPILE +         \ S:n flag'+n
      [COMPILE] OF  ; IMMEDIATE 

Here is an example of its use (block #41 of FBLOCKS must be loaded to use WITHIN ):

: XX  ( n -- ) 
      CASE
         DUP 2 9 WITHIN ?OF ." In range (2,9)." ENDOF
         ELSEOF ." No match!" ENDOF
      ENDCASE  ;

...lee

 

[Edits in this color.]



#1477 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Tue Nov 27, 2018 8:52 AM

The above version of ?OF works in fbForth 2.0!

 

TheBF’s example use of ?OF inspired the following word, which requires block #41 of FBLOCKS to be loaded for PICK , WITHIN and -ROT :

: RANGEOF   \ compile-time ( 4 -- here 5 )   run-time: ( n lo hi -- []|n )
      COMPILE 2 COMPILE PICK COMPILE -ROT       \ S:n n lo hi
      COMPILE WITHIN                            \ S:n flag
      COMPILE 0= COMPILE OVER COMPILE +         \ S:n flag'+n
      [COMPILE] OF  ; IMMEDIATE

It must be paired with ENDOF and used within a CASE ... ENDCASE construct as

: TEST  ( n -- )
    CASE
       2 9 RANGEOF ." In range." ENDOF
       ELSEOF ." No match!" ENDOF
    ENDCASE  ;

...lee



#1478 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Tue Nov 27, 2018 1:02 PM

Cool!  I forgot I posted this experiment. So yeah. That's what I meant.  ;)

Thanks for figuring it out for me

 

I have been crunching on resurrecting the directed threaded version of CAMEL99 Forth which means fixing the cross-compiler and all the rest. I broke it a year ago, but decided to focus on one code base until I got things working better.

 

My old brain is sweating, but I am getting closer.

 

After DTC I want to take serious run at sub-routine threading with some inline primitives. It should run 3 times faster...

in theory.



#1479 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Tue Nov 27, 2018 4:42 PM

As I looked at your code, I realized that Chuck says "the dictionary is your case statement" (or something like that).
 
Here is my interpretation of what that means in regards to your SAVE-FONT word:
 
Spoiler

 

My 2 cents Canadian.  (about 1.44 cents USD so take it for what it's worth)

 

 

Here is my version, after some re-thinking of SAVE-FONT :

HEX
\ The following 2 words are Brian Fox’s creations
: VPLACE   ( addr len vaddr -- )  \ like PLACE, but for RAM to VRAM
      OVER OVER VSBW 1+ SWAP VMBW ;
: CLIP ( n min max -- n') ROT MIN MAX ; 

PABS @         \ VRAM address for PAB
HERE           \ RAM addres for PAB-BUF (dummy not actually used)
PDT            \ VRAM address for PAB-VBUF (Pattern Descriptor Table)
FILE FONTFIL   \ associate above 3 addresses with FONTFIL

\ SAVE-FONT forces bytes to be 1024..2048
: SAVE-FONT  \ ( bytes -- )   ( IS:<fontFileName> )
      400 800 CLIP         \ forces font file size of 1..2 KiB 
      FONTFIL SET-PAB      \ set up FONTFIL
      BL WORD HERE COUNT   \ filename-addr cnt
      PAB-ADDR @ 9 +       \ vaddr
      VPLACE               \ cnt+filename->PAB+9
      SV    \ save 1024..2048-byte binary font image to file
;  
\ Usage example: 400 SAVE-FONT DSK1.FONT0230
DECIMAL

And, here it is à la MKBFL (requires same preamble as SAVE-FONT):

HEX
: SVFFL  ( IS:<fontFileName> <bytes> )
      FONTFIL SET-PAB      \ set up FONTFIL
      BL WORD HERE COUNT   \ filename-addr cnt
      PAB-ADDR @ 9 +       \ vaddr
      VPLACE               \ cnt+filename->PAB+9
      BL WORD              \ <bytes> input string to HERE
      HERE NUMBER DROP     \ convert to 16-bit number on stack
      400 800 CLIP         \ force font file size of 1..2 KiB 
      SV    \ save 1024..2048-byte binary font image to file
;
\ Usage example: SVFFL DSK1.FONT0230 400
DECIMAL

...lee



#1480 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Wed Dec 12, 2018 3:24 PM

CF7+/nanoPEB Mounting Utilities—

 

Back in post #1350, about 2 years ago (I cannot believe it has been this long!) I posted utilities for mounting CF7+/nanoPEB volumes in a non-persistent manner and had indicated that a permanent solution might be a little too involved to be worth pursuing.  Well, with a little help from code that Guillaume Tello (moulinaie) had developed for Extended Basic, and with his blessing, I have written a word, CFPMOUNT , that permanently mounts volumes, i.e., they persist after a system reset because the volume#-DSK# associations are stored on the CF card.  All of the CF utilities will be in the new FBLOCKS I will post later tonight.  Here is that code for those who cannot wait:

Spoiler

 

Later, I will also explain a bit more about what is going on with CFPMOUNT .

 

...lee



#1481 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Wed Dec 12, 2018 10:41 PM

I updated post #1 with all files related to fbForth 2.0:11, which includes new words, 

  • BYE ( -- ) —A synonym for MON
  • SD0 ( -- addr ) —Returns the address of the bottom of the FIFO sound stack in low RAM
  • CMOVE> ( src dst cnt -- ) —Copies cnt bytes of src RAM to dst RAM in the opposite direction as CMOVE , i.e., from high RAM to low RAM.  As with CMOVE and MOVE , it is not overlap safe.
  • ABORT" ( flag -- )  (IS:<message>") —If flag is nonzero, <message> is printed and ABORT is executed.  See the spoiler in my last post for examples of usage in the definitions of CFCHK and DSKCHK .

Also posted is the latest FBLOCKS file, with the new word, CFPMOUNT , added to the Compact Flash Utilities.  CFPMOUNT persists the mounting of volumes until the next change, i.e., it survives a system reset or removal of the CF card.  You may recall that CFMOUNT actions do not survive a system reset.  See post #1480 above for more detail.

 

I will update fbforth.stewkitt.com in the near future.

 

...lee



#1482 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Thu Dec 13, 2018 1:54 PM

Hey Lee,

 

Since you and Willsy implement blocks as files, it is making me think about using a "BLOCK" file for virtual memory to create a text file editor. 

It would work like this:

  1. Load the text file into a block file, adding blocks as needed
  2. Edit the text file in the blocks
  3. Save the file back to DV80 format when you are done editing and delete block file.

What do you think of that approach?



#1483 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Thu Dec 13, 2018 5:37 PM

You could probably do something like that.  If I were to do that in fbForth, I would need to figure out how to handle lines because a block is 1024 characters with no delimiters except at the end of the block.  A block is usually visualized as 16 64-character lines, but the block is filled with spaces when empty.  That said, there is nothing preventing using block space in another way.  We do it all the time with binary image blocks.  I use blocks for program images on occasion.  I did that for Walid’s plotter driver.

 

You may know, but just to be sure, TurboForth and fbForth use DF128 files for blocks.  Each block is 8 records in 4 sectors.  fbForth uses 4 block buffers in low RAM space (same design as  TI Forth, which has 5 buffers) with a single 128-byte record buffer in VRAM, whereas, TurboForth has its block buffers in VRAM, which, IIRC, are also the record buffers.  I forgot how many block buffers TurboForth has (5 or 6?).  TI Forth has 5 block buffers handled the same as fbForth but TI Forth reads/writes 4 sectors at a time without regard to file I/O, using a 1024-byte VRAM buffer.  TurboForth may be faster with block I/O but does not manage bitmap graphics as do the other two Forths.  Sorry, I am rambling...

 

...lee



#1484 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,100 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Dec 14, 2018 10:54 AM

Yes TF has 6 block buffers at power-up but you can change that with the #BUF variable. It's possible for TF to do bitmap (if the appropriate library were developed - I ran out of steam and talent!) but block operations would corrupt your screen. Likely not a major issue as most programs run from ram once they're loaded.

#1485 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Fri Dec 14, 2018 12:13 PM

Yes TF has 6 block buffers at power-up but you can change that with the #BUF variable. It's possible for TF to do bitmap (if the appropriate library were developed - I ran out of steam and talent!) but block operations would corrupt your screen. Likely not a major issue as most programs run from ram once they're loaded.

 

I believe the “time” bit but not the “talent” bit.  You are a very talented programmer!

 

...lee



#1486 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Sun Dec 16, 2018 10:57 PM

You could probably do something like that.  If I were to do that in fbForth, I would need to figure out how to handle lines because a block is 1024 characters with no delimiters except at the end of the block.  A block is usually visualized as 16 64-character lines, but the block is filled with spaces when empty.  That said, there is nothing preventing using block space in another way.  We do it all the time with binary image blocks.  I use blocks for program images on occasion.  I did that for Walid’s plotter driver.

 

You may know, but just to be sure, TurboForth and fbForth use DF128 files for blocks.  Each block is 8 records in 4 sectors.  fbForth uses 4 block buffers in low RAM space (same design as  TI Forth, which has 5 buffers) with a single 128-byte record buffer in VRAM, whereas, TurboForth has its block buffers in VRAM, which, IIRC, are also the record buffers.  I forgot how many block buffers TurboForth has (5 or 6?).  TI Forth has 5 block buffers handled the same as fbForth but TI Forth reads/writes 4 sectors at a time without regard to file I/O, using a 1024-byte VRAM buffer.  TurboForth may be faster with block I/O but does not manage bitmap graphics as do the other two Forths.  Sorry, I am rambling...

 

...lee

 

I could probably use 128 bytes lines internally and then print them out to a text file when I save then using -TRAILING on each line. It will not be real fast to save but it would work.

But I am considering making a 40 column editor without windowing so lines fit on the screen. Kind of like the original Forth used 64 column lines because that fit on the screen at the time.

 

Is there a reason you use DF128 files and not DF256 (is 256 possible?)



#1487 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Mon Dec 17, 2018 8:33 AM

I could probably use 128 bytes lines internally and then print them out to a text file when I save then using -TRAILING on each line. It will not be real fast to save but it would work.

But I am considering making a 40 column editor without windowing so lines fit on the screen. Kind of like the original Forth used 64 column lines because that fit on the screen at the time.

 

If you have not set up block buffers à la figForth as with TI Forth, fbForth and TurboForth, there is no reason you could not devise your own, possibly more convenient scheme.  You could set up block buffers that hold 16 80-character lines that use block files with 5 sectors/block.  That would likely be less wasteful of RAM real estate, but, of course, require blocks files that are 5-sector (1280-byte) multiples.

 

Is there a reason you use DF128 files and not DF256 (is 256 possible?)

 

Yes.  DF128 is the largest record size that uses the entire sector for data, i.e., there is no wasted space.  DF256 is not possible because there is only a 1-byte space in the FDR for storing the bytes/record and storing 0 in the records/sector byte means that the file is a program file, which complicates reading the file.  DF255 (I think that is possible) would only allow blocks of 1020 bytes, requiring an inconvenient line-handling algorithm.  And, of course, with 64 characters per “line” and 128 as a multiple of 64, it is quite convenient.

 

...lee



#1488 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Mon Dec 17, 2018 11:08 AM

Ok thanks.  I am looking at old code from HsForth for blocks in files.  I should take a look at FB Forth too.



#1489 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Mon Dec 17, 2018 8:05 PM

While scouring my old system from the 90s I found this code that I wrote to manage block source files.

 

Some of it might have value for if you don't already have them.

I always liked the "listing" word.  I would run it to the printer and put the listings in my source code folder.

And then run the .index and get a table of contents.

 

So convenient.

Spoiler


#1490 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Mon Dec 17, 2018 8:31 PM

Somewhat similar stuff in TI Forth (Alternate I/O, block 72) and fbForth (Alternate I/O, block 19).

 

...lee



#1491 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Mon Dec 17, 2018 10:39 PM

I may have use that as a starting point. I can't remember. The guy that wrote HsForth hated blocks, so there was minimal support.



#1492 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Sat Jan 5, 2019 11:58 AM

Space saving opportunity?

 

Hi Lee,

 

While I was looking at FBForth's block file code I found this:

: R/W   ( bufaddr block# flag --- )
    IF
       RBLK
    ELSE
       WBLK
    THEN  ;

It appears to be used only twice. Once in the READ operation in BLOCK and once in WRITE operation in BUFFER. 

This appears to be a tradition in Fig Forth and I also see it in MVP Forth, by Glen Hayden, (circa 1983) which also has a form of this word controlled by a parameter on the stack.

This seems to break the axiom "the dictionary is your case statement".

 

HsForth, (circa 1990) removes the control parameter and simple puts the RBLK in the BLOCK word and the WBLK in the BUFFER word

as does FPC by Tom Zimmer (circa 1988) and ZenForth by Martin Tracy (1989)

It appears the Fig-Forth sacred tradition was removed by more contemporary authors.

 

Perhaps you could put this on your stack for future changes to save some space.



#1493 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • Topic Starter
  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Sat Jan 5, 2019 12:31 PM

Yeah...That was mostly to avoid breaking anything in TI Forth user code and probably a little laziness, as well.  |:)

 

...lee







Also tagged with one or more of these keywords: fbForth, Forth, TI Forth

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users