How did TUI's worked with CP/M

[etcher-sage]

I'd been searching around looking for how applications like wordstar, used the screen as a 2D grid (of 80x24 character) to produce user interfaces, or further full GUIs in some cases. And from what I've found it seems that CP/M itself didn't have the capabilities for such a thing directly, and because of this most applications that did have TUIs (or GUIs) had to be configured for each systems hardware individually. With all that in mind, I haven't been able to find any documentation on how they accomplished it. Even if not for my specific system, I'd like to understand the concepts behind how to create a TUI for a CP/M based system. Ideally I'd like to, eventually, be able to replicate the effects on other systems specifically a Northstar Advantage system to name one.

I apologize if this question is too vague, I'm mainly looking for a point in the right direction here- just feels a bit like I've hit a brick wall in finding information on it. Any resources or advice would be greatly appreciated, thank you.

Any resources would help allot, be it: books, websites, ideas, examples, or even word of mouth

edit: just noticed my grammar died in the Title, meant to be "How did TUI's work on CP/M systems?", rip

 

[ajacocks]

Welcome to the forum @etcher-sage !

- Alex

 

[Chuck(G)]

I hate to be the bearer of bad news, but each application had its own customization procedure. Thus, for Wordstar, there's a "patch area" that can be modified for the terminal type (there's also an installation program that has several common "canned" patches).

You must appreciate that CP/M got its start in the "dumb terminal"/TTY era, as did many applications.

 

[durgadas311]

Many CP/M systems used serial terminals, so it was not always tied to the platform but rather the terminal(s). Some applications made provisions for systems that had "memory mapped video", but many were strictly serial terminals (ESC sequences, etc). Some systems performed a terminal emulation in their BIOS, so applications oriented towards serial terminals could work on systems with memory-mapped video (the Kaypro comes to mind, but there are others).

 

[Plasmo]

The integrating video/keyboard capabilities into CPM is something I’m actively working on last month or so. I have I/O mapped PS2 keyboard and 4K I/O mapped video display. Like others have said, you need a custom BIOS for the specific video/keyboard hardware. In my case I needed about 1K additional BIOS space to implement PS2 scan code tables and VT52 escape sequences. VT52 is fairly simple, I can’t imagine what full VT100 is like. I have no idea how WordStar was able to accommodate myriads of terminals of its time.
Bill

 

[Petrofsky]

Take a look at the Turbo Pascal 3.0 manual, appendix L, pp. 345-354. You can see the TINST program had a menu of 26 terminal types to choose from, plus an extensive questionnaire to deal with anything not on the list.

One approach you could take is to just use the TINST program, slightly modified so that after gathering the data, instead of using it to patch the Pascal executable, it writes the data out to a file that your executable reads.

And from what I've found it seems that CP/M itself didn't have the capabilities for such a thing directly

The same could be said about UNIX, but in that world, a standard language for describing any terminal's capabilities eventually emerged (termcap), and then applications just needed to read the terminal's termcap description and behave accordingly.

 

[Chuck(G)]

To the point: how many terminal types are listed in termcap or terminfo?
An example of what happens when there aren't any standards.

 

[cj7hawk]

CP/M system wasn't designed to have anything fixed in the TPA between the zero page and the BIOS start except for the BDOS and the CCP which were both fixed in size and code.

It's possible to implement such a scheme in the BIOS, but it's going to get fairly large, fairly quickly. Since CP/M doesn't need the full 64K however, using memory above the BIOS is a good strategy. The OSBORNE 1 did this, and has a 128x32 video map in 4K of space of which 52x24 is active, though this actively moves around inside that 4K space and can literally be anywhere, so writing this space directly results in issues since unless you work entirely outside of the BIOS, you can't be sure if you're in the active video space or not, and pressing keys and the like is very likely to shift this video space around.

Other systems used paging to keep things out of the TPA. I think the ZX Spectrum version of CP/M does that - as the TPA doesn't seem affected, so I assume they are paging it in and out of the lower memory to write on it, though they also might be paging it into upper memory which is also possible on that mode - which is notable, because that model had a bitmapped screen.

The easiest way to do what you are trying to do is to emulate a character mapped screen ( I assume TUI is Text User Interface, but CP/M is also designed for GUIs after version 3 with the Graphical Extensions ) - This extended the BIOS and allowed for polylines, vector graphics, polygons etc, and was the basis for GUIs like GEM.

This may be why what you're doing is a little more challenging to find information on - Perhaps you should build your screen model over a terminal emulator?

Which brings up the question I have - is there any advantage to using more than VT52? I know other terminals offered more, but did any notable software require more than this?

David.

 

[Chuck(G)]

You can do things with less than a VT52. In terms of terminals used with CP/M, perhaps the most common was the ADM-3 and associated terminals (e.g. Kaypro). The problem with the VT52 (and VT100) is that they weren't cheap, when compared with the likes of a Wyse WY50 or Hazeltine 1400.
I customized Wordstar to a terminal without direct cursor addressing (only up/down/right/left one position).

