Jump to content
IGNORED

vi99


TheBF

Recommended Posts

On 10/4/2022 at 9:35 AM, TheBF said:

 vi99 Tip

 

Due the clever design of Classic99 you can bring text files from vi99 to your PC with:

 

:w clip

 

Then pasted the windows clipboard to wherever you want it.

Remember you can also write directly to text files... DSK1.?W.FILENAME.TXT will create a Windows text file so long as DSK1 is a FIAD folder. The .txt extension is important if you want Classic99 to read it back, but the ?W forces the mode.

Admittedly I often use clip to notepad too, but there are cases where direct may be faster ;)

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 2 months later...

My apologies for the long time to fix this.

I get distracted easily by things that peak my interest like almost everything.

 

I found a serious problem with some of the routines in the previous version.

In some conditions I was saving the cursor shape on the return stack so it could be changed for the new editing mode.

If you exited normally the cursor was popped and all was well.

But in my cleverness I provided a fast exit out if there was an error condition, but didn't cleanup the cursor character. Oopsie! 

 

This editor also is shift for me in that the VDP screen is the actual text editing buffer. (my choice)

It means that I don't have to copy anything to the text save buffer in memory until you complete editing a line.

That's is foreign to me from other editors I have written and so I found a case where I was trying to do both at the same time when pasting a line from clip buffer.

 

I think this version is more reliable now.

It has an ls-l command now so you can see file types and sector sizes.

ls and ls-l  default to the start up DSK which is retained in HOME$. 

I have not made a non-Forth syntax way to change HOME$ yet.

 

If you really want to changed it use: (mind all the spaces and upper "caseness")

S" DSK2." HOME$ PLACE

 

Merry Christmas to anyone who is trying to use vi99 and special thanks to @dhe who seems to be the biggest fan of VI99. :)

 

Things I can improve:

  1. Screen refresh is line by line a so very ugly 
  2. make vi command use HOME$ as default path (should that be done?)
  3. Load editor into low ram leaving ~15K for text buffer (currently only 8K) 
  4. Add more commands
    1. Which ones do you miss the most? 

I hope I didn't break more that I fixed...

 

 

VI9980-1.41.ZIP

  • Like 4
Link to comment
Share on other sites

That’s some nice progress there, I like the use of $HOME and the ls command.

Have the same feeling with my progress on Stevie.

It has been slow due to changes at work and writing Stevie in assembly sure doesn’t help.

But am also to release a new version in the next days (better menu system, goto line functionality, "uncrunch" TI Basic program + small changes)

 

Thinking about it, I might steal the idea with the environment variables for a future version. Hope you don’t mind 😃

Also thought about integrating a forth interpreter and  do some of the “high-level” stuff there. But that would really

be a long-term goal.

 

If I may make a suggestion, and it’s not directly an editor thing. But perhaps you could add the capability to load a FG99 cartridge from inside the editor.

That way you can jump there from the editor. (that something I’m working on in stevie as well, but not for this release). With SAMS in place I can even return from a cartridge to Stevie and resume work in the editor without loading anything in memory, because it’s all just there. You just have to make sure that you switch SAMS pages upon program exit and switch them back in when you resume work)

 

 

Edited by retroclouds
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

6 hours ago, retroclouds said:

That’s some nice progress there, I like the use of $HOME and the ls command.

Have the same feeling with my progress on Stevie.

It has been slow due to changes at work and writing Stevie in assembly sure doesn’t help.

But am also to release a new version in the next days (better menu system, goto line functionality, "uncrunch" TI Basic program + small changes)

 

Thinking about it, I might steal the idea with the environment variables for a future version. Hope you don’t mind 😃

Also thought about integrating a forth interpreter and  do some of the “high-level” stuff there. But that would really

be a long-term goal.

 

If I may make a suggestion, and it’s not directly an editor thing. But perhaps you could add the capability to load a FG99 cartridge from inside the editor.

That way you can jump there from the editor. (that something I’m working on in stevie as well, but not for this release). With SAMS in place I can even return from a cartridge to Stevie and resume work in the editor without loading anything in memory, because it’s all just there. You just have to make sure that you switch SAMS pages upon program exit and switch them back in when you resume work)

 

 

