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

[+Lee Stewart]

On 2/19/2022 at 12:21 PM, Lee Stewart said:

maybe it’s time to make this fbForth 3.0?

 

Perhaps, I will make it fbForth 2.1.

 

Also, I need some thoughts about my last-posted question. Anybody?

 

...lee

[HOME AUTOMATION]

On 2/19/2022 at 12:21 PM, Lee Stewart said:

I can manage the address calculations at startup if necessary, but I would rather not. Does anyone know whether these addresses are , indeed, constant?

Better safe than sorry.

 

     -HA

[+TheBF]

15 minutes ago, Lee Stewart said:

 

Perhaps, I will make it fbForth 2.1.

 

Also, I need some thoughts about my last-posted question. Anybody?

 

...lee

I have no direct knowledge but given that it's a 42 (?) year old design my money is on,  it's not changing. 

It's just a feeling mind you.

(There's always a smartass)

 

[GDMike]

 Following

Edited February 21, 2022 by GDMike

[+jedimatt42]

13 hours ago, Lee Stewart said:

 

Perhaps, I will make it fbForth 2.1.

 

Also, I need some thoughts about my last-posted question. Anybody?

 

...lee

TI created a lot of abstractions like the XMLLNK table that would have made changing the memory map possible on a future system. But if you are content with 4A compatibility, the silence suggests it is safe to assume the same console ROM in all. 

 

There is clearly a design intention for there to be various compatible versions of the console ROM. But proving the absence of something ever existing is never really satisfying.

 

I should build a small cart that checksums the console ROM, as a diagnostic / identifier. 

 

Maybe a direct message to Jim 

 

 

[Willsy]

There's maybe a difference on the v2 console (where they disabled cart ROM scanning). But that ROM is available in classic 99 so easily verified.

[+Lee Stewart]

58 minutes ago, Willsy said:

There's maybe a difference on the v2 console (where they disabled cart ROM scanning). But that ROM is available in classic 99 so easily verified.

 

Just checked and the Floating Point XML table references are, indeed, the same—WooHoo! 

 

...lee

[GDMike]

Wouldn't that be cool to have FPL used this way and making it easy to access.

[+Lee Stewart]

Ok...I am gearing up to produce fbForth 2.1. The first thing I am dong is adding auto-repeat to the keyboard. Here is the original code inherited from TI Forth:

 

Spoiler

KEY0   MOV  @KEYCNT,R7
       INC  R7
       JNE  KEY1
       MOV  @CURPO$(U),R0
       BLWP @VSBR             Read character at cursor position...
       MOVB R1,@CURCHR        ...and save it
       LI   R1,>1E00          Place cursor character on screen
       BLWP @VSBW
*
KEY1   BLWP @KSCAN
       MOVB @KYSTAT,R0
       COC  @H2000,R0         check status
       JEQ  KEY2              JMP if key was pressed
*
       CI   R7,100            No key pressed
       JNE  KEY3
       MOVB @CURCHR,R1
       JMP  KEY5
*
KEY3   CI   R7,200
       JNE  KEY4
       CLR  R7
       LI   R1,>1E00          Cursor char
KEY5   MOV  @CURPO$(U),R0
       BLWP @VSBW
KEY4   MOV  R7,@KEYCNT
       MOV  @INTACT,R7        Are we in user's ISR?
       JNE  KEY6              Don't enable interrupts if so.
       LIMI 2
KEY6   DECT IP                This will re-execute KEY
       B    *NEXT
KEY2   SETO @KEYCNT           Key was pressed
       MOV  @CURPO$(U),R0     Restore character at cursor location
       MOVB @CURCHR,R1
       BLWP @VSBW
       MOVB @KYCHAR,R0        Put char in...
       SRL  R0,8              ...LSB of R0
       B    @BKLINK

 

 

and here is my new code with auto-repeat:

 

Spoiler

* This routine has been modified to allow for key repeats by holding
* a key down long enough. Repeats can be disabled by storing an odd
* number at RH. User can do this by storing at DCT+16. Access to RL
* is similarly at DCT+18, but should never be odd.
*
KEY0   INC  @KEYCNT           inc cursor/char blink count
       JNE  KEY1              jump if re-entry
       MOV  @CURPO$(U),R0     get cursor position
       BLWP @VSBR             Read character at cursor position..
       MOVB R1,@CURCHR        ..and save it
       LI   R1,>1E00          Place cursor character..
       BLWP @VSBW             ..on screen
*
* Check for keystroke
KEY1   BLWP @KSCAN            check keyboard..
       MOVB @KYSTAT,R0        ..for keystroke
       COC  @H2000,R0         check status
       JEQ  KEY8              jump if key was pressed
* 
* Check time for char blink
       LI   R7,180            load time for char blink
       C    @KEYCNT,R7        time to blink char?
       JNE  KEY2              jump if not
       MOVB @CURCHR,R1        yes..get char to display
       JMP  KEY3              and display it
*
* Check time for cursor blink
KEY2   SLA  R7,1              load time (360) for cursor blink
       C    @KEYCNT,R7        time to blink cursor?
       JNE  KEY4              jump if not
       CLR  @KEYCNT           yes..clear blink count for re-entry
       LI   R1,>1E00          get cursor char
KEY3   MOV  @CURPO$(U),R0     get cursor position
       BLWP @VSBW             display cursor or char
*
* Check for key, pressed or not
KEY4   CB   @KYCHAR,@HXFF00   no key?
       JNE  KEY5              jump if we have a key
       MOV  @RH,@RCNT         reset repeat count
       JMP  KEY6              re-enter via fbForth's KEY
* 
* Repeat key processing
KEY5   DECT @RCNT             time to repeat key?
       JNE  KEY6              jump if not yet time
       MOV  @RL,@RCNT         set repeat count to low count
       JMP  KEY8              process key
* 
* Set up to re-enter via fbForth's KEY       
KEY6   MOV  @INTACT,R7        Are we in user's ISR?
       JNE  KEY7              Don't enable interrupts if so.
       LIMI 2                 no..enable interrupts
KEY7   DECT IP                re-execute fbForth's KEY
       B    *NEXT
* 
* Return pressed/same key to caller
KEY8   SETO @KEYCNT           -1 to reset re-entry indicator
       MOV  @CURPO$(U),R0     Restore character at cursor location
       MOVB @CURCHR,R1
       BLWP @VSBW
       MOVB @KYCHAR,R0        Put char in...
       SRL  R0,8              ...LSB of R0
       JMP  BKLINK

 

 

Let me know if you have any improvements to the code.

 

The next thing I will be working on is changing the FPL (Floating Point Library) to use the console ROM routines for FMUL,FDIV,FADD,FSUB,FCOM,CSN,CFI. This should be faster than my current ROM routines because they are on the 16-bit bus. I will then work on the remaining FPL routines to accommodate the console routines where they can be used (rounding, etc.). Any feedback will be appreciated. 

 

...lee

[+TheBF]

That's a nice addition.

How does a character get from R0 to top of stack?

[+Lee Stewart]

1 hour ago, TheBF said:

That's a nice addition.

How does a character get from R0 to top of stack?

 

The high-level KEY calls kEY , which gets to the system routine (via “BL *LINK”) that branches to the routine I posted. It is when that returns that R0 is pushed to the stack via code that duplicates what is commented out at the end of kEY :

;[*** KEY ***        ( --- 7-bit-char )
*        DATA KE__N
* KEY__N .name_field 3, 'KEY'

KEY    DATA DOCOL
       DATA KE,LIT,>7F,_AND,SEMIS
*
;]*
;[*** kEY ***        ( --- char )
*        DATA NCLS_N
* KE__N  .name_field 3, 'kEY'

KE     DATA $+2
       LI   R1,-2
       MOV  @$SYS(U),LINK
       BL   *LINK
       JMP  R02STK      ; space-saving JMP [R02STK must be within 254 bytes]
*        DECT SP
*        MOV  R0,*SP
*        B    *NEXT
*
;]*

...lee

[+TheBF]

I don't understand the details of your trampoline or implications of it but could you replace R0 with *SP, by doing a DECT SP before you start the whole thing?

(Maybe R0 is in another workspace?) 

 

 

 

[+Lee Stewart]

8 minutes ago, TheBF said:

I don't understand the details of your trampoline or implications of it but could you replace R0 with *SP, by doing a DECT SP before you start the whole thing?

(Maybe R0 is in another workspace?) 

 

Perhaps (it is, in fact, in the Forth workspace), but I would need to analyze everything that calls that system code. Most (all?) of those system routines pass values back and forth via registers. It is basically straight from TI Forth and there is likely a lot that could be optimized. Once I work through the FPL stuff, there will be some room in bank 3 to work with. I might be able to hoist quite a bit of stuff out of low RAM, but I would need to weigh the effects of trampolining in and out of bank 3. As things stand now, the system calls do not need trampoline code—they are in low RAM.

 

...lee

[+TheBF]

I am sure it would work just fine as is.

It just seems that since the output needs to get there and the machine can reference memory real well that there could be some space saving by using  [ EDIT *SP ] right out of the gate.

 

I am also eyeballing KEYCNT ? and wondering about keeping it on the Rstack to save another variable. 

 

Edited March 8, 2022 by TheBF
TYPO

[+Lee Stewart]

7 hours ago, TheBF said:

I am also eyeballing KEYCNT ? and wondering about keeping it on the Rstack to save another variable. 

 

That would be difficult to effect considering the use of 

KEY7   DECT IP                re-execute fbForth's KEY
       B    *NEXT

to re-execute KEY because KEYCNT must persist through all re-entries until it gets reset to -1.

 

...lee

[+TheBF]

Ah. That is a wrinkle.

 

So this not very Forthy but might save memory. 

Build a small stack frame for your variables on the data stack and reference them with indexed addressing and collapse it on the way out?

Not sure if you'd eat more space with code than you do now with variables because indexed addressing eats up extra bytes too.

I find the 9900 does not surrender to optimization without a fight.  

 

 

[+Lee Stewart]

14 hours ago, Lee Stewart said:

Ok...I am gearing up to produce fbForth 2.1. The first thing I am dong is adding auto-repeat to the keyboard.

 

So far, it works! Now, I should modify the 40/80- and 64-column editors to remove their separate key routines.

 

...lee

[+TheBF]

Makes me wonder if I could shoe-horn repeating keys into my kernel. 

[+Lee Stewart]

50 minutes ago, TheBF said:

Makes me wonder if I could shoe-horn repeating keys into my kernel. 

 

Don’t know why not!

 

...lee

[+TheBF]

Well... at the moment I play this game of keeping the thing inside the 8K limit.

Might have to break that or oh... I don't know ... build a cartridge! 

It's on the stack now.

For the moment I am shaming myself with this MachForth compiler. 

 

Oh and I owe you a thank you.

I completely forgot about the COC instruction until I read your code.

[+Lee Stewart]

I now have auto-repeat working for the kernel’s keyboard routine, as well as using it successfully for the 40/80-column editor. This added 34 bytes to bank 1 (removing that same amount from the free space for the return stack in low RAM, but removed 202 bytes from the editor (also in bank 1), netting 168 more bytes in bank 1, which leaves 354 free bytes for mayhem in bank 1.  

 

I will worry about the 64-column editor later because it is not part of the cartridge code.

 

Next, I think I will focus on reworking the FPL to use the console routines for FMUL,FDIV,FADD,FSUB,FCOM,CSN,CFI. Immediately after that, I will need to patch the remaining math routines where they use those same console routines: INT,^,SQR,EXP,EXP10,LOG,LOG10,COS,SIN,TAN,ATN, etc.

 

If anyone would like to try out fbForth 2.1 as it is so far, I will try to get around to posting an alpha copy later today.

 

...lee

[+Lee Stewart]

Before I get down and dirty with the FPL, I decided to add a feature to VOCABULARY that will take the responsibility from the programmer of making the definitions of new vocabularies IMMEDIATE :

HEX
: VOCABULARY   ( --- )  ( IS:<vocabulary name> --- )
   <BUILDS 
\ store precedence bit in NF of newly defined vocabulary
       4000 LATEST +!       \ make immediate
\ initially point vocabulary link to PNF of previous vocabulary
       CURRENT @ 2+ ,
       81A0 ,               \ pseudo-name field
       HERE VOC-LINK @ ,    \ chronological link
       VOC-LINK !           \ update to point at above field
   DOES> CONTEXT !  ;

It did add 8 bytes to bank 0, which now has only 28 bytes left. 

 

...lee

Edited March 9, 2022 by Lee Stewart
correction

[+Lee Stewart]

Here is the first alpha build of fbForth 2.1 (build @) for you to try, along with a minimally updated FBLOCKS (none of the BLOADs will work) :

 

  fbForth210_8.bin  fbForth210_9.bin  fbforth210.rpk  FBLOCKS 

             
...lee

[+Lee Stewart]

DATA[ ... ]DATA in the above alpha release of fbForth 2.1 now can manage the line comment, \ . The three words that can be sprinkled amongst the list of numbers are

• ( )         <----inline comment
• \             <----rest-of-line comment
• -->         <----next block loader (allows for multiblock number arrays)

...lee

[+TheBF]

12 hours ago, Lee Stewart said:

Before I get down and dirty with the FPL, I decided to add a feature to VOCABULARY that will take the responsibility from the programmer of making the definitions of new vocabularies IMMEDIATE :

HEX
: VOCABULARY   ( --- )  ( IS:<vocabulary name> --- )
   <BUILDS 
\ store precedence bit in NF of newly defined vocabulary
       4000 LATEST +!       \ make immediate
\ initially point vocabulary link to PNF of previous vocabulary
       CURRENT @ 2+ ,
       81A0 ,               \ pseudo-name field
       HERE VOC-LINK @ ,    \ chronological link
       VOC-LINK !           \ update to point at above field
   DOES> CONTEXT !  ;

It did add 8 bytes to bank 0, which now has only 28 bytes left. 

 

...lee

I have dim memories of arguments on this matter in 20th century. I can't remember the pros and cons.

I the only negative implication I can think of is that you have to use [COMPILE] if you want to make a word that changes a vocabulary along with other stuff which is not too serious.