The most annoying were the cheap terminals that used a character position for attributes (e.g. intensify). You'll see mentions of that in termcap.

 

[Petrofsky]

I'd been searching around looking for how applications like wordstar, used the screen as a 2D grid (of 80x24 character) to produce user interfaces, ..., I'd like to understand the concepts behind how to create a TUI for a CP/M based system.

The responses from Plasmo and cj7hawk seem to be answering a different question, of how one might go about extending CP/M to provide direct access to screen RAM.

To be clear, writing an application like Wordstar or Turbo Pascal that ran on many different systems and provided a 2D text interface did not require any direct access to video RAM on any system. Those applications worked by outputting a linear sequence of bytes, which were then interpreted as directives for updating a two-dimensional array of character cells on a CRT. Whether the bytes were interpreted by a separate, dedicated terminal or by code running on the same CPU as the application was immaterial to the application writer.

What did matter to the application writer was what bytes meant what. That is, all the questions that the Turbo Pascal TINST program asks, like "which byte do I write to clear the screen?", etc..

Which brings up the question I have - is there any advantage to using more than VT52? I know other terminals offered more, but did any notable software require more than this?

For any sort of full-screen text editor, you would want insert-line and delete-line, which the VT52 lacked. Without them, adding or deleting a line in the middle of the screen would require rewriting half the screen. While Turbo Pascal didn't require them, the manual (linked above) warned about the slowness you would experience if your terminal didn't have them.

 

[cj7hawk]

Even if VT52 lacked many functions, many terminals seem to have built on top of this and added extra escape sequences.

I've had a difficult time finding a clear set of escape codes written with definitions so that they can be easily implemented into a video terminal emulator. If you know of any links, please post them. Mostly I have to trawl through terminal operators manuals, which are written more from the perspective of the software writer rather than the video manufacturer.

David.

 

[Chuck(G)]

When I wrote the firmware for the Fortune Systems text terminal, I used several documents, mostly because of vendor's requirements. So, the VT100 manual, which describes VT52 codes as well, Teletext standard, and the Videotex standard. "Combo characters", i.e. characters with diacritic markings as well as some combinations were the most interesting to me.

Said terminal was Z80-based. I still have the prototype, sans keyboard.

 

[whartung]

I've had a difficult time finding a clear set of escape codes written with definitions so that they can be easily implemented into a video terminal emulator.

For which terminals? ANSI/VT100 is well documented, there's several terminal manuals around for the various types of terminals.

If you want one stop shopping, search for terminfo. The terminfo library has a zillion terminals. You'll need to read the (extensive) man page for terminfo to decipher the, but it has just zillion terminals and variations. My Mac has over 2800 of them. Terminfo compiles its entries into a binary form. infocmp will dump them out.

This is the one for pcansi on my machine:

