[TF, camel, FB Forth fun]

As the year is drawing to a close you might want to know that Forth is more popular that Scheme and in the same league as Haskell and ML, in the year 2023.

 

TIOBE Index - TIOBE

 

Merry Christmas an a Happy New Year to all.

🎅

[Looking for a BASIC speech program featuring joke-telling robots]

LOL. Make we want to write one.  I would be possible with the T/E II cartridge I think.

[TF, camel, FB Forth fun]

2 hours ago, GDMike said:

I just started playing with the 2Mb ramdisk

It is partitioned as 15 segments of 2024 bytes I believe. 

And the labeling of each drive is using a letter at the tail end, as in, DSKG, DSKH, etc..

Turboforth doesn't seem to like,

S" DSKN.BLOCKS" USE

 

Neither does my SNP filing

But both like numbers 1-3

As in DSK3.

 

BUT the editor/ assembler has no issues loading raw files from the "lettered" drives at all.

Any ideas?

Is the word USE in the kernel or is it loaded from disk at startup?

If it's source code we can change it on the disk.

Or we might have to find out what it's doing and write a new one.

 

[TF, camel, FB Forth fun]

9 hours ago, Lee Stewart said:

 

Undoubtedly a victim of “cut and paste”, but the line I bracketed with “( *** )” should read

 

        WHILE ( R@=char)

 

...lee

Yup. Comment creep.

Thanks Lee.

[vi99]

@Vorticon here is the last version of the RS232 version.

 

I have one more bug to find on the VDP version and then I want build the RS232 version with this new code base because I think it's better. 

 

 

[TF, camel, FB Forth fun]

4 minutes ago, Switch1995 said:

Thanks @TheBF!!  Looking forward to trying this out over the holidays.  Appreciate it 

My pleasure.

Note: I labeled left$ and right$ backwards in the first post.  I have edited them.

[vi99]

8 hours ago, Vorticon said:

Getting there  What is the default baud rate? Can one pick the baud rate at program initiation or set a permanent default? 

This version is only for VDP/F18.  I am tight on space as it is currently built so I don't think I can fit RS232 and VDP in the same program without blowing it out into SAMS.

I want a solid editor before I go to SAMS.

 

The latest version for RS232 is autobaud.  It sets BPS after your first enter key is pressed. 

 

[TF, camel, FB Forth fun]

And a bit more stack string magic for TurbForth

 

SKIP and SCAN come from the intel x86 Forth systems where they used intel strings instructions.

They turned out to be very handy and although not part of the ANS/ISO Standard, most modern systems have them these days. 

On Camel99 they are written in Forth Assembler for speed, but they still perform well in Forth because of the power of stack strings.  

 

\ These look funny because they use WHILE twice.
\ This structure let's us jump out of loops like we do in BASIC and Assembler
\ THEN resolves the 1st WHILE and REPEAT resolves the 2nd WHILE 

\ scan stack string for char. Return a string that starts with CHAR
: SCAN (  adr len char -- adr' len')
        >R                 \ remember char
        BEGIN
          DUP
        WHILE ( len<>0)
          OVER C@ R@ <>    \ test 1st char
        WHILE ( R@<>char)
            1 /STRING      \ cut off 1st char
        REPEAT
        THEN
        R> DROP            \ Rdrop char
;

: SKIP (  adr len char -- adr' len')
        >R     \ remember char
        BEGIN
          DUP
        WHILE ( len<>0)
          OVER C@ R@ =    \ test 1st char
        WHILE ( R@=char)
            1 /STRING      \ cut off 1st char
        REPEAT
        THEN
        R> DROP            \ Rdrop char
;

 

Test code 

\ String literal in colon def. returns a stack string
: A$ ( -- addr len) S" ***********Clean this up!" ;


A$  CR TYPE
\ skip the leading stars in the string, return remaining text
A$  ASCII * SKIP CR TYPE

