• Please review our updated Terms and Rules here

Most common emulation for CP/M programs?

DJ Sures

Member
Joined
Jan 10, 2023
Messages
24
Hey gang - I recently posted a video about adding vt100 terminal emulation to my NABU Cloud CP/M BIOS. I choose vt100 because I did a quick google search and saw that it was the most popular. But, it occurred to me that I have access to the cp/m experts right here! And egg on my face, I should have just asked you. What is the most popular terminal emulation for cp/m applications?
 
Well, the ADM-3A was a very popular terminal for home use, since it was less costly. That seems to have been a commonly implemented terminal type in the CP/M software that I have seen.

- Alex
 
The problem with VT-100 is that the control codes could be too long for the space allocated by some programs. I would go with ADM-3A, this was also emulated on the Kaypro and C-128. VT-52 or possibly Osbourne 1 emulation would also be a good choice.
 
Both ADM-3A and VT-52 are very similar in complexity, but VT-52 actually supports arrow keys. CP/M support for both seems pretty universal (unless for VT-100, which is sometimes missing).

Additionally, a VT-52 works well as a Linux terminal (although vim uses "insert line" and "delete line"), supports a few additional characters, and can be verified using "vttest". So I would recommend going for VT-52 over ADM-3A.
 
Also, as a variation on the VT-52, there were a lot of Heath/Zenith H19 terminals out there. In addition to the H89 computer which had the H19 built-in.
 
I knew this was the correct place to ask. I created a vt100 prototype the other day. Actually, it was entirely complete except for allowing the scrolling region to set, which i did last night because it was only a few lines of code to add variables to set the range of my existing scrolling function area.

That was easy with my existing vdp framework to do this for scrolling...
C:
    case 'r': { // enable scrolling

      parseAndPopulateArgs();

      if (_args[1] == 0) {

        _scrollRangeTop = 0;
        _scrollRangeBottom = SCREEN_MAX_Y;
      } else {

        _scrollRangeTop = _args[0] - 1;
        _scrollRangeBottom = _args[1] - 1;
      }

      _scrollRangeTopSaved = _scrollRangeTop;
      _scrollRangeBottomSaved = _scrollRangeBottom;

      _isEscaped = false;

      break;
    }

and supporting things like turning on and off the scroll area....

C:
void vtDoQueryH(uint8_t h) {

  switch (h) {

    case 6: {

      _scrollRangeTop = _scrollRangeTopSaved;
      _scrollRangeBottom = _scrollRangeBottomSaved;
      
      break;
    }
    case 7: {

      _isLineWrap = true;

      break;
    }
    case 8: {
      break;
    }
  }
}

void vtDoQueryL(uint8_t l) {

  switch (l) {

    case 3: {
    
      _scrollRangeTop = 0;
      _scrollRangeBottom = SCREEN_MAX_Y;
      _isLineWrap = true;
      
      vdp_clearScreen();

      break;
    }
    case 6: {

      _scrollRangeTop = 0;
      _scrollRangeBottom = SCREEN_MAX_Y;
      
      break;
    }
    case 7: {

      _isLineWrap = false;

      break;
    }
    case 8: {
      break;
    }
  }
}

void vtDoQueryFunction() {

  switch (_vth[0]) {

    case 'h': {
      
      parseAndPopulateArgs();

      for (uint8_t i = 0; i < MAX_VT_ARG_CNT; i++)       
        vtDoQueryH(_args[i]);

      _isEscaped = false;

      break;
    }
    case 'l': {

      parseAndPopulateArgs();

      for (uint8_t i = 0; i < MAX_VT_ARG_CNT; i++)       
        vtDoQueryL(_args[i]);

      _isEscaped = false;

      break;
    }
    case 'n':
    case 'i': {

      _isEscaped = false;

      break;
    }
  }
}

So I have a complete vt100 now. Of course, it doesn't do color, and nearly all programs through telnet do not like 40-character width. Emacs is pretty bad! I guess I'll check in source control and save what I have completed for the time being. It doesn't sound like supporting vt100 is useful for native cp/m applications. And realistically, it's not useful for Telnet either.

