new VI clone for CP/M 2.2 and 3.0

[deramp5113]

I just posted version 2.3. There's been a bunch of work done to verify that all commands work and performance on slower CPU's should be much better. I've also improved the screen refresh logic to accommodate slower terminals. Let me know how all this plays out in your machine.

Hi,

Looks like the posted version is now version 2.5. I still encounter many of the same issues: Both "I" and "i" (as well as "O" and "o") immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Commands to edit like cw, dw, dd, etc., don't work - I assume those modifiers aren't implemented yet?

Mike D

 

[deramp5113]

Patrick Linstruth has worked iteratively with Claude Code over the last few weeks to create the best CP/M version of VI I've ever tried. A very workable subset of VI is already implemented and it works fast even on an 8080 at 2MHz (a Z80 is not required).

To try it, download VIEDIT.COM found here: https://github.com/deltecent/altair8800-claude/tree/master/projects/viedit/src

A preliminary manual for VIEDIT can be found up one directory level. Download VIEDIT.PDF found here: https://github.com/deltecent/altair8800-claude/tree/master/projects/viedit

Mike D

 

[Svenska]

Patrick Linstruth has worked iteratively with Claude Code over the last few weeks to create the best CP/M version of VI I've ever tried. A very workable subset of VI is already implemented and it works fast even on an 8080 at 2MHz (a Z80 is not required).

How does it compare to hjalfi's QE.COM?

 

[tachijuan]

Hi,

Looks like the posted version is now version 2.5. I still encounter many of the same issues: Both "I" and "i" (as well as "O" and "o") immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Commands to edit like cw, dw, dd, etc., don't work - I assume those modifiers aren't implemented yet?

Mike D

Thanks for testing, but I don't see this behavior at all. I've tried "I", "i", "o", "O", cw,dw,dd,etc. All of them work properly on both RunCPM and my SC131 machine. What kind of hardware/emulator are you running your copy on? FWIW - my test harness verify all this functionality against RunCPM. I'd be surprised if I pushed code now that breaks that basic functionality.

 

[tachijuan]

Patrick Linstruth has worked iteratively with Claude Code over the last few weeks to create the best CP/M version of VI I've ever tried. A very workable subset of VI is already implemented and it works fast even on an 8080 at 2MHz (a Z80 is not required).

To try it, download VIEDIT.COM found here: https://github.com/deltecent/altair8800-claude/tree/master/projects/viedit/src

A preliminary manual for VIEDIT can be found up one directory level. Download VIEDIT.PDF found here: https://github.com/deltecent/altair8800-claude/tree/master/projects/viedit

Mike D

No secret here, I too have been working with Claude Code.

 

[deramp5113]

Thanks for testing, but I don't see this behavior at all. I've tried "I", "i", "o", "O", cw,dw,dd,etc. All of them work properly on both RunCPM and my SC131 machine. What kind of hardware/emulator are you running your copy on? FWIW - my test harness verify all this functionality against RunCPM. I'd be surprised if I pushed code now that breaks that basic functionality.

It’s a vintage Mostek Z80 development system running CP/M 2.2. I’ll try it on some other vintage Z80 machines I have.

Mike D

 

[deramp5113]

Hello,

I encounter the same problems when running HVI on a vintage North Star Horizon under North Star branded CP/M 2.2 and under Lifeboat branded CP/M 2.2. "I" and "i" and "O" and "o" immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Commands to edit like cw, dw, dd, etc., don't work. For example, "cw" simply moves forward a word. The "c" is ignored ("unknown motion" briefly flashes at the bottom of the display when the "c" or "d" is typed).

Mike D

 

[deramp5113]

How does it compare to hjalfi's QE.COM?

I haven’t found QE.COM already made in his GitHub repository, and I don’t have the Amsterdam Compiler Kit to build it, so I haven’t evaluated QE. If you have an executable QE.COM for CP/M, I’d love to try it.

Mike D

 

[Svenska]

I haven’t found QE.COM already made in his GitHub repository, and I don’t have the Amsterdam Compiler Kit to build it, so I haven’t evaluated QE. If you have an executable QE.COM for CP/M, I’d love to try it.

The Github repository contains pre-built disk images for all targets [here]. I only checked the kayproii.img, but all of them should contain QE.COM.

 

[tachijuan]

Hello,

I encounter the same problems when running HVI on a vintage North Star Horizon under North Star branded CP/M 2.2 and under Lifeboat branded CP/M 2.2. "I" and "i" and "O" and "o" immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Commands to edit like cw, dw, dd, etc., don't work. For example, "cw" simply moves forward a word. The "c" is ignored ("unknown motion" briefly flashes at the bottom of the display when the "c" or "d" is typed).

