TheBF

Ok from what I read the EP-44 can work like a terminal. So in theory you could connect it to the VI-99 shell and pull a directory or delete a file and that's about it for now. If you enter the vi99 editor it assumes an 80x24 screen so that would not work so well I suspect. I think I would need to make a different kind of "line" editor to work with EP-44 where you list the file, select a line number, then edit that one line and save it back. I never used it but I think the EDLIN program in DOS worked like this.

So here is what I suppose is best called an Alpha version. bfox9900/VI99TTY: VI style editor over RS232 for TI-99 computer (github.com) The bin folder has the program files but I attached them here as well. Run with E/A 5 VI99TTY1 If you put VIMANPAGE on the program disk, the help command will let you view it in read-only mode. Set your terminal emulator to: 19200, 8,n,1 VT100 emulation. I have used Putty and Teraterm There be warts here so let me know what you find. VI99TTY1 VI99TTY2 VI99TTY3 VIMANPAGE

I have just built a repository and I am getting the binary files from my TI just now. I am not sure if VI99 is going to help you there. It assumes the file is loaded into low RAM on the TI-99. The serial port is used to control the TI-99 either in the shell section or the editor section. It is not a terminal emulator but rather it turns the TI-99 into "mini-computer" type thing, that requires an external terminal emulator I am at a loss as to what we can do with a connection between VI99 and EP-44. I will do some reading on the EP-44. Maybe we need a module that can accept a file from EP-44 and save it to a DV80 FILE. ?? I have something like that in my library.

Yes it's important that REPEAT behave as expected even though it has secret abilities under the hood. By Jove, I think you've got it.

And one more thing... You can speed up 1 /STRING with this simple definition. : 1/STRING 1- SWAP 1+ SWAP ; I considered calling it CIRCUMCISE but I thought better of it.

I found somebody who says you can learn Forth in just 7 steps. (It took me more) Forth in 7 easy steps • JeeLabs

I realized in the NEXTWORD definition above, I forgot to give everyone a version of SKIP and SCAN with the magic word /STRING. These ones work in TurboForth. Now that Lee is adding these strange multiple While statements to FbForth, he can use this code too along with his fancy new REPEAT word. -ROT is a code word but ROT ROT will do the same thing. : /STRING ( a u n -- a+n u-n) \ trim string ROT OVER + -ROT - ; : 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 ; And of course SKIP is very similar : 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 ; /STRING should also be a code word. It's waaaay more efficient because the 9900 can reach into the stack memory directly. Here is the my version but it just needs a few tweaks to work in the other systems. CODE /STRING ( c-addr1 u1 n -- c-addr2 u2 ) TOS *SP SUB, TOS 2 (SP) ADD, TOS POP, NEXT, ENDCODE [THEN]

The AI instruction is always there to temp us.

I thought that might be the case. Reducing all the control flow stuff down to bare bones seems to be the only way to get that simplicity to flow through to the rest of the pyramid. The only alternative I can think of is implementing a separate control flow stack and that's just another huge change. Your ALC will do the job just fine.

BTW, did you get a chance to compare the speed of the new code versus the old version?

As always you write some very fine ALC. I think it could also be done in Forth using an idea from ENDCASE, which compiles a prerequisite number of THEN (ENDIF) tokens to match the OF tokens. So in theory we could do: : REPEAT [COMPILE] AGAIN BEGIN ?DUP WHILE [COMPILE] ENDIF REPEAT ; IMMEDIATE Which would be even smaller by maybe 1/2 or so. Not sure if that would jibe with your existing AGAIN and ENDIF definitions. If they have compile time match detection it might not work this simply but however you implement ENDCASE should give the necessary recipe, I think. Just a thought.

I like the idea of making it look cleaner. I am not fond of altering a standard word too much. Since FbForth has many words specific to TI-99 already, an alternative would be to keep REPEAT and add a word that does this thing specifically. REPEATS maybe ?? As I write this I think you could get away with: : REPEATS ?COMP [COMPILE] REPEAT [COMPILE] ENDIF ; IMMEDIATE

