One year after it’s initial creation, the Terminals Wiki has basic data for approximately 550 different terminals.
New data is being added on a regular basis, providing a central location where data from bitsavers, manx, google books and other sources can be concentrated for each type of known terminal.
A common workflow for me has become:
- scan terminals manuals
- upload manuals to bitsavers
- add new bitsavers links to manx
- link new manx documents to the terminals wiki
I’ve recently prototyped a set of mediawiki templates for summarizing the command (ESC) sequences received and transmitted for the different personalities of a terminal. This will provide a quick visual means of comparing the control sequences between two different terminals and give an indication of the complexity of a particular terminal.
So what does this have to do with the graphics museum? Many terminals contained some sort of graphics capability and many early users of computer graphics knew it only through the display capabilities of the terminals they used.
Beyond the historical tie-in, my experience in building the terminals wiki will be applied towards creating a Graphics Wiki, a place where a history of computer graphics can be incrementally constructed through a set of cross-linked articles. Where appropriate, interwiki links will provide a unified view of graphics terminals along with other hardware in the graphics wiki. While this blog provides a way to make casual announcements and posts, it isn’t suitable as a long-term organized reference like a wiki.
I wanted to bring a terminal that I recently discovered, the Alphacom.
http://vintagecomputer.net/browse_thread.cfm?id=502
I got this from the son of a former Alphacom salesman. Pretty interesting story. I’d like to know more about this terminal, if you have any docs, etc. Thanks.
b
Wow, that is certainly an interesting terminal! I don’t have any information on this particular terminal, unfortunately.
Given it’s age, the display memory is either ferrite core memory, or early static RAM. Generally 2048 bytes are enough to supply a terminal with all it’s character memory and a little scratchpad, assuming it is displaying at 80×24. On one of your pictures I counted 25 lines of 72 characters each, for a total of 1800 characters. Since this terminal appears to be upper-case only, they may only be using a 6-bit code for each character stored in the display memory. With 6-bit codes, you have enough combinations to represent all the symbols shown on the keyboard. If this terminal has the ability to define a form on the screen, then there will be additional bits used to represent the structure of the form.
Judging from pictures of the keyboard, I believe this terminal only displays upper-case characters. Notice that
[,\, and]characters are shown on the K, L, and M keys. In the ASCII character encoding, you get the code for[by taking the code forKand ORing0x10to it. Following this progression, I infer that the “up arrow” shown on the N key is not a cursor movement key, but the symbol for^, which you get by ORing0x10to the ASCII code forN. Similarly, shiftedO(oh) will give you_and shiftedPwill give you @. Now, the P/@ combination is a little more interesting because it’s actually P that you get from @ by ORing in0x10, so in this case, they have simply switched the sense of what the shift key does with respect to the code generated! The digit and symbol keys also reflect the idea of SHIFT simply ORing in another bit into the generated character code. Like many early terminal keyboards, there doesn’t appear to be any means of generating the characters in the range0x60through0x7E(`backquote or accent grave, the lower case letters and the symbols{,|and}). The RUBOUT key almost certainly generates ASCII0x7F, generally referred to as DELETE.The terminal’s intelligence is almost certainly implemented as a simple state machine via small-scale integration 7400 series chips. While I don’t have design information on this specific terminal, all the terminals I have studied have very similar designs. The Beehive B100, and the Basic Four 7220 both have discrete logic controllers implemented as state machines. The documentation linked through the wiki has circuit diagrams and descriptions of the state machine implementations. You will find that there are two parts to the controller: refresh and edit. The refresh portion cycles continuously through memory, reading out character data and feeding it to a character generator circuit to obtain a bit pattern that is used to generate the video signal. The edit portion of the controller interfaces the keyboard and the communication circuits to deposit characters into display memory, or read characters from display memory and transmit them.
Just stumbled on your wiki while looking for info about TEC terminals, which I used as the operator terminal on a Harris H135 and H500.
Great site. Any interest in non-American terminals, for example ICT/ICL mainframe terminals?
All terminals are welcome on the wiki! The scanned issues of Computerworld and InfoWorld on Google books are my primary source of information and being US publications they don’t often have much about non-US terminals. There is a contributor who has written about Tandberg terminals, but I think that’s the only foreign terminal manufacturer listed so far.