Thanks for the encouragement. You can use any idea from my code that suits your needs. It's all public domain as far as I'm concerned.

I added on variable for convenience and now realize I should read an init file on startup to allow personalizing. This a case where having the interpreter embedded makes it much simpler.

 

These are good suggestions.

This version of vi99 is expansion RAM only. I have some preliminary code that can swap out the entire memory map into SAMS so that sounds like what you are talking about.

I will need some "personal" development to understand using FG99. I should probably buy one first. :) 

When that time comes I will reach out to learn what you are doing.

 

 

 

 

 

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

I have been noodling on this vi99 editor over the holidays.  This thing is a very deep rabbit hole!. :) 

I will never be able to emulate all the stuff that vi does but I got a bit closer. 

 

I figured out how to add the numeric argument to the system so you can do commands like 5dd and delete 5 lines,  or d4w to delete 4 words.

Still need to add that to the y command to copy lines.  It's not a speed demon doing this, but it is working.

 

There is also a limit at the moment of about 90 lines in the current clipboard buffer in VDP RAM because it is a fixed record size system so I will have to fix that with a different data structure. Also because there is only one clipboard buffer I had to add a ^K command to "kill" the buffer contents when you need to. No standard vi. Sorry.

The number of lines in clipboard is also displayed on the bottom line. I keep breaking the sacred tradition. Such heresy. 

 

I decided to patch the Forth repl with a different loop that looks more like a linux prompt that shows the current path.

 

And now you don't need to use the disk number with the file name. The current path is pre-pended to the filename if you don't add a dsk?. in the text. 

 

New commands 

  • view  <filename>  lets you look at files in read only mode  
  • cd     "change disk" :)  
  • -R      sets read only mode. BUT it is a Forth word so it goes before the vi command.
  • -M      sets modify mode. Same rule as -R. 
  • ^Z     exit editor to the shell

Fixed commands

  • G    goes to end of file  9G goes to line 9

 

I posted a quick video of what it looks like now. 

I hope to get a new version of the program on here soon. 

 

 

 

 

 

 

 

 

 

 

 

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

Awesome work! This is progressing very nicely indeed! I love the fact that the text color changes depending on whether one is in view or edit/insert mode, not to mention the shell feature. 

The text buffer size limitation is definitely something that will need to be ironed out at some point as 60 lines is not nearly enough for larger projects. By the way how large of a file can the editor handle? Are you making use of the SAMS by any chance? 

  • Like 1
Link to comment
Share on other sites

3 hours ago, Vorticon said:

Awesome work! This is progressing very nicely indeed! I love the fact that the text color changes depending on whether one is in view or edit/insert mode, not to mention the shell feature. 

The text buffer size limitation is definitely something that will need to be ironed out at some point as 60 lines is not nearly enough for larger projects. By the way how large of a file can the editor handle? Are you making use of the SAMS by any chance? 

Thanks. 

Not using SAMS at the moment so memory is tight.  I started this thinking it would be a super tiny editor.  Was I wrong. It is now a ~18.K image.

The largest file is 8K because I used low RAM  for the text. It is kept as byte counted strings, packed end to end, so it's pretty tightly held. Still that would be only ~200 lines of code without many comments. 

I should be able to do something different in VDP RAM with the clipboard, but I might need a double linked list because I use it like a stack of strings.

We shall see. 

 

The way the memory is storage is being used in this version will probably have to change if I go to SAMS. 

I need to do some testing on what happens if every byte read/write goes through virtualization translator.

It could be way too slow.

  • Like 2
Link to comment
Share on other sites

I forgot mention that I finally have a rudimentary 1 level undo.  I think that was all you got with the original vi as well.

Just like 1976!

It's better than nothing and with a couple more line buffers it could be three levels deep!

 

  • Like 5
Link to comment
Share on other sites

  • 3 weeks later...

OK right out of the gate I need to say there are some things that Forth makes so easy and then there are times... 