Changed the line redraw function to only write the "right side" of the buffer string on refresh. This is probably as good as I can make it for 1200 baud but it also makes things better at all baud rates. Thanks @Vorticon for forcing me to test at slow speed. However inserting text into a line is still painful because more of the line is redrawn each time. But... it works. vi99 tty at 1200 baud improved.mp4

I was looking at code from the Legend of Tilda and saw something I had seen before. I found this in my library folder. It reads the CRU bit on the 9901 chip to test for vertical interval synchronization. Don't know it is any better or not. My version PUSHs and POPs R12 onto the return stack so it is safe to use in the middle of other I/O operations. Also I added an extra line from the legend of Tilda version to clear the CRU bit before testing bit 2. That could be removed but if you want to keep it here are the definitions for RPUSH, and RPOP, which should work in TForth as well. ( might need to change *RP and *RP+ ?? ) : RPUSH, ( src -- ) RP DECT, ( src) *RP MOV, ; \ compiles 4 bytes : RPOP, ( dst -- ) *RP+ SWAP MOV, ; \ compiles 2 bytes \ vsync.fth adapted from code by @PeteE on Atariage.com 12JUL2022 NEEDS MOV, FROM DSK1.LOWTOOLS HEX 8802 CONSTANT VDPSTA CODE VSYNC ( -- ) R12 RPUSH, VDPSTA @@ R12 MOVB, \ Clear interrupt flag manually R12 CLR, \ 9901 CRU base Address= 0 BEGIN, 2 TB, \ Test CRU bit 2 - VDP INT EQ UNTIL, \ Loop until set VDPSTA @@ R12 MOVB, \ Clear interrupt flag manually since we polled CRU R12 RPOP, NEXT, ENDCODE DETACH \ removes the assembler from Low RAM

Well that was interesting. I can see that I have to re-think where I place the "RELINE" function. Drawing the line every time through the editing loop is not practical with a low speed connection. I think I can improve that. @VORTICON what are you planning to connect the TI to at 1200bps? 1854245734_VI99TTYOVER1200bps.mp4

Yes. The port is configurable. I have defined BA=9600 BA=4800 BA=19200 . I will add a word BA=1200. Then I will try it and post a video for you to see. Listing a page might be painful but hey we cut our teeth on TI-BASIC. I think you are making me add a config file to set the baud rate at startup. If only I could get that autobaud code to work ....

Yes if you are moving fast you would need to synchronize your code to the frame rate of the video. Lee posted this code few years back in another thread. Quote: Here is the ALC [corrected] to poll for the next VDP interrupt in TurboForth (WI , say), which must have the TMS9900 Assembler (block 9) loaded: \ Wait for VDP Interrupt ASM: WI ( -- ) R1 $8000 LI, \ VDP interrupt mask $8802 @@ R2 MOVB, \ reset VDP status byte BEGIN, $8802 @@ R2 MOVB, \ get VDP status byte R1 R2 COC, \ VDP interrupt? EQ UNTIL, \ loop if not ;ASM and, without the TMS9900 Assembler [corrected]: \ Wait for VDP Interrupt HEX CODE: WI ( -- ) 0201 8000 D0A0 8802 D0A0 8802 2081 16FC ;CODE ...lee

So... does that mean you could put all eight bytes of the float onto the data stack and point R7 to the appropriate end of the data? If you could, then the FAC would become the top of the floating point stack, cached, ie: the way I do math in Camel Forth. The data stack or another stack of your creation could be the "next on stack" for FP routines. Things that I wonder about...

So where will ARG come from in your new version? The Forth DATA stack perhaps?

