Previously, I mentioned a bit about the ancient termcap system which is used to send display codes (clear, move cursor, underline, blink) to terminals of different kinds. In this modern GUI world, none of this is necessary … folks pretty much have to rewrite the whole program to work with native Mac, Windows, Linux, Java, etc. I suppose the modern equivalent to termcap would be a cross platform GUI (kind of like a graphical termcap?) which turns things like “create a pop up window” or “create a menu with the following options” in to whatever it takes to display them on the end operating system.
I suppose that’s truly what I should be learning right now — my program could make use of graphics on the Linux-based Raspberry Pi, Windows or Mac. However, since my program is not intended to be a windows-based program (no pull down menus, no mouse, etc.) and really had no use for graphics, I decided to write everything using text.
My original prototype was rather bland, spitting out 80 column descriptive text. This was perfect for debugging, but certainly not what we want the end-user to have to deal with:
By writing the application as a strict ANSI-C program, and just using text, it would compile and run on a Windows PC as well, in a DOS-style COMMAND window (CMD.EXE):
The target system for this project would be Raspberry Pis, the $25-$35 micro-Linux computer designed for educational use. We would be using the $35 model, which has more RAM (512mb) and USB/ethernet. The Pis support HDMI and composite video output. Instead of using large (pricy) HDMI TV/monitors, I found tiny composite color monitors for under $20 (4.3″, about the size of a GPS unit or large smartphone screen).
By setting the resolution of the Pi to match the display’s 480×272 resolution (/boot/config.txt: framebuffer_width=480 and framebuffer_height=272), and by choosing the largest font available (setfont /usr/share/consolefonts/Uni3-Terminus32x16.psf.gz) I was able to get a large, easy to read (on the tiny screen) 30×8 display. It would look something like this:
+------------------------------+ |123456789012345678901234567890| |2 | |3 | |4 | |5 | |6 | |7 | |8 | +------------------------------+
The actual screen ends up much wider than this text drawing, since the displays I am using are 16×9 widescreen.
Have you noticed the lack of mentioning Termcap so far? Let’s correct that now.
If I was going to be using this particular screen and run on just a Raspberry Pi, I could just hard-code everything to expect 30×8 characters, and whatever display codes were needed to clear the screen or change colors.
And that would be bad programming. Doing this “because this is all it is planned to ever run on” is like not having insurance because you never plan to get in an accident. It’s certainly fine to write anything for yourself any way you darn well please (I do that all the time, too), but I try to think ahead and write things to be as portable and as flexible as I can.
Fortunately, I wrote such portable code back around 1995. At the time, I had created a text-based user interface called EthaWin. It was written for OS-9 Level 2 on the Tandy Color Computer 3, and later ported to the OS-9/68000 MM/1 computer. The CoCo 3’s terminal window system supported all kinds of screen codes for basic things like color, blinking, move cursor, etc., much like ANSI graphics on a PC did. The MM/1 was meant to be a next generation replacement for the CoCo OS-9 users, so it’s K-Windows system replicated (and expanded upon) those same screen codes.
My EthaWin was not the “portable code” I am speaking of. It would only run on a CoCo or MM/1 under OS-9. When I began working for Microware, the company that had created OS-9, none of my stuff would run on the “headless” OS-9 computers in the building — most didn’t even have video displays. The way you accessed them was via an RS232 serial port and a hardware terminal (or software terminal program), or from telnetting in across the network.
OS-9, being created as a very Unix-like operating system, supported termcap, and text editors like vim, uMacs, etc. made use of this to give full screen editing. If I wanted EthaWin to work on these OS-9 machines, I was going to have to learn how termcap worked.
In the next installment, I will finally talk about termcap and show how very simple it is to do very simple things.
Pingback: Using Termcap – part 3 | Sub-Etha Software