I made a lot of changes to the VI99 code and got myself down a rabbit hole or two mostly around keeping track of inserting and deleting counted strings.

Fortunately I figured it out or I might have turned to drugs. :) 

 

The copy paste feature now can handle more than the contents of the primary editing buffer using all the VDP RAM from >0C00 up to about >3700

I had to create an pointer stack in High VDP RAM that grows down and holds the text string pointers, that are in low VDP RAM and grow upwards.

If you put more than about 8100 bytes of text in the clipboard or there-about, it's going to blow up. You have been warned.

Also copying and pasting is pretty glacial. I didn't do any optimizing yet and lines update the screen while shuttling those damned counted strings back and forth.

 

Changes:

I also added an rm command with an "Are you sure?" check.  It doesn't work on Classic99 but "should" work on real hardware. (let me know. I don't have F18) 

Added dw (delete word) command and it takes a numeric arg. (does not save the deletion but you get one UNDO) 

Also all the cursor keys take a numeric argument (ex: 12j  moves left 12 chars after the cursor) 

The default path is set from the boot disk you use. This disk is automatically appended to filenames that have no '.' character. 

 

The Zip file contains the 3 binary files. Start the program with DSK?.VI9980

The updated vimanpage file is included so you can see what works now.

 

For the VI fans out there give it a good beat-up and let me know what you would like fixed or improved.

I try to find problems but it's hard to catch everything. 

 

I also need to ditch the ROM font. Any suggestions for a font that would look better in 80 columns? 

 

Source code for the brave hearts among us is here:

VI99/src at main · ForthHub/VI99 · GitHub

 

EDIT:  My humble apologies. V1.43d has a big bug in the pasting mechanism. 

Look down the post for the repaired version. 

 

 

image.png.1877d660ab8ca6037da056a6e2ab32f8.png

 

 

Edited by TheBF
Removed the buggy version
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

8 hours ago, TheBF said:

I also added an rm command with an "Are you sure?" check.  It doesn't work on Classic99 but "should" work on real hardware. (let me know. I don't have F18) 

Remember you can test such things using the TI disk controller emulation. It's only the Classic99 DSR that disables delete. :)

 

Link to comment
Share on other sites

10 hours ago, TheBF said:

I also need to ditch the ROM font. Any suggestions for a font that would look better in 80 columns?

 

Here are two font possibilities:

 

CHAR@1     CHARA1

 

The first is from Funnel Web, I think. It has true descenders and a '0' that is clearly different from capital 'O'. It also is 2 KiB in size (256 chars) with the PC box-drawing characters in the upper 128 chars.

 

The second is from TI Writer (Tony Knerr’s @Gazoo’s favorite font)—also with true descenders and a distinct ‘0’, but just 128 chars.

 

The first 6 bytes are E/A-SAVE style, i.e., not part of the font. I have them with those 6 bytes removed (for fbForth) and the last char (127 or 255) fleshed out, if you like.

 

...lee

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 1/24/2023 at 9:58 AM, Lee Stewart said:

 

Here are two font possibilities:

 

CHAR@1 2.13 kB · 3 downloads       CHARA1 1.13 kB · 4 downloads

 

The first is from Funnel Web, I think. It has true descenders and a '0' that is clearly different from capital 'O'. It also is 2 KiB in size (256 chars) with the PC box-drawing characters in the upper 128 chars.

 

The second is from TI Writer (Tony Knerr’s @Gazoo’s favorite font)—also with true descenders and a distinct ‘0’, but just 128 chars.

 

The first 6 bytes are E/A-SAVE style, i.e., not part of the font. I have them with those 6 bytes removed (for fbForth) and the last char (127 or 255) fleshed out, if you like.

 

...lee

@Lee Stewart I can load this data but my font loader assumes the pattern table is at >800 for ascii char 0.

These files seem to make a different assumption because I get random shapes.

What is the first character defined in these files?

Link to comment
Share on other sites

7 hours ago, TheBF said:

What is the first character defined in these files?

 

The first character is ASCII 0. If you are doing a DSR LOAD (opcode 5), you would need to load 6 bytes ahead of >0800. That is why I stripped those bytes out for fbForth. Here they are so you can load them at >0800 (or wherever ASCII 0 starts):

 