Since this topic is about Forth "fun" I thought I would share some stuff I am having "fun" with. I wanted to add the "next word/previous word" function to VI99. Years ago I was quite confused/indignant about the new Forth way of handling strings as an (address, length) pair on the data stack. Seemed too complicated managing two items for every string. I was pretty sure that my byte counted strings were good enough for any purpose under the sun. Now I am getting why some senior Forth people changed things. We all have -TRAILING to remove trailing spaces from a string and return the stack string pair that defines the new string. For the editor I took a page from this idea and made: : LASTCHAR ( addr len -- char) 2DUP + 1- C@ ; : -ASCII ( addr len -- addr' len') BEGIN DUP WHILE LASTCHAR BL <> WHILE 1- 0 MAX REPEAT THEN ; With these tools the PREVWORD definition is simple. : PREVWORD -TRAILING -ASCII ; Where -TRAILING removes any "trailing blanks" from the string and then -ASCII scans backwards past anything that is NOT a blank character. In the case of PREVWORD the resulting string length is the same as the screen column so we just need this code to set the editor column. ( addr len) NIP COL ! Although not standard words most modern Forth systems have SKIP and SCAN which search a string from start to end. I think these first showed up in FPC for DOS by Tom Zimmer and used the intel x86 string scanning instructions. They stuck with the community. Like -TRAILING, SKIP and SCAN return a new address, length pair string. This means they can eat their own output. To get a string that starts with the next word we just need this: : NEXTWORD BL SCAN BL SKIP ; Where BL SCAN searches forward for the next occurrence of a "blank" (old term for space character) Then BL SKIP skips past "blank" characters until it finds a non-blank character ie: a word. Getting the editor column value is a bit more complicated because NEXTWORD it is cutting off the front of the string word by word. So we need to subtract the new length from the full length of original line in the editor to compute the COL value. There is a bit more to the final code because at the end of a line we need to go up or go down in the file depending on the direction. And VI editors can be given a numeric argument and so they can go ahead or back any number of words. I will be putting up the code on Github this week so you will just have to wait until then for the full story but here is a peek. : GOFORWARD DUP 0= \ 0 means we are at end of line IF 2DROP GODOWN COL OFF ELINE# SEEKTO END NEXTWORD ; : CMD-w \ next word command ELINE# SEEKTO RIGHTSIDE ARGS ?DO GOFORWARD LOOP NIP SEEK$ @ LEN SWAP - 0 WIDTH CLIP COL ! ; : GOBACK ( addr len -- addr' len') DUP 1 < \ test for beginning of line IF 2DROP \ don't need this string now GOUP \ go up one line ELINE# SEEKTO \ re-seek to the new line DUP COL ! END PREVWORD ; : CMD-b \ previous word command ELINE# SEEKTO LEFTSIDE 1- \ start scan at the cursor-1 ARGS ?DO GOBACK LOOP NIP COL ! ;

It sounds like you are comfortable with music notation so this might be of use. I have not tried it yet but it looks very nice. (I have used Sibelius for well over a decade but I might switch to this one based on what I see here) Free music composition and notation software | MuseScore

Thanks. I am just adding the 'w' and 'b' commands now to skip along the text word by word. After these and little more testing I can release a Beta version for people to find the real problems. I have considered an expanded version using SAMS. The challenge there is the current memory organization assumes contiguos memory. The file is read into memory as byte counted strings end-to-end. It's pretty fast to skip along the byte counts like a poor-mans linked list. I have functions called INSERTLN, DELETELN and REPLACELN. Moving that to "block" oriented SAMS memory might mean requiring a call to a virtualization routine on every byte access which would be much slower. I could also just go back to chopping SAMS up into 80 byte records which would be the fastest. (?) Maybe that's still the best way to handle SAMS for editing, even though it wastes a lot of space. ?? What data structure do you prefer for the memory buffer in SAMS?

Making some progress. The editor itself seems pretty solid. A few more features to add before I release it but here is a video that demonstrates how it looks and feels with an audio commentary explaining what I am doing at the keyboard. Note: The commentator made a confusing statement. (I gotta hire better talent) CPU RAM is used to hold the file data. VDP RAM is used for the cut/paste buffer.

This sounds like it will fly. I am looking forward to seeing your work. I would have to re-compile my kernel with user variables in expansion RAM to use the code, but that's a possibility I think.

I accidently stumbled across this Forth 2020 site and found this 1968 listing of Forth by Chuck Moore. Wonderful to see it there. Forth2020 - Forth 1968Listing There is also a bunch of other neat things on the site for the Forth aficionado, including this interview with Chuck that really gives some insight into how he thinks. Forth2020 - About Forth