new VI clone for CP/M 2.2 and 3.0

[horo]

I used the HTC linux port from https://github.com/ogdenpm/hitech and compiled hvi.com with:

htc -V -O hvi.c gap.c term.c screen.c emove.c edit.c erepeat.c ex.c

giving

-rw-rw-r-- 1 horo horo 38012 30. Apr 20:04 hvi.com

 

[Thorbjørn Ravn Andersen]

z88dk sdcc: I found that the sdcccall(1) convention (which passes parameters in registers instead of on the stack IX/IY-indexed) gives pretty good code, if kept to a few parameters. I still work on the z80-adaptation at https://github.com/ravn/llvm-z80 but even at the current embryonic stage it generates better code than sdcc. The llvm backend in z88dk is still very experimental and didn't generate as good code so I didn't use it much.

 

[JohnElliott]

I could probably come up with workable code for things like strlen, fopen, etc. These are fairly well known and well documented routines, and there might even be examples available on-line. BUT, what the heck does _iob do? Is it something that is only found in the HiTech package? Of course, this all assumes that I can figure out how to generate a ".a" archive that XGCC will work with.

All the functions listed are parts of the standard C library. I don't know if there is one for CP/M-68K; if not, one would have to be written or ported. _iob is the table of open stdio files, starting with stdin, stdout and stderr. So _iob[0] is stdin, _iob[1] is stdout, _iob[2] is stderr.

 

[KE6JAG]

All the functions listed are parts of the standard C library. I don't know if there is one for CP/M-68K; if not, one would have to be written or ported. _iob is the table of open stdio files, starting with stdin, stdout and stderr. So _iob[0] is stdin, _iob[1] is stdout, _iob[2] is stderr.

Thanks John, my iobyte was just a "wag" (wild assed guess)!

 

[tachijuan]

I used the HTC linux port from https://github.com/ogdenpm/hitech and compiled hvi.com with:

htc -V -O hvi.c gap.c term.c screen.c emove.c edit.c erepeat.c ex.c

giving

-rw-rw-r-- 1 horo horo 38012 30. Apr 20:04 hvi.com

oh cool. I was looking for the linux port. This will help with my iterations. I'm still plugging away at refactoring the stdlib out of the app. Thanks for this.

 

[norwestrzh]

Thanks John, my iobyte was just a "wag" (wild assed guess)!

Not so much of a "wag" as you might think. The iobyte could have a great deal to do with the definition of stdin, stdout, and stderr!

A related question: is it possible to force HiTech C to generate 8080 code only? Or any other of the popular C compilers of the time?

 

[Svenska]

ACK generates 8080 code. Also, the FUZIX compiler (which is a recent development) can target 8080, 8085 and Z80. Both are cross-compilers.

 

[Laci53]

I could probably come up with workable code for things like strlen, fopen, etc. These are fairly well known and well documented routines, and there might even be examples available on-line. BUT, what the heck does _iob do? Is it something that is only found in the HiTech package? Of course, this all assumes that I can figure out how to generate a ".a" archive that XGCC will work with.

The _iob buffer contains the file definition area (8 bytes / file)
In the case of HiTech C , buffers for 5 files are quite enough

;=========================================================
; Offsets of things in the _iob structure

ptr equ 0 ; pointer to next byte
cnt equ 2 ; number of bytes left
base equ 4 ; beginning of buffer
flag equ 6 ; flag bits
file equ 7 ; file number

; The bit numbers of the flags in flag

_IOREAD_BIT equ 0
_IOWRT_BIT equ 1
_IONBF_BIT equ 2
_IOMYBUF_BIT equ 3
_IOEOF_BIT equ 4
_IOERR_BIT equ 5
_IOSTRG_BIT equ 6
_IOBINARY_BIT equ 7

Please, study the Z80 assembler source files named "lib*.as" to be found in my customised HiTech C compiler... you will find there all the necessary LIBC.LIB modules( strings, file I/O, ...), implemented as Z80 assembler files.

Ladislau

 

[Laci53]

Of course, this all assumes that I can figure out how to generate a ".a" archive that XGCC will work with.

If you build HVI on a CP/M machine, you do not need to worry about these ".a" archives.

I develop my Z80 software projects on a outstanding 25MHz Z80 CP/M machine (built by Bill Shen "plasmo"), and I am quite content with its processing speed.

Of course, I use my customized HiTech C toolset, in order to be able to use larger C and assembler source files...

Once again, as you, I encountered the same obstacle (too big final executable) and I was constrained to build my "custom" LIBC, by replacing all the necessary library modules with Z80 assembler files, assembled and added in the final LINK command.

Ladislau

 

[tachijuan]

OK - I've been busy and have a completely different build that I'm calling ZVI. In this iteration, I wanted to test if I could use the horsepower of a modern computer with a more modern compiler/assembler toolchain to optimize the binary size. For this version the source has been updated to compile with Z88DK/SDCC and I've tried to eliminate all dependencies on the STDLIB of that toolchain. This has brought the binary down to ~34k. I've also added true large file support. Please let me know if this works better for you all, if you have any suggestions, and/or if you run into any issues. The repo is here: https://github.com/tachijuan/zvi

 