CHAR@1FBF     CHARA1FBF

 

...lee

  • Like 2
Link to comment
Share on other sites

23 minutes ago, Lee Stewart said:

 

The first character is ASCII 0. If you are doing a DSR LOAD (opcode 5), you would need to load 6 bytes ahead of >0800. That is why I stripped those bytes out for fbForth. Here they are so you can load them at >0800 (or wherever ASCII 0 starts):

 

...lee

OK. I didn't understand the implication before.

Thanks for the new files.

  • Like 2
Link to comment
Share on other sites

So I dug into this project for the last week or so.  I went back and forth between VIM on my Mac and VI99 to try and get the features that I have, working like the real thing.

I realize that this has been pretty painful for "dyed in the wool" vi users like @dhe so I hope this helps absolve me of my past sins. 

Part of the problem is that I am not a VI user regularly and I struggle to understand all the features of vi. 

Also I had so many data structure errors at first that I didn't pay attention to the operational stuff.

This version works pretty close to the real thing from what I can tell within the limits of the features supported.

(there are still warts)

 

Here is what has been touched or changed:

V1.43f
Fixed lots of stuff.

  • Improved screen list speed a bit
  • Optimized where screen is re-drawn in the code to speed up deletions and yanks 
    • They are very fast on smaller files now
  • 'o' command opens line below cursor 
  • 'O' command opens line above the cursor
  • double letter commands are handled better 
    • 'dw'  waits for the w key properly
  • HOME$ named changed to $HOME (not needed by user) 
  • Startup tries to loaded VI99FONT file from the $HOME path 
    • VI99FONT is FONT0230 from a resource I found here with some tweeks by me. 
    • if VI99FONT is not found you get TI ROM Font like BASIC
  • Added SAVEUNDO to 'a' command 
  • 'k' command fixed: does not jump 2 lines at top of screen
  • BACK-SPACE works correctly when editing a line (deletes chars as it goes backwards)
  • ENTER now does line splitting
  • Added 'J' command (upper case J) to join lines
  • Cursor stops at end of file+1 line
  • edit command lets enter vi99 from the shell with the existing file in the buffer 
  • G command works as expected in visual mode
  • STK= on the bottom line is a debug line to see what's on the DATA stack. It will go away in future.


    *Not Quite vi Functions*
    --------------------------
  • 'p' command adds text below CURRENT LINE, not at cursor
  • 'P' command adds text above the current line,  
  • ^K  kills the contents of the clipboard. (VI99 has only the " buffer in vi parlance {I think}) :) 
  • font command loads a font from the shell command line. 
    • The default font is called vi99font 
    • Lee graciously provided CHARA1FBF and CHAR@1FBF fonts that are in the ZIP file.  You can load them but the default cursor is not correct for vi99. (more work)
    • CHAR@1FBF appears similar to VI99FONT



  • Things that I might fix in future
  • The colon command line does not use the same interpreter as the visual mode key interpreter
    • It uses Forth and so is "faking" the key commands that it handles

 

 

 

 

 

VI99-1.43f.zip

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

  • 9 months later...
31 minutes ago, dhe said:

@TheBF

Just pinging on this project, to see if you have played with it anymore?

I have not. I went down some other rabbit holes. Joined a community orchestra and picked up an instrument I had never played before. Man is that humbling at 68 years old. :)  (But its getting better)

 

But questions like yours raise all my programmers guilt so it sounds like its time to get back at it. :)

 

Is there any feature in particular you are waiting for? 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

@TheBF

 

A couple of questions.

 

Was vi9980 tested with classic99 in 80-column mode?

 

Should this be the correct syntax to open and create a file?

 

image.png.f34b3021dc38ec32dbf2fa96c60e3d21.png

 

(using DSK image on Classic99)

 

If I start a new session and hit I for insert mode, I type Line 1, hit enter and end up with this displayed.

 

image.png.6bc9735474967be8532c88662ea3e3e7.png

 

Link to comment
Share on other sites

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.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...