: B$ S" I wonder where my * went?" ;

\ find * in B$ and return the string from * to end
B$ ASCII * SCAN CR TYPE

 

One my favourites.

: VALIDATE ( char addr len -- ?) ROT SCAN NIP 0<> ;
: PUNCTUATION? ( char -- ?)  S" !@#$%^&,./?';:|[]{}" VALIDATE ;

\ test code
 ASCII : PUNCTUATION? .

 

[TF, camel, FB Forth fun]

I promised @Switch1995 that I would demo some simple words to make strings a little easier to use without a big library.

 

The underlying assumptions here are strings exist on the data stack as a pair: (address, length) I call these a "stack string" 

They are stored in memory as a byte counted string, where the 1st byte holds the length. (max size=255 bytes)

To store a stack string to memory we use PLACE. 

To convert a stored string from memory back to a "stack string" we use COUNT. 

Albert VanderHorst, of CIFORTH calls the $@ (string fetch)  That is a good name in this case. 

 

If you prefer $@ might want to call PLACE  $! .  But PLACE has become the un-official "standard" name for it. 

 

The interesting thing about stack strings is that if you make string functions that leave a stack string on the stack

you don't need a "string stack" where you copy things back and forth from one string to another.

You only need to copy back to memory when you want to retain the result for future use.

 

Here is some code that runs on TurboForth.

\ amazingly versatile string cutter
: /STRING ( caddr1 u1 n - caddr2 u2 ) TUCK - >R + R> ;

\ "place" a string into memory as a byte counted string
: PLACE       ( addr n dst$ -- ) 2DUP C! 1+ SWAP CMOVE ;

\ increment the byte at addr by c
: C+!         ( c addr -- ) DUP C@ ROT + $00FF AND SWAP C! ;

\ append the string addr,n onto the byte counted string $
: +PLACE      ( addr n $addr -- ) 2DUP >R >R  COUNT + SWAP CMOVE  R> R> C+! ;

\ append a single char onto the byte counted string
: APPEND-CHAR ( char $addr -- )  DUP >R COUNT DUP 1+ R> C! + C! ;

\ Since strings live on the stack as addr,len, DUP is all we need
: LEN      ( addr len -- addr len c ) DUP ;

\ emulating TI BASIC SEG$ is this simple
: SEG$     ( addr len n1 n2 -- addr len) >R /STRING  R> NIP ;

 

And if you prefer MS BASIC LEFT$ and RIGHT$ ...

Edit: Oops  I named these backwards the first time. 

: RIGHT$   ( addr len n -- addr len) /STRING ;  \ 🙂
: LEFT$  ( addr len n -- addr len) NIP ;      \ :-)   

 

Example code

\ creating strings is easy
CREATE A$    80 ALLOT
CREATE B$    80 ALLOT
CREATE C$    80 ALLOT

\ assign text to strings with PLACE
S" TI-99 is the ideal gift" A$ PLACE
S" , for the Christmas season" B$ PLACE

\ use PAD as temp storage and append A$ and B$
\ without changing either A$ or B$
A$ COUNT PAD PLACE   B$ COUNT  PAD +PLACE

\ Type the new combined string
PAD COUNT CR TYPE

 

More to come...

[vi99]

So once I tried to use V .92 it was pretty sad. 

 

This version is much better.

1. line 24 reports file/editor information more consistently
2. r command (read file) works for insert a file into a file at the cursor. 
3. dd dw yy report a text message more like vim. 
4. Overall seems more stable. 
5. Found a stack error in my putch code that I compensated for in the wrong place. Fixed. 

Let me know.

 

I think I can see my way clear now to using this code base with VT100 codes by consolidating the VDP code into a file like the VT100 screen control.

 

 

Known bug:  When I try pasting a large file into the editor it hangs after a few lines. Don't have a reason for that yet. 

 

VI99II.93.zip

[Happy Holidays in FORTH!]

