• Please review our updated Terms and Rules here

In memory editor with VI key bindings?

JonB

Veteran Member
Joined
Jan 26, 2014
Messages
1,652
Location
South Herefordshire, UK
Hi all

Looking for a text editor with VI key bindings. WordStar is too arcane for me (sorry, vi is hard wired into my muscle memory). Anyone know of one for cp/m? Does not need to be a disk paging clone, it is just for program files.

Thanks

JonB
 
Hi All;
I can't say that this will fit the bill, If I remember correctly.. "Software Tools" by Kernighan and Plauger., Was ported over to Tiny C, and so was available on CPM Diskettes.. I have it "SomeWhere" on an 8" Floppy..

THANK YOU Marty
 
Hmm, Marty - that looks promising. It's a book though - I wonder if one of the examples is an editor?

The problem here is that a modern vi clone like elvis uses a bit of disk i/o. There's always a temporary file somewhere and this is going to slow things right down on a floppy drive based system. I think there is no need for a text editor that can handle megabytes of text, so this sort of feature is not necessary on a CP/M type machine.

If you have an image or can make an image of the disk we can see. Of course, the format may be a problem. The CP/M I am using (on the TRS-80 Model IV) has the capability to read many formats, and of course there are some CP/M disk reading utilities for MS-DOS I might try.

Please let us know how you get on. In the meantime I am going to research it a bit.

@Mike: Yes, may be time to write one indeed. Would love to have a bash at it. But need a decent editor to enter the code! :) I would like to develop it on a CP/M system as that is a load more fun, but I have not yet pulled together a suitable toolchain yet. Still trying to get the "el cheapo" IDE interface running for the TRS-80.

Cheers

JonB
 
Last edited:
What's in SIMTEL20 and CPMUG? It seems to me that there were quite a few editors there. Perhaps one is open to modification.

I ended up writing my own editor for CP/M with the features that I wanted.
 
vi.jpg

A little teaser. It is a hacked up copy of stevie which is a vi clone written for the Atari ST by a guy called Tim Thompson. Unfortunately it is horribly slow and crashes, but it works, sort of.

I used the Aztec C compiler to build it and it is currently set for Televideo 910 escape sequences, because my terminal is only supported by WordStar in TVI 910 mode. WS sucks, but at least it works. As this is running on a TRS-80 Model 4, it needs to support ADM3 sequences. Eventually I will create an installer like the WS one that can patch the COM file with the selected terminal sequences.

Right now I need to look at it a bit closer in order to see where it can be made to run quicker. The main issue is the key response; it takes ~500ms to respond to any keypress and because the console i/o is unbuffered, there is no type ahead. So you can use it but not at normal speeds.

As to crashing, well, it crashed (as far as I can tell) when I tried to save the test file with ":wq". Not sure why right now, but I think it is encouraging that it only took a day to get this far (admittedly I am getting help from a Linux installation on my PC, but it is all natively compiled).

The maximum file size it can edit is set to 16K and the executable is currently 28K. Not that you'd want to actually try and edit a 16K file with it being this slow!
 
Last edited:
Cool - keep working! I'm stacked up with a couple of other projects right now, so I couldn't get around to writing a VI clone for CP/M any time soon anyway :)

Mike
 
Cool - keep working! I'm stacked up with a couple of other projects right now, so I couldn't get around to writing a VI clone for CP/M any time soon anyway :)

Mike

It's surprising how much of it actually works.

The only bug I found apart from slowness is that the RETURN key on my terminal is not being handled properly and this affects both command line and insert mode, but ^J works as a RETURN substiute.

Update: Got it working, yay! Turns out I DO need the ioctl to do the CR->LF translation. But it is still very slow, and it doesn't use any of the terminal's special controls such as scrolling or line insert. The program is using - as far as I can tell - escape sequences for clear_screen and locate_cursor(x,y) and that's it, so there is an awful lot of redrawing going on. This sort of thing can be fixed.... eventually.

Now, which terminals should it support? I think vt100, adm3a, tvi910 - any others?
 
Last edited:
Some more thoughts.. loading / saving is really slow. I think this is because it is reading / writing the file a character at a time. Would be much faster if it did it a line at a time. Also with a larger file it is pretty slow at deleting / inserting lines. I haven't analysed the code yet, but I reckon this is because it is managing each file as a single contiguous buffer in memory and it could be much cleverer than that (for example, by using a linked list of lines and a "buffer gap" algorithm).

However, I have just used the fledgling CP/M stevie to edit one of its own source files, which is a milestone. And this with the most stinkiest of colds...

:D
 
loading / saving is really slow. I think this is because it is reading / writing the file a character at a time.

Perhaps the original version was depending on C stdio buffering to improve the performance to/from disk? fgetc/fputc will access an internal buffer managed by the C standard library.
 
Yes, I know. But it is a bit sluggish on the ST too. The guy who wrote it said he'd just hacked a useable tool and wasn't really interested in refining it further, so it tends to use a sort of brute force approach rather than optimised elegance. Despite this, it does work very well, and if you use vim on Linux, you are using its direct descendant I believe.

But back to file I/O. CP/M loads files one sector at a time (in blocks of 128 bytes) according to what I read. So optimising the read so it a) does it in chunks on one block at a time, and b) reads the file straight into the edit buffer yields a significant performance gain.

It is also trying to insert into the edit buffer, so each character it reads entails additional operations to open a character wide space in the buffer prior to insert. Even at the end of the buffer it is making this check. This is so the vi :r (read into buffer) command will work properly.

The solution is to use fseek() and ftell() to get the file length, then open the buffer up with memmove() if it already contains text and the insert point is not at the end. However, an intermediate buffer may be required here because Montezuma CP/M reports the characters used to pad the last sector as part of the file length. You can see this if you use DUMP.COM to list a text file - the last sector is padded with SUBs. Or I could use the unused space at the end of the edit buffer to load the file, then truncate the SUBs, then copy into the opened buffer.

Another interesting point about the original code is that it doesn't use memcpy() or memmove(). I presume this is because these were not available in the compiler the author used. Certainly, it isn't on my ST C compiler, although Aztec C on CP/M does have memmov() but not memcpy().

I could yak on about this stuff all day but I would rather cut some code! ;)

@tingo: can you tell me what terminal escape codes you need, or the terminal type your CP/M box is using / emulating, please? I need clear screen, home cursor and set cursor position (row, col) sequences as a minimum. I can then compile a version for you to try.
 
Last edited:
A further update: I looked at the screen handling code and my earlier suspicion was correct - it's using brute force to do it. This makes it easier to update the screen properly so it is in line with the contents of the file buffer, but on slower machines it introduces too much latency.

I think the answer will be to leverage more of the terminal's escape sequences and this may mean that dumber terminals may br left behind. Missing sequences can be coded using cursor positioning and sending characters alone, but the cost will be performance. I'll need to find out about terminal capabilities of the older terminals and see where the common denominator is.
 
Back
Top