$ infocmp pcansi
#    Reconstructed via infocmp from file: /opt/local/share/terminfo/70/pcansi
pcansi|ibm-pc terminal programs claiming to be ANSI,
    am, mir, msgr,
    colors#8, cols#80, it#8, lines#24, ncv#3, pairs#64,
    acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
    bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, clear=\E[H\E[J,
    cr=\r, cub1=\E[D, cud1=\E[B, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch1=\E[P, dl1=\E[M,
    ed=\E[J, el=\E[K, home=\E[H, ht=^I, hts=\EH, il1=\E[L, ind=\n,
    invis=\E[8m, kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
    kcuu1=\E[A, khome=\E[H, op=\E[37;40m, rev=\E[7m,
    rmacs=\E[10m, rmso=\E[m, rmul=\E[m, setab=\E[4%p1%dm,
    setaf=\E[3%p1%dm,
    sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;12%;m,
    sgr0=\E[0;10m, smacs=\E[12m, smso=\E[7m, smul=\E[4m,
    tbc=\E[3g,

Just to give you an idea of what you're getting into. But, point being, if you want the info, it's out there, and terminfo makes it all readily digestable.

It should be noted that I believe many modern Linux distributions release a very abbreviate terminfo dataset, since everyone is running ansi or xterm.

So, if you fire up a random distro in a VM, it may not have a terminal you might be looking for. But the full set is out there.

 

[Chuck(G)]

Termcap is my (old guy) speed. Stallman has a nice write-up here. Termcap is somewhat deprecated, but still is current on several Unix distros. Bill Joy is given credit for its development; I never knew that.

 

[whartung]

Termcap is more obsolete than Terminfo. NCurses and Terminfo are bound at the hip, and if anything, modern termcap entries are backported from Terminfo, but Termcap does not have all the facilities that Terminfo supports.

For the two or three terminals someone is likely to want to support, it probably doesn't much matter, but Terminfo is more up to date and better documented today.

 

[Chuck(G)]

infocmp -C will search the terminfo database and deliver a termcap definition. I find them more readable, that is, if any terminal definition can be so classified. Mostly that's because when I was working with terminals, I was using BSD. AFAIK, infocmp is packaged with most Linux distros.

Example:

$ infocmp -C vt52
#	Reconstructed via infocmp from file: /lib/terminfo/v/vt52
# (rmacs/smacs removed for consistency)
vt52|dec vt52:\
	:bs:\
	:co#80:it#8:li#24:\
	:K1=\E?q:K2=\E?r:K3=\E?s:K4=\E?p:K5=\E?n:bl=^G:cd=\EJ:\
	:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :cr=\r:do=\EB:ho=\EH:k0=\E?y:\
	:k1=\EP:k2=\EQ:k3=\ER:k5=\E?t:k6=\E?u:k7=\E?v:k8=\E?w:\
	:k9=\E?x:kb=^H:kd=\EB:ke=\E>:kl=\ED:kr=\EC:ks=\E=:ku=\EA:\
	:le=\ED:nd=\EC:nw=\r\n:sf=\n:sr=\EI:ta=^I:up=\EA:

But if you like the terminfo format, just omit the "-C":

$ infocmp vt52
#	Reconstructed via infocmp from file: /lib/terminfo/v/vt52
vt52|dec vt52,
	cols#80, it#8, lines#24,
	acsc=+h.k0affggolpnqprrss, bel=^G, clear=\EH\EJ, cr=\r,
	cub1=\ED, cud1=\EB, cuf1=\EC,
	cup=\EY%p1%' '%+%c%p2%' '%+%c, cuu1=\EA, ed=\EJ, el=\EK,
	home=\EH, ht=^I, ind=\n, ka1=\E?q, ka3=\E?s, kb2=\E?r, kbs=^H,
	kc1=\E?p, kc3=\E?n, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
	kcuu1=\EA, kf0=\E?y, kf1=\EP, kf2=\EQ, kf3=\ER, kf5=\E?t,
	kf6=\E?u, kf7=\E?v, kf8=\E?w, kf9=\E?x, nel=\r\n, ri=\EI,
	rmacs=\EG, rmkx=\E>, smacs=\EF, smkx=\E=, u8=\E/[KL], u9=\EZ,

It should be noted that not all of a terminal's capabilities are in termcap/terminfo. For example, block-editing functions aren't usually included. Some definitions are really sparse, such as that for the IBM 3270:

#	Reconstructed via infocmp from file: /usr/share/terminfo/i/ibm327x
ibm327x|line mode IBM 3270 style,
	gn,
	clear=\r\n, el=\r, home=\r,

 

[whartung]

For example, block-editing functions aren't usually included.

I've never seen anything use block editing in the Unix world. I remember fiddling with it long ago on a...Espirit III? Televideo? Doesn't really matter.

Block terminals are a complete different world than smart "glass tty", and they're for a quite different use case. They were much more appropriate for much slower hardware where simply keeping up with the typing of an interactive user was a load on the system. Block terminals did everything locally, and sent the entire page in bulk. Also worked better, I think, over very long distances.

We were able to support 150 users @ 19.2 on a '030 with "smart" serial cards back in the day.

 

[Bob-O-Rama]

I'd like to understand the concepts behind how to create a TUI for a CP/M based system. Ideally I'd like to, eventually, be able to replicate the effects on other systems specifically a Northstar Advantage system to name one.

First off, the Northstar was just... wow - a different animal - wish I had one. My only experience with them was long ago and with the Z80 version. I'm sure you can find a manual for it on archive.org, etc. which details the video architecture. ( I won't go into it, as I am sure I'll get it wrong, but they had bit mapped video RAM arranged vertically - which was very unusual. ) They did have BIOS routines for writing text and also supported cursor management - so like a really bad serial terminal.

Point being, every architecture was different, and this was more different than most. So as a developer it was all bespoke. Wordstar and other vendors would abstract the video interface into a library - and sometimes tool makers would make libraries for developers to use to make porting easier. You occasionally see these advertised in old computer rags of the day.

 

[Bob-O-Rama]

Block terminals are a complete different world than smart "glass tty", and they're for a quite different use case. They were much more appropriate for much slower hardware where simply keeping up with the typing of an interactive user was a load on the system. Block terminals did everything locally, and sent the entire page in bulk. Also worked better, I think, over very long distances.

The other advantage to block terminals is that most systems using a front end processor ( or software equivalent ) would record and keep the received terminal pages as a form of replayable journal. Say mid day your system crashes. You restore to a backup from last night. Then prior to letting users back in, you have the FEP replay all screens - on order received - since the backup. After the screen replay was complete, the system is in the same state it was prior to the crash. Now you re-enable your on-lines and people are back in business without losing anything.

 

[Chuck(G)]

Some of the early word processors (e.g. CPT) used the block-edit feature also. You loaded a page, edited it, then sent it back to the CPU.

Another advantage, often seen in the transaction world, was displaying a form, allowing the user to edit only certain fields, then sending the completed form back for processing.