I'm porting CP/M to a new/old machine (the Amstrad NC200 laptop). Running programs on it is no problem, but running interesting programs (i.e. WordStar, Turbo Pascal and Ladder) involves implementing a terminal emulator of some description.

I was originally planning on implementing a VT52 but from exploring the Walnut Creek CP/M archive it seems that most CP/M software come preinstalled for other terminal types --- the Kaypro uses escape sequences similar to the ADM-3A, for example.

My device only has an 80x16 screen so some configuration would be required no matter what terminal type I implement, but I should be able to save a lot of grief if I just used a terminal type which was already well supported by CP/M software.

So, what was the most common CP/M terminal type?

  • VT100 and VT220 eulators were fairly common. – Walter Mitty Dec 4 at 12:50
  • 1
    I was implementing terminal application some time ago, starting from VT52 (the very basic terminal), then adding VT100 with colors (ANSI). These terminals, while having differences, are complementary. Look at command set and you will see. I ended up implementing most used sequences from both terminal types. – Anonymous Dec 4 at 14:35
  • As an aside, for Wordstar at least the best option isn't a terminal emulator at all: Wordstar has space set aside for patching the program with your own display handling code, and doing so makes it perform better than using a terminal emulator (assuming you have a direct memory mapped character display). – Jules Dec 5 at 0:48
  • The Amstrad PCWs were probably the largest-selling CP/M machines. They used VT52/Heathkit H19 codes – scruss Dec 5 at 15:01
  • @Jules Sadly I have a bitmap graphic display (held in banked out RAM). – David Given Dec 5 at 17:02
up vote 10 down vote accepted

Apologies for a non-definitive answer; while implementing a CP/M emulator for the Mac I find a fairly even split in the terminals that software available via Walnut Creek, etc, was configured for out of the box between the ADM-3a, VT-52, Hazeltine 1500 and Osborne control sets.

If you're looking to do a really thorough job, I found that simple statistical autodetection worked pretty well for all the software I tested: whichever terminal is detecting the largest number of control codes that pass basic validation (like not trying to move the cursor outside of its meaningful range) is invariably the one the software believes itself to be talking to.

So I used a simple generic page buffer, two bytes per character to cover both terminals with modal attributes as well as those with serial attributes, and the user sees only that of the terminal that is statistically most likely. After a certain confidence threshold is crossed, that choice is locked in and no further emulation of the other terminals occurs.

  • Wow, that's hardcore! Sadly not applicable for my case (I only have a couple of kilobytes to put the terminal state machine implementation in). Sounds like I should probably just pick whichever of those is the easiest to implement, then. – David Given Dec 4 at 15:51
  • I did a VT52 emulator to drive a "TV typewriter" board I hacked together on my TRS-80 Model I. Like you, I was memory-constrained. I needed to talk to VMS systems, so I wanted a DEC emulation; VT52 was very easy, VT100 would have been too large and complex. ADM-3A would have been even easier. In your situation, I'd target that first. (I spent limited time in CP/M, not nearly enough to speak to terminal support frequency.) – jeffB Dec 4 at 18:06
  • I have actually implemented (most of) VT52, as I had code for it already... and then I discovered that Turbo Pascal and friends don't actually offer VT52 as a built-in configuration option. I'll investigate the ADM-3A ones instead. – David Given Dec 5 at 17:07
  • 2
    Yes, ADM-3A/Kaypro II looks good. Incidentally, the Kaypro manuals have the sequences for Insert Line and Delete Line backwards, which isn't confusing at all. – David Given Dec 5 at 20:57

There were plenty of CP/M systems that had the terminal built in and just as many that shipped with no terminal at all and had a user-selected model at the end of a serial cable. That makes the most-common terminal type difficult to nail down.

Fortunately, publishers of terminal-intensive programs knew this and provided the ability to configure without requiring a particular type of terminal. WordStar, for example shipped unconfigured from MicroPro with a program called WINSTALL.COM that had simple text menus for doing that. It was also common for computer vendors (e.g., Osborne, Kaypro) to license OEM versions of popular programs and ship them preconfigured for their systems, allowing that step to be skipped.

If you want to get some idea of what terminal you should support, start with a dumb emulation, run the setup programs for products you're likely to use and find the ones they support. You might also dig through old issues of Byte available on the Internet Archive and see what terminals were offered for sale alongside systems that didn't have their own console.

This is further complicated by the fact that many terminals could be configured to emulate others. The Visual 50 I used in my first job didn't have its own control sequences but could be a DEC VT-52, LSI ADM-3A, Hazeltine Esprit and ADDS Viewpoint. It would be hard to go wrong with the VT-52/100 or ADM-3A.

  • Er, yes, I know that most devices had built in terminals, and that most programs allowed configuration; I believe I mentioned that in the question! And re not being able to go wrong with the VT52 --- most of the software I've found is not preconfigured for the VT52, hence my question... – David Given Dec 4 at 14:59
  • @DavidGiven Point was that there were just as many systems that shipped without terminals and that most terminally-interesting programs didn't ship preconfigured at all. What you found in the Walnut Creek archive may have been preconfigured by a system vendor. – Blrfl Dec 4 at 15:25

Back in the 1980s, at our university we've been using CP/M machines with real serial terminals a lot, and most of them ADM-3A or compatible ones. I don't remember any incompatibility. Many screen-oriented programs had to be configured to use the correct escape sequences, but ADM-3A was always supported or could easily be configured.

And I liked programming with the ADM-3A escapes: they were a lot more compact than the VT-100 family ones, meaning much faster over a 9600-baud serial line.

Another common command format was TVI-950 which IIRC was the basis for the later Wyse-50.

In 1985, I wrote a DOS CON: driver terminal emulator for use with a networked CPM 2.2 ISA card to run WordStar. I chose to emulate TVI-950 because it had line insert and delete which VT52 didn't (and I don't think ADM 3A had either).

I agree with Ralf Kleberhoff that the ANSI emulation (VT100 and later DEC models) was verbose and more difficult to parse in assembler.

As noted in various ways by others, the ADM-3A was very popular (I used them at the University of Maryland in the early 1980s), but more importantly they were one of a handful of de facto standards. Most of the Wyse terminals (starting with the Wyse 100 - I had two of those - my first video terminals, beautiful machines, but I digress), plus quite a few others. The escape sequences were fairly straightforward and easy to use & to emulate, which should make it a good choice for a memory-constrained emulation.

My impression of the VT-52 and VT-100 is that the control codes were better designed, but also more verbose - e.g., many functions Escape + a printable character where the ADM-3A (and Wyse, etc.) would use a single non-printable (< 32) control code and particularly direct cursor position - on the ADM-3A (and Wyse, etc.) 4 characters: Escape = row col - where row & col are single bytes, but on the VT-100: Escape [ row ; col H - if row & col >= 10 then that's 8 characters instead of 4, and to emulate it you have to convert decimal (text) to binary. That also makes a significant difference on a low-speed (e.g., 300bps modem) but it helps a little even with a direct connection at 9600bps.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.