- 12/26/2017 – Fixed some typos, adding some section headers.
Years ago, I created the EthaWin user interface for the Radio Shack Color Computer 3 running OS-9. This is its story…
A GUI for the Rest of Us
At the time, the main GUI for CoCO OS-9 apps was something called MultiView. MultiView was sold separately from OS-9 and no runtime version was available, so anyone who wanted to sell a MultiView app could only sell it to users who also owned MultiView. This certainly limited the potential market for MultiView apps, and probably explains why there were never as many GUI-based OS-9 apps as there could have been.
Another issue was performance. When running OS-9 on a graphics screen, it was pushing around far more data than an 80×24 hardware text screen required, and thus most of us never really used the graphical displays unless we really needed proportional fonts and other features. (Yes, back in the 1980s, there were proportional screen fonts for an operating system running on an 8-bit home computer. I guess we just took it for granted at the time, but it seems really forward thinking in retrospect.)
It also goes without saying that running a 640×225 graphic screen chewed up more of the limited system RAM than a text screen, as well, making things quite a tight fit on a 128K CoCo 3 if you had multiple windows and programs open.
One of the last obstacles MultiView faced was the learning curve. Setting it up and using it was not really any different (or any more difficult) than any other OS-9 program, but programming it was another issue. Really smart programmers didn’t seem to have any problem creating MultiView apps in BASIC09 or C or 6809 assembly. I, unfortunately, was not one of those. Reading the documentation in the MultiView developers manual made my head spin. I am not sure I even knew C programming yet, so many of the concepts were completely lost on me.
So, with all this in mind, I decided to create “the user interface for the rest of us.” I wanted something that gave the advantages of a GUI — a menu bar with pull down menus, pop-up overlay windows, and mouse control. I also wanted it te completely and easily usable from the keyboard (something MultiView, and many modern operating systems, do not provide). It also had to be fast, and use very little memory. And most importantly, it had to be super simple to program for so anyone could create programs to use it.
A GUI without Graphics
I realized that most of the GUI applications I had really didn’t need to be on graphical screens. They were just programs with mouse support. Apps like this could just as easily run on a text screen if there was some way to give them a menu and mouse system.
My solution was to build EthaWin, which would operate on a high-speed, low memory text screen. I would make use of OS-9’s powerful terminal capabilities which included things like overlay windows and locking the working area so you could scroll just some parts of the display without effecting the rest.
I would create a menu bar at the top, and the user would be able to use a mouse (moving a cursor block around) to pull down any menu and make a selection. Or, they would be able to use the ALT-key to select a menu, and arrow keys to move between options (or between different menus).
I wrote EthaWin using the original OS-9 K&R C compiler, and designed it so all the developer had to do was set some variables and create some arrays which represented the menus and their options. It was super simple C code, and it worked great.
The first (and probably only) EthaWin app that was created was a disk utility I wrote called “Towel.” It quickly became one of the pieces of software I used more than anything else, since it greatly simplified the process of selectively copying files or doing other common operations. It sold very well, and I hope others found it as useful.
MM/1 K-Windows EthaWin
EthaWin was later ported to OS-9/68000 on the MM/1 computer, which always operated on a graphical screen (like a Macintosh or Atari ST or Amiga did). The code worked the same way, but graphics commands were used to decorate the menus and make things look more like a traditional GUI. The MM/1 also had an on-screen mouse at all times, so it used that instead of the cursor moving trick I did on the CoCo’s hardware text screen.
In 1995, I took a full-time job with Microware Systems, the creators of OS-9. Sub-Etha Software shut down to avoid a conflict of interest, but that didn’t stop me from trying to do more with EthaWin.
At Microware, we all had SUN Workstations, and used green screen terminals to hook to various OS-9 boxes via serial ports. After seeing some of the rather fancy curses Unix apps that did all kinds of windowing type things via a terminal session, I set out to port EthaWin to generic OS-9/68000, using nothing but the Termcap library. Termcap (terminal capabilities) was a standard way of presenting different types of screen control codes, such as VT100 or ANSI. A Termcap program would read an environment variable to learn what kind of terminal the user was using, then it would load the specific codes for that terminal from a definition text file. A Termcap program could clear the screen or move the cursor, without needing to know what escape sequence did that for the user’s terminal.
The approach I took to port EthaWin to Termcap was to write a new library, which I called TCWin (Termcap Windows). I created Termcap versions of all the standard CoCo OS-9 library calls that did things to the screen, such as turning bold on, or underline off. I figured once I had all of those, none of the rest of my source code would need to be touched. Much.
On the CoCo (and under K-Windows on the MM/1), overlay windows were managed by the system, so if you drew one, used it, then made it go away, whatever was under it would be restored. While there were some terminal protocols that offered things like this, I could not rely on that. I decided to create a buffer to represent the virtual screen, with bytes for the character and its attributes (blink, bold, underline, etc.). My routines would draw to this buffer and then the buffer would be updated to the terminal screen, and if I created an overlay window, I would create a new buffer for that, and be able to restore what was under it since the original screen buffer still existed.
I thought it was a very clever solution, and other than having to create some new wrapper functions for printing to the screen and disabling mouse functions, it worked. All functions of the normal EthaWin could be used, including scrolling. The TCWin library, when used by itself, could even do some things that the CoCo version could not do, such as having independent control of any window on the screen. (On the CoCo implementation, once an overlay window was created, all I/O went just to that window and you couldn’t use any background windows until you closed the overlay.)
Just for fun, while on a work trip to Rochester, New York, I sat around with an old CoCo friend of mine one night (who had long since moved to PCs) and ported EthaWIn yet again, this time to run on a DOS screen. Sadly, the code for this port was lost with a Toshiba hard drive crash soon afterwards. That was when I became aware of the concept of backing up hard drives…
But I digress…
I could (and maybe will) write a whole series of articles on how I created this environment, but instead, I wonder… Could I port it to an Arduino? I have plans to dig out the old code and rewrite/update it for the CoCo, to use as part of my CoCo Ethernet experiment, so why not also update it for other uses?
I could not find an implementation of Termcap for the Arduino, but that’s not really important. The only capability I really need is the character sequences for certain functions (clear, cursor move, etc.) for whatever terminal types I plan to support. Initially, I might say I will only support VT100 and ANSI (very common for Unix and PCs). Then, someone could telnet in to an Ethernet Arduino, or connect using a good terminal program (not the crappy serial monitor that’s part of the Arduino IDE), and run apps more in the style of Unix — with nice text screens and menus and such.
There are some technical challenges in doing this with just 2K of RAM. Since I was previously caching a full copy of the window (and attributes) as well as overlay windows, I might have to give up some of that support. But I think some of the basics could be supported.
We shall see.
If I do decide to work on this, I will create a new category for EthaWin posts so those interested can follow my progress (or lack thereof).