[norwestrzh]

I downloaded the code from the zvi github site. ZVI.COM works OK with my 20 MHz SBC. It's a little slow, but still quite usable. Kudos that the arrow keys now work! Great piece of work!! I have not tried to build my own version yet ... just used the .COM file included with the code.

Thanks.

edit: works even better on my 24 MHz Z80 SBC!!!

 

[tachijuan]

I downloaded HVI.COM and uploaded it to a real Z80 CP/M machine which has 51K of TPA below the BDOS. I get a "hvi: out of memory" error when I try to run HVI. Does HVI need to be compiled on the target machine? Do I need any HiTech-C runtime files on the disk to support the program?

Mike D

Mike - I just posted version 2.0 of HVI on GitHub. It's ~11K smaller and should work in your environment. Give it a go and let me know how it goes for you.

Thanks,

Juan

 

[tomjennings]

Nice! Today I added ANSI support to my fZ80, HVI.COM works on CP/M, and runs on MP/M II 2.1 maybe with issues. I have a bunch of ANSI sequence issues I have to fix before I can know. When I do I'll bang on it and get back to you.

 

[deramp5113]

Mike - I just posted version 2.0 of HVI on GitHub. It's ~11K smaller and should work in your environment. Give it a go and let me know how it goes for you.

Thanks,

Juan

Juan,

HVI now runs on my Z80 CP/M 2.2 machine and no longer gets the out of memory error. However, several primary commands don't seem to work properly. Both I and i immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Paging forward and backward takes about 5 seconds before the page starts to redraw. I noticed that cw, dw, etc., don't work - i assume those modifiers aren't implemented. If instead I individually delete characters, it takes 2-3 seconds per character deleted (more time the closer the cursor is to the top of the screen). Looks like running with reasonable response time on a real 2MHz or 4Mhz machine may require a more optimized solution coded in assembly language.

Have you every tried WordMaster (the predecessor to WordStar)? John did an excellent job getting reasonable response time in a full screen editor on a 2MHz 8080 or Z80 machine. I'd like to create a version of vi that has performance similar to WordMaster.

Mike D

 

[tachijuan]

Juan,

HVI now runs on my Z80 CP/M 2.2 machine and no longer gets the out of memory error. However, several primary commands don't seem to work properly. Both I and i immediately enter an endless loop of inserting spaces rapidly, and yet, I can type in new characters while it's busy inserting spaces. Paging forward and backward takes about 5 seconds before the page starts to redraw. I noticed that cw, dw, etc., don't work - i assume those modifiers aren't implemented. If instead I individually delete characters, it takes 2-3 seconds per character deleted (more time the closer the cursor is to the top of the screen). Looks like running with reasonable response time on a real 2MHz or 4Mhz machine may require a more optimized solution coded in assembly language.

Have you every tried WordMaster (the predecessor to WordStar)? John did an excellent job getting reasonable response time in a full screen editor on a 2MHz 8080 or Z80 machine. I'd like to create a version of vi that has performance similar to WordMaster.

Mike D

Thanks for testing. That's interesting. I'll dig into the input loop to see what might be causing this. It'll be a bit of time before I can work on this again. Sit tight.

 

[shirsch]

Nice! Today I added ANSI support to my fZ80, HVI.COM works on CP/M, and runs on MP/M II 2.1 maybe with issues. I have a bunch of ANSI sequence issues I have to fix before I can know. When I do I'll bang on it and get back to you.

I have not had an opportunity to try HVI.COM, but I'm happy to hear about ANSI support in fZ80. I assume it's a subset?

 

[tomjennings]

I have not had an opportunity to try HVI.COM, but I'm happy to hear about ANSI support in fZ80. I assume it's a subset?

I tried to include all I could find. I've left out keyboard and other such. Colors and modes are way off; colors not yet mapped. Modes mostly not possible (dim, strikethrough) but those hopefully aren't critical.

I used this: https://gist.github.com/ConnerWill/d4b6c776b509add763e17f9f113fd25b

It's horribly buggy -- hvi runs but the screen is a mess, but consistent. It just needs debug time and I'm in the middle of getting all the hardware together for 25 new machines; boards and cabinets arrive next week. Sans a real test program, I work up a hideous kludge to halt (firmware) after each hvi ANSI command and track command vs. result. Probably I can get most of it fixed in a day.

It's interesting how many H19 sequences map to ANSI, and VT100. Implementation was to catch the '[' and turn the states that followed into recursive calls to H19Out() using the H19 states.

Oh -- no H19 vs ANSI mode needed -- only one command conflicted! ESC M. To resolve that, a heuristic flag set positively-ANSI for each valid ESC [ x y... sequence, and set positively-H19 for ESC Y and some other. Then ESC M decides via that flag. "Should work" lol, if not, a MODE via VGA.COM or something.