Mike D

Thanks for trying this out. I'll haul out my Osborne or Kaypro's and try it on them to reproduce.

 

[tachijuan]

Hello,

I encounter the same problems when running HVI on a vintage North Star Horizon under North Star branded CP/M 2.2 and under Lifeboat branded CP/M 2.2. "I" and "i" and "O" and "o" immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Commands to edit like cw, dw, dd, etc., don't work. For example, "cw" simply moves forward a word. The "c" is ignored ("unknown motion" briefly flashes at the bottom of the display when the "c" or "d" is typed).

Mike D

Mike -

I think I found the problem. Please test out version 2.7.1 for me.

Thanks,

Juan

 

[deramp5113]

Mike -

I think I found the problem. Please test out version 2.7.1 for me.

Thanks,

Juan

Juan,

This works dramatically better! All the issues I mentioned are fixed.

Now that I can use cw, i, etc., I see a screen update issue. My main use of vi for is editing assembly language programs with a tab between each column. If I perform a cw (or dw followed by an i), each new character I type moves the remainder of the line over one position independently of the tab characters. This results in the columns of the line being in the wrong position. Subsequent word movement (w) moves to where the words should be, but aren't shown there anymore. Forcing a screen redraw with ctrl-l fixes the errantly displayed line.

Mike D

 

[tachijuan]

Juan,

This works dramatically better! All the issues I mentioned are fixed.

Now that I can use cw, i, etc., I see a screen update issue. My main use of vi for is editing assembly language programs with a tab between each column. If I perform a cw (or dw followed by an i), each new character I type moves the remainder of the line over one position independently of the tab characters. This results in the columns of the line being in the wrong position. Subsequent word movement (w) moves to where the words should be, but aren't shown there anymore. Forcing a screen redraw with ctrl-l fixes the errantly displayed line.

Mike D

Excellent! I'll work on this shortly. Glad we found that other bug. Turned out to be an undocumented "feature" of BDOS. This screen alignment thing should be easy to fix.

 

[deramp5113]

The Github repository contains pre-built disk images for all targets [here]. I only checked the kayproii.img, but all of them should contain QE.COM.

The Kaypro II version won't use VT-100/ANSI escape sequences, so I can't use an existing S-100 machine and ANSI terminal like I've been using to test HVI and Patrick's VI editors. I'll have to fire up my Kaypro 10 and see if it's compatible with the Kaypro II version of QE.

Mike D

 

[tachijuan]

Juan,

This works dramatically better! All the issues I mentioned are fixed.

Now that I can use cw, i, etc., I see a screen update issue. My main use of vi for is editing assembly language programs with a tab between each column. If I perform a cw (or dw followed by an i), each new character I type moves the remainder of the line over one position independently of the tab characters. This results in the columns of the line being in the wrong position. Subsequent word movement (w) moves to where the words should be, but aren't shown there anymore. Forcing a screen redraw with ctrl-l fixes the errantly displayed line.

Mike D

Mike - I just pushed version 2.7.2 that should fix this. Let me know.

 

[deramp5113]

Juan,

Yep - the tab alignment problem is fixed!

Mike D

 

[tachijuan]

Juan,

Yep - the tab alignment problem is fixed!

Mike D

Excellent! Let me know if you have any other feature requests. My next major task will be to abstract the terminal handling so HVI can be configured for other terminals (Televideo, adm3, etc.).

 

[tachijuan]

I've just pushed a version that I worked on last night. This expands support for a number of common terminals. I chose to implement this as a compile time option instead of the typical configuration/patch system because this allows me to minimize the binary size. Would really appreciate more testing from this group on non-ANSI terminals/hardware.

It's staged as a branch right now and can be found here: https://github.com/tachijuan/hvi/tree/feature/configurable-terminal-type

 

[whartung]

Are you developing on CP/M machine, developing in a simulator, or are you developing on a modern system and cross compiling? Curious what your workflow is like.

 

[tachijuan]

Are you developing on CP/M machine, developing in a simulator, or are you developing on a modern system and cross compiling? Curious what your workflow is like.

I'm developing on a modern machine using RunCPM as the emulator. All the code is written either by me or Claude Code (cli version). All of the code is then compiled in RunCPM using the HiTech-C 3.09 compiler. Claude also helped me write python scripts that test all the functionality of the editor in RunCPM before I publish code. There's an extensive test suite in the GitHub repository if you want to take a look at how that works. This has been extremely productive. My first versions were written with Gemini (cli as well). It wasn't as capable at testing the code automatically and I had to do the compile/test process by hand.