It'll be easy to implement vt52 with the framework I've done. So maybe I will downgrade the emulation because cp/m programs won't use vt100 anyway

Regarding compatibility between vt52 and vt100 - there isn't much- and the commands overlap with different behavior. For example, ESC D in vt52 is cursor left, meanwhile, ESC D in vt100 is scroll display down one line. The same is for nearly all other commands. Although many sources claim vt100 supports the previous vt52 commands, I do not see that. Almost every command I checked in vt100 is entirely different from vt52. An interesting tidbit is Putty's documentation, which states Putty supports vt100 but not vt52. If vt52 was a subset of vt100, it would have been supported.

I feel weird taking vt100 support away since i did such a great job implementing it. But if it's not going to be used....
 
The MYZ80 emulator supports two families of terminal emulation:
"MYZ80" - supports codes for VT100, Televideo 912, ADM 3A, Morrow MT70
"VT52" - supports codes for VT52, Amstrad CPC / PCW / Spectrum +3

It has a number of other emulations which are slight variants of the "MYZ80" scheme, with different numbers of screen lines or wrap settings.
 
So the conclusion is having my bios natively support vt52 emulation. I quickly removed my vt10 code and replaced it with vt52, which was way easier than I thought. I do like vt52 because the function comes before the parameter. Vt100 ansi white paper expects a 32 byte buffer that you keep track of the escape sequence until receiving a command character, or the buffer fills.

I tried using the vt52 with Linux in my telnet client, but the Linux terminfo or shell or what ever still sends vt100 commands. I set the emulation mode with option 24 in telnet. Echo $term is correct and tput has the correct screen dimensions from my telnet option as well.

So I might have yo keep a vt100 for telnet
 
AFAIK, telnet, at least on Linux/Unix, is just a pass-thru. That's the way it's always been in the past, at least. If you are using an xterm, or similar, terminal window to run telnet then that is what is doing the emulation of the vt100-like commands. 'xterm' does have a VT52 emulation mode, and the latest Ubuntu man-page claims it is complete.
 
I tried this out using xterm, and it seems to work. I used the "-ti vt52 -tn vt52" options to xterm. My bash setup is a little off, as something seems to be hard-coded for the 'xterm' term type when printing my prompt string, but it otherwise seems to work. Unfortunately, programs that I have on-hand are designed for the H19 and that does not exactly match the VT52 (H19 is a superset of VT52).
 
So here’s some info about how telnet works. Telnet isn’t a pass through. There’s a whole communication model behind telnet called Options.

There’s a number of options that have different parameters based on your communication presences. They happen behind the scenes which is why most ppl think telnet is just a tcp terminal. But there’s a lot more.

So there’s a discussion during and at a connection about will, will not, will do, and such. Telnet option 24 is the emulation preference. If you take a look at my nabulib GitHub, the telnet source has option communication built in.

During the connection there will be a request for emulation mode. You can supply vt100 or vt220 or vt52 etc. and you can say “I only do this”.

So I specify the emulation preference during the options neglecting of my Nabu telnet client. The funny thing is there’s still vt100 escape codes being sent. I’ll dig into it further. But I’m okay to keep my vt52 in bios for local cpm applications, and use vt100 in the telnet client.
 
It's curious how telnet has become a pariah of protocols. I had to search pretty hard for a telnet client for Android--SSH, sure, but unvarnished telnet, not so much. I note the Firefox has dropped support for ftp as well, even though there are many sites still using it. (I use PaleMoon as my ftp client).
 
NANO is always a good test of emulation :)

1674378138629.png


And when i referred to the strange way the shell still tries to force vt100 - look at this. Also, i don't think these commands are vt100. I think they're some extension used for xterm because they have something to do with specifying the bracket paste method.

1674378230301.png

I think the only solution is to parse it in my bios. haven't tested with other OS' yet - that's on debian.
 