4 hours ago, Switch1995 said:

I've just started learning FORTH this year and could be wrong, but it seems like using S" TYPE gives more flexibility than ."  and so I'm trying to get into the habit of "always" using it for strings.   For example:  

 

: test S" Hello World!"

;

 

test 2DUP TYPE TYPE

 

btw, In my top post, I neglected to thank @Willsy and @Lee Stewart for their fantastic FORTH products and, more importantly, taking the time to document and teach those that follow.

Congratulations on jumping into this strange world. 

Lee and Willsy have done a superb job of documenting their systems.

(I have been focused on trying to learn compiler design stuff so my docs are bit stale compared to the current system) 

 

In Forth we are free to use words as we see fit. So there is nothing wrong with what you coded.

 

Since you are in a learning mode I will share some stuff I have learned over the years.

 

In BASIC we don't think about this much but there are string variables and also string "literals"

 

10 PRINT "Hello World!" 

creates a string literal in BASIC. 

 

Your definition of TEST above also creates a string literal with S" . 

In both examples it is assumed that you never want to change the string in a running program.

(of course you could change it with Forth but you might corrupt the dictionary if you try it) 

 

Here is a simple definition of ."  in  Forth 

 

: ."  (  ccc" -- )  [COMPILE] S"    COMPILE TYPE ; IMMEDIATE

You can see that it is actually just replacing the word ."  with S" and TYPE.  

 

I you want to explore string variables you can use Willsy's string library. It lets you do what BASIC can do with strings.

However in my experience after having made these kind of libraries myself, most of the time they are not needed.

A few much simpler words is all we need for normal programs.

I will post some options over on the Fun with Forth thread. 

 

 

 

[RXB 2024 update]

That's a big improvement Rich. Nice work.

 

So I would guess that the big difference in the code above is the CHAR() function re-write?

 

[Happy Holidays in FORTH!]

Wow it's great to see someone else working with Forth. 

This was nicely factored. 

 

I have a question. Do you have a reason for not using  ."   to type text?

 

It would look like this

: news6 ( -- addr len )
0 15 GOTOXY
   ." NEWS - HAPPY HOLIDAYS TO ALL        " 
CR
CR ." THE 99ERS OUT THERE!                " 
CR
CR ." WISHING YOU AND YOURS A             " 
CR
CR ." PEACEFUL AND JOYOUS SEASON          " 
CR
;

 