It's quite possible that your .bashrc or equivalent file is directly setting the prompt to include VT100 control codes. For example, my .bashrc contains the lines:
Code:
if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
In my case that only happens for a terminal of type xterm-color, but your setup may be different.
 
So here’s some info about how telnet works. Telnet isn’t a pass through. There’s a whole communication model behind telnet called Options.
...
Of course telnet has a protocol, that's not what I meant be "pass-through". The telnet protocol describes a way for the two sides to communicate information about terminal emulation/type, but (standard) telnet does not do the terminal emulation. That would not make sense, since it is the responsibility of the client/user "front end" to do that. Whatever is providing the "front end" to telnet is what needs to do the terminal emulation. Telnet does not dictate or control what that front-end is. If you logged in via a serial port, then your terminal is defined by what is connected to the serial port (typically a physical, CRT+keyboard, terminal). If you are working from a GUI (through a graphics adapter), then things like xterm provide you a "terminal" and those programs are responsible for the terminal emulation. Telnet is just a transient program you run from one of those terminal-oriented environments.
 
Also, as a variation on the VT-52, there were a lot of Heath/Zenith H19 terminals out there. In addition to the H89 computer which had the H19 built-in.
They seem to also support ANSI sequences... how commonly were they used in ANSI mode vs. Heath mode?

So I have a complete vt100 now. Of course, it doesn't do color, and nearly all programs through telnet do not like 40-character width. [...] It doesn't sound like supporting vt100 is useful for native cp/m applications. And realistically, it's not useful for Telnet either.
Well, a complete VT-100 also includes VT-52 support... and at least LADDER supports both modes. :)

The screen size is separate from the terminal emulation. Modern systems support dynamic sizes (see SIGWINCH), which Telnet can negotiate as well. However, CP/M 2.2 is completely unaware of the output device and applications are fixed to a specific size. While applications can often be configured/patched to a different size, many still require at least 64 columns.

CP/M 3.0 can report the screen size, but I don't know whether that was commonly used by applications; retrieving the current screen size requires ANSI/VT-100 support unfortunately (it also allows detecting whether the other end renders UTF-8 or not).

Alexandre Montaron made an RSX and some patches to support this in some applications: http://canal.chez.com/CPM/

If you implement a complete VT-100 emulation, you get VT-52 support as well (no compatibility issues) and a lot more possibilities. Depends on how much memory you got to spare, though.

Although many sources claim vt100 supports the previous vt52 commands, I do not see that.
You use "ESC ? 2 l" (DECANM) to switch the VT-100 into VT-52 mode, and "ESC <" to switch back. Compatibility is not transparent.

I tried using the vt52 with Linux in my telnet client, but the Linux terminfo or shell or what ever still sends vt100 commands.
There are a number of modern applications which forego curses/ncurses and instead hardcode ANSI escape sequences. Nothing you can do about those, especially if they freely use private sequences (such as "set window title") as well. Many shell scripts do that to get color support, including the default .bashrc shipped in many distributions. Make sure to have $TERM set correctly early on and manually override $PS1 afterwards if necessary.

It's curious how telnet has become a pariah of protocols. I had to search pretty hard for a telnet client for Android--SSH, sure, but unvarnished telnet, not so much. I note the Firefox has dropped support for ftp as well, even though there are many sites still using it. (I use PaleMoon as my ftp client).
It fits within the "move fast and break things" thought frameworks. Both Chrome and Firefox have dropped support for Gopher and FTP for years now, and Telnet has been heavily discouraged as a security problem for much longer. Now that most appliances have switched away (and older one been replaced), there is little reason to keep telnet supported anywhere.

NANO is always a good test of emulation :)
For my VT-52 work, I found vim more annoying. Also, check out "vttest" for a quite good test.

I've built a monochrome-based AVR-based serial TV terminal (80 columns), and included both VT-52 and ADM-3A support; ADM-3A is basically unusable in Linux, which is why I stopped recommending it at all. I am not aware of any CP/M application which knows ADM-3A but not VT-52, so I'll always opt for the latter (or both).
 
Back
Top