In many Forth systems it compiles the same code as you wrote ( S" and TYPE)  but it looks a little cleaner. 

 

[vi99]

Oops!  I found an error in my LIST code.

It fails to display line 24 when the screen refreshes completely when loading a new file or page-up/page-down.

(I think it worked on Terra Term OK, but I will have to test that as well)

 

Very sorry.  Here is a corrected version (0.93)

 

I really suck at quality control without a boss.  

 

PS. Send in your bugs and I will do my best to clean them up.

 

Standby.. fixed another thing.

 

[vi99]

Now if I was really smart, I would figure out how to compile this with my Forth re-compiler which removes all the text headers and would give back about 30% of the space for more features.

hmm... that might take some work. 😊

 

[vi99]

So I finally got my head together to port the TTY version backwards onto the F18 80 column functionality.

 

I found and fixed a bug that was in the TTY version where the editor cursor  lost sync with the screen position. 

 

Changes:

1.  arrow keys and pageup/pagedown keys added to the valid key strokes for the 21st century VI users.
2. When you enter editing mode the cursor changes from and underline to tall block
3. I think this was missing in 1.43 of the f18 version.  dw ( delete word/words) 
4. Next word (w) and previous word (b) commands

 

Future:

Now that this seems pretty stable, I have a search utility in development. It's pretty close. So that will add the / command.

Replace might be a stretch but I will give it a try.

 

The zip file just has the 3 binary program files  (VI99II) and the manpage. 

 

Let me know what I broke.   I have not spent enough time testing everything myself. 

 

 

 

 

[vi99]

And that's the rest of the story. 

 

Thanks!

[GCC for the TI]

It's really cool to see the compiler output. 

How hard will it be to convince the compiler to use: 

 

BL @raw_vdpmemcpy

 

 

[Toward a Better (and Better-Documented) DSRLNK]

2 hours ago, Lee Stewart said:

 Is there ever a level-3 call that does not have a ‘.’ following the device name?

RS232 ? 

This is what I see on my hardware.

2 hours ago, Lee Stewart said:

 

The above scenario implies that the initial call to open a file would be

       BLWP @DSRLNK
       DATA 8

 

and subsequent calls for the opened file might be just

       BLWP @DSRLNK

 

Of course, I could just use the normal call with the DATA directive for both contingencies, which would make it unnecessary to answer the above question. I would still like to know, however.

 

...lee

 

In the 2nd example would you not have to specify a "0" or some such parameter to indicate that the call does not search for a device? 

 

(I often wonder about passing parameters in the space after the call. I get that it make sense in Assembler but I wonder if it should be done another way for Forth or C) ?

 

 

[vi99]

Update on VI99 II for F18 80 columns.

I have compiled the code for the RS232 version using function names from the VT100 library that run VDP code.

It starts and much of it is working now. My emulation of the VT100 scrollup and scrolldown  need a lot of work 

and a few other bugs but I think the potential for this version is to be much better than the previous

version for F18.

 

On the mend but still lacking full energy.  

 

 

[vi99]

On 11/27/2023 at 5:37 PM, dhe said:

 

Any chance these could be mapped to the arrow keys via Classic99?

Even on PC's running Linux, I never use those...

Oh man. I thought you were an Orthodox user.  

 

I will put this on the list. 

I might need to make a keymap file that can be loaded on boot up to address all the user requests out there.  

 

[vi99]

15 hours ago, dhe said:

It's my understanding, VI was a modal editor in order to make it easier to port to multiple terminals, and to make it responsive on slow terminal connection (?).

 

Would it be possible to re-factor the code and create an abstraction layer, so i/o could be done either via a keyboard/vdp or a terminal?

 

Also, per your question what would be nice to have, I didn't see search and replace mentioned in the docs. I know things like regex is hard, but maybe a simple /string/replacement string/ ?

I believe you are correct about the modal "model"  

There is also some history written about it being built on top of some kind of IBM line editor that was not very nice and VI was designed to make the line editing look more WYSIWYG.

 

You are reading my mind about how to do the port from the RS232 to F18.  In fact Forth programs are just one abstraction layer upon abstraction layer.

You can overwrite any function with a new one of the same name. The language is a chameleon.

 

For example in the regular Camel99 Forth kernel the ISO Forth screen I/O words call a bunch of VDP assembler code.

In the RS232 version of Camel99 Forth the screen control words emit VT100 escape strings. But they both can compile standard ISO programs.

 

In theory... (he said nervously)  I should be able to recompile the RS232 version on the VDP kernel and most things will just work. 

hahahhahaha

 

I know that I made use of some VT100 features in the RS232 version for scrolling part of the screen that I might need to translate to VDP so there will be that extra work.

Just starting to feel human again today so I might start getting some files organized.

 

 

[vi99]

Oh Yes for the VDP/F18 version Classic99 is how I do things.

[Toward a Better (and Better-Documented) DSRLNK]

Thanks for the platitudes.  

 

Ah. Other controllers. Ok. I have no knowledge of them at all. I guess what I have is probably the safest albeit not the most efficient.

[vi99]

Those like excellent bug reports.  

 

I have decided that since I spent so much time on the RS232 version I am going to migrate that code base back to use the VDP display.

I learned a lot making the second version as one always does.

 

I will be starting on that this week as I can. Just recovering from a nasty virus. I am not 100% yet.