6502.org

VT-100 CONSOLE FOR HOMEBREW COMPUTERS

Ever since I designed and built POC V1.0, I’ve used a serial-interfaced, "dumb" terminal as the system console.  First it was a WYSE 60, then an ADDS 260LFC, and now a WYSE thin client in WYSE 350 emulation mode.  These have all worked out well, but I have really wanted my computer to be a "stand-alone" unit not dependent on another computer or computer-like-device to operate.

Part of that goal was realized (more-or-less) in 2012 when I built a SCSI host adapter and thus was able to attach mass storage to POC V1.1.  However, POC V1.1 and the units that followed were still dependent on a terminal for a console.  I needed to devise something that would allow me to integrate display and keyboard I/O and thus break free of the bonds chaining me to a terminal.  That started me on a long process of evaluating different approaches to video output and keyboard input.

An early step was to look at the Picasso video display module.  I purchased one and played around with it a bit but for various technical reasons concluded it wasn’t suitable for my application.  I gave it away.

Next, I looked at the MicroVGA unit, which drives a VGA monitor and accepts input from a standard PS/2 style keyboard.  It mostly behaves as an MS-DOS ANSI.SYS console and based upon the information given on the MicroVGA website, I purchased one.  It worked as advertised, but was not very satisfactory.  It has a poor mechanical layout—the keyboard socket is jammed right up against the video receptacle, which is a problem with the Key Tronic keyboards I use (and sell)—and the character set’s font is horrid and for me, difficult to read.  I still have it on my shelf collecting dust.

In late 2014, I became aware of an Australian gentleman, Geoff Graham, who had developed some interesting applications for Microchip’s PIC microcontroller (MCU), one of them being an ASCII terminal that implements most of the VT-100 command set, plus some graphics extensions.  The hardware design is straightforward and uses only readily-available components.  The only specialized device is the PIC PIC32MX250 MCU, which can be purchased with the requisite firmware already loaded.

At the time of this discovery, I was very busy with other (money-making) things, and hobby computer stuff languished.  Finally, in the latter part of 2017 when things had slowed down, I decided to proceed and procured a bare PCB and flashed PIC.  However, before the parts had arrived, I experienced a little medical malady that brought everything to a halt.  The parts took up residence next to the MicroVGA unit.

Fast forward to late 2019 and now I was working on the design for POC V1.2, which was to serve as a guinea pig for testing some hardware concepts (Jeff’s clock stretcher being one of them). I decided now was the time to get the VT-100 terminal off the shelf and into operation.  I completed its assembly yesterday and gave it a test.  It works as advertised.


This unit is designed to be powered by a 5 volt source and driven by a serial interface running at TTL levels.  Although the PIC and associated circuitry operate at 3.3 volts (there’s an on-board regulator to produce the 3.3 volts), the serial-in connection is 5 volt tolerant and in fact, could be directly connected to a TIA-232 level output without damage.

The terminal understands much of the VT-100 command set, and includes the cursor-addressing functions.  Also included are the commands for clearing part or all of the display.  Absent in firmware versions prior to V1.3 are the functions for turning off and turning on the cursor, which is not a deal-breaker for me.

In addition to character-oriented features, the terminal has pseudo-commands that can generate graphic lines, rectangles, circles and filled areas, all of which are plotted in terms of pixels from the 0,0 coordinate, which is the top, left corner of the display.  Notably absent are the alternate characters that produce box drawing glyphs, such as ┤ or └.  These will have to be simulated by using the graphics commands.  Any use of the graphics features in assembly language will require four-function integer math, which is not too difficult to implement on the 65C02/65C816 (there is code around here that can be used).

As far as construction goes, purchasing a PCB instead of laying out one and having it made was a less-expensive and less-time-consuming route, and virtually eliminated the likelihood of a DOA unit due to a design defect.  The unit required about three hours assembly time and worked on the first try.

On his website, Geoff has published the schematic, parts list and firmware for this gadget, which means it is possible to integrate the terminal into a larger design.  I plan to do exactly that in a future iteration of my POC series, which will result in the unit truly being stand-alone.  For now, POC V1.2 has its console channel arranged so I can patch the terminal in and test it under actual operating conditions.

Now for the interesting part.  Geoff also released the source code for the PIC32, which I have studied in some detail out of curiosity, but also with a half-formed plan.  Truth be known, I have never liked the VT-100/ANSI/ECMA48 control set.  It’s a classic, design-by-committee mess and due to the general structure of the commands, e.g., <ESC> [<v>;<h>H to plot the cursor (<v> is the row and <h> is the column, both being 1-based), results in more serial I/O traffic than later and more modern command sets, such as that implemented by the WYSE 60/150/160/GPT/325 terminal series (in contrast, plotting the cursor on a WYSE unit is <ESC>=<v><h>, which is also assembly language-friendlier, since <h> and <v> are one-byte binary, not multiple ASCII numerals).

So, my eventual interest would be in replacing the VT-100 commands with their WYSE 60 equivalents.  Not only will the terminal run faster because of the reduced workload (no ASCII-to-binary conversion needed), less flash memory will be needed to store the code, since the resulting command look-up table will be smaller and command parsing will be less complex.  This latter has to do with fact that the actual command "word" is at the end of the sequence, e.g., H in the cursor plotting command, not the beginning as it is in the WYSE command set, necessitating that a command be parsed in reverse.

First thing though will be to integrate the terminal into a future version of POC V1.

————————————————————
EDIT: The MicroVGA website appears to be up again.

That is actually pretty interesting. And it looks like it wouldn't be too hard to make it understand BBC VDU codes instead of minicomputer rubbish.

I'm not familiar with the BBC VDU, so I can't opine on ease or difficulty. The process would fundamentally be the same as implementing the WYSE 60 command set, in that a leading <ESC> would be used to indicate that a command follows. You could use almost any method as long as a command can be unambiguously identified in the incoming data stream.

Where the VT-100/ANSI/ECMA48 method is a pain is in it using ASCII numerals that have to be internally converted to binary to be usable, as well as the general "wordiness" of commands. ASCII numerals make it friendly for someone writing code to run on a DEC mini, but not so friendly for the bloke writing the terminal's firmware and trying to parse a command whose command "word" is the final character of the sequence.

What I like about WYSE's approach is the character immediately after the <ESC> tells the terminal what it is supposed to do and also indirectly tells the terminal how many datums to expect after the command "word." That makes parsing much less complicated than in the VT-100 scheme. A sorted look-up table can be used to determine which command is to be processed and code specific to that command can then be run to parse the remainder of the command. Even in assembly language, it would be simple. Simplicity of implementation is why most general-purpose terminals have WYSE 60 emulation (also, the 60 was the most widely-used terminal right up until use of dumb terminals died out—I estimate I installed several thousand of them over the years).

As far as implementing a different command structure in Geoff's design, there are one or two source code files that would have to be edited and then the entire mess would have to be compiled and flashed. It would be akin to a bare metal project, except you'd be programming in C instead of assembly language (my understanding is PIC assembly language is pretty unfriendly). You'd also need a PICKit or similar to actually flash the MCU. That can be done in-circuit if a suitable header is present, as is the case on my unit.
BTW, here is a pic I took of the PCB before assembly.

Right, so the VDU commands are a lot like the WYSE ones, but approximately one byte shorter - because they don't have an ESC prefix. Instead the ASCII control codes (1-31) are more thoroughly used, as most of them are redundant in a post-1960s world. But some of them are well-defined in ASCII, but bizarrely not used by the VT, while they are used for their original purpose in VDU.

Anyway… there's not much hope of 100% BBC Micro compatibility in this little terminal device. But many of the VDU codes can be usefully implemented.

There are two cursors and windows, for text and graphics. The text cursor is defined in character cells, and the graphics cursor in pixels (or fractions thereof). VDU codes 4 and 5 switch text printing to begin at the text and graphics cursors respectively. Graphics plotting always begins at the graphics cursor. By default both the text and graphics windows cover the whole screen.

VDU codes 8, 9, 10, 11 (BS, HT, LF, VT) move the text cursor by one cell in each direction. Code 12 (FF) clears the text window, and code 16 clears the graphics window. Code 13 (CR) moves the cursor to the start of the current line. Codes 14 and 15 switch on and off, respectively, a "page mode" which halts the display after scrolling through a screen's worth of text.

Code 17, which takes one post-byte, sets the text colour. If the MSB of the post-byte is set, it actually sets the text background colour. For a monochrome display, only the least-significant bit of the colour value would be significant.

Code 18, which takes two post-bytes, does the same for the graphics colour. The second post-byte is similar to text colours. The first post-byte sets the plotting mode (eg. replace, invert, XOR, AND, OR); normally this is left at 0 for "replace".

Code 19 takes 5 post-bytes and is used for setting the colour palette and low-level programming of the video hardware. It's probably fine to just read and discard the post-bytes.

Code 22 takes one post-byte to change screen mode. This could be used as an escape to switch back to VT mode.

Code 23 takes nine post-bytes and is used to redefine characters in the screen font, nominally in an 8x8 matrix.

Code 24 is used to define the graphics window. Eight post-bytes provide the left, bottom, right, top edge positions in graphics coordinates, 16 bits each. Subsequent graphics operations (and text drawing from the graphics cursor) are clipped to that window.

Code 28 does the same for the text window. Only four post-bytes are needed, since the coordinates are in character cells.

Code 25 is the general graphics plotting command. Five post-bytes; the first gives the graphics operation to perform, the rest is just a pair of coordinates. A short history of coordinates provided to this command is used to complete commands that need more than one pair; eg. a triangle fill requires two history entries plus the new coordinate. There is a "move" command which does does nothing except update the history. The latest entry in the history serves as the graphics cursor.

Code 26 restores both windows to the full screen.

Code 29 moves the graphics origin, taking four post-bytes. By default it's at the bottom left of the screen (positive up and right).

Code 30 returns the text cursor to the top-left position. Code 31 takes 2 post-bytes and moves it to an arbitrary position.

Code 127 backspaces and rubs out the corresponding cell.

Code 27 (ESC) is unused.

I've skipped a few that aren't relevant…

Well, the VT-100 doesn't use the random ASCII control codes for other stuff because doing so would break strict ASCII compatibility - and when DEC was in its heyday, it was still far from being a "post-1960s world." I don't know how much vintage data-processing equipment ever really made use of the more esoteric control characters (I always got the impression that most of the gear used for that kind of thing was oriented towards IBM and EBCDIC,) but there would've been value in not breaking compatibility, even if you weren't going to make actual use of those functions.

Right, but what about the cursor movement codes? I see ESC sequences in the VT manual for performing those, when just one byte would suffice.

Unfortunately, if you're not relying on eight-bit transmission of what is technically a seven-bit character code, there aren't any places to fit in more elaborate one-byte cursor controls; aside from the really basic ones like tabs and backspace (which may well be interpreted as printing whitespace rather than just moving the cursor,) there are no direct cursor control codes in the set, and no free spaces to put any ($80-FF being not technically part of the standard.) ASCII was already well-established before anyone needed it to print to a screen (the very first standalone video terminal wasn't even announced until four years after the standard was established, and it would be well into the '70s before CRTs would really supplant teletypes in most installations,) so the makers of ASCII terminals just had to make do with what they had.

Which isn't to say that the VT-100 standard isn't over-engineered and an inefficient use of bandwidth; even DEC's own VT52 had a more condensed (if more limited) set of escape sequences. But eh, what're you gonna do?

Which could make them ambiguous in the real (i.e., ASCII) world where a common standard is required. What you have described is a very narrow and specific hardware example.

<ESC> was defined in the ASCII standard so a receiving device could unambiguously detect when the following character(s) are to be interpreted in some way instead of being sent on to be displayed. Even the Commodore 128 used escape sequences to affect the video in some fashion, thus insulating the programmer (BASIC or otherwise) from having to know anything about the video driver or the underlying hardware.

In the timesharing BASIC dialects that were developed during the minicomputer era (and are in use to this day), the abstraction was even greater. For example, to print flashing, reverse video text to the terminal, one could write PRINT 'BR','BB',"Flashing Text",'EB','ER' in their program and the BASIC interpreter would generate the escape sequences needed to turn on reverse video ('BR') and flashing ('BB'). Internally, the character string would be tokenized to <ESC>BR<ESC>BBFlashing Text<ESC>EB<ESC>ER, the <ESC> bytes telling the interpreter that the next two characters were a display control command. The programmer didn't have to know anything about the terminal's command language, as the interpreter would take care of that.

That said, this topic isn't really one about how to control a display. Whatever floats your boat is the right way to do it. However, standards do have a purpose and the use of <ESC> to tell a device that something special is coming is nearly universal in computing—for example, any printer that understands PCL is using escape sequences. It's been that way since I started back in 1970 and will probably stay that way into the foreseeable future.
...which is why the VT-100 command set evolved the way it did. DEC was a laggard when it came to adopting 8-bit serial transmission, opting instead to stick with 7 bits with parity. By the mid-1980s, parity in terminal interfaces was dying out (it really didn't have any purpose, as a framing or other error would immediately be obvious to the terminal user) and 8N1 had become the de facto standard. I can't recall the last time I configured a terminal server to use parity (parity does live on in some serial data acquisition devices, such as credit card readers).
Dunno about "over-engineered." More like "over-complicated." Even after 8-bit ASCII became commonplace, DEC stuck with their scheme, apparently as some form of vendor lock-in (it didn't work—WYSE and others added VT-100 emulation to their products).

As I earlier said, the more compact WYSE 60 command structure had a lot to do with that terminal's overwhelming success (also, the quality of its display was a factor). In a complex screen layout in which there are many fields requiring many cursor-plotting functions, bandwidth consumption on the slower serial interfaces of the 1980s was a real concern. For example, sending four bytes to position the cursor (WYSE) instead of eight (VT-100), multiplied by 15 or 20 such commands per screen significantly reduced bandwidth consumption in a large installation (in the past, I routinely installed systems with 30-40 terminals, all running off a single UNIX box). Reducing the total outflow reduced low-level kernel processing, since serial I/O in those systems was interrupt-driven.

Getting back to the topic, a change of terminal personality definitely can be done if one is familiar with C and knows the details of the terminal to be emulated. I understand that a development environment can be downloaded from Microchip's website and installed to write code. A PICKit is needed to flash the MCU. The genuine Microchip PICKit costs about 50 USD through the usual electronics sources. There are Chinese clones that vary in quality. As always, caveat emptor.

Part of my Ruby project has a BBC VDU to ANSI converter so I can drive Minicom on my desktop from Ruby and have it understand all (almost all) the standard VDU commands including a function key hack/remap o-tron. That happens inside the ATmega host processor though but it wasn't hard to put together. If you can upload a new image to the PIC then it should not be too hard.

At boot time Ruby detects an ANSI terminal or a Ruby Terminal - the latter is my own SDL terminal application that runs on my desktop that does the VDU decoding directly.

this:

https://www.youtube.com/watch?v=rPGCT0lah4Q

is a C program running on Ruby that draws circles. the circle drawing is just:
which ought to be familiar enough to Beeb enthusiasts.

-Gordon

PIC32MX chips are clocked at around 50Mhz and with its 5 stage pipelining it achieves around 70+ MIPS. Most the screen drawing is done by DMA transfer to an SPI peripheral initiated by some timer interrupts. I suspect the code is idle most (>90%) of the time.

Decoding the ASCII number strings isn't taxing the PIC. Its taxing the 65C816 when it generates them.

There are PICs and there are PICs. Old 8 bit PICs, although I never had the misfortune to have to use them, indeed look pretty ghastly. But this one is a PIC32, which means it isn't a PIC at all. PIC32 is actually MIPS. I've done a fair amount of MIPS programming (the Playstation 2 used one), and once you get used to the branch delay, it's a rather pleasant experience. Full 32 bit, plenty of registers, and no ugly hacks (apart from the branch delay).

But it's also a very good target for compilers. Most of the time there's no need for assembly.

IMHO, the VDU codes are no more ambiguous than using the ESC prefix.

Except for DEL ($7F), all of the VDU control sequences are introduced by a code below 32, which is detectable with a simple NOR gate (2-NOR in 7-bit ASCII, 3-NOR in 8-bit). Detecting ESC specifically requires a full 7 or 8 bit comparison respectively, which at minimum requires two cascaded 4-input gates (one NAND, one NOR) to perform the 7-bit detection.

Now, suppose you pick up a console stream in the middle of transmission. How do you tell if the very first character received is in the middle of a control sequence? It is equally difficult in both cases. The only advantage to the ESC prefix is that its relatively likely that the logic will synchronise to the correct sense of control versus data in a short period of time. But in the case of WYSE, it is not guaranteed because the ESC code is valid in the interior of control sequences. So in fact it is still ambiguous.

It *is* possible to design a console protocol that is unambiguous. Is that a project we should initiate?

And no status register or hardware stack!! (It has conditional instructions instead)

Here's a bit from one of my lockdown projects, a PIC32 native Forth. This is the = ( n1 n2 -- true/false ) word. The 'lw/addui' recover the next on stack (nos) from memory. The 'seq' compares the top of stack register (tos) to the next on stack (nos) and sets tos to either 0 or 1 which the 'neg' changes into 0 or -1.

The MIPS assembler has lots of synthetic instructions. In this case 'seq' is translated into an 'xor' which will result in a 0 only if the values are the same and 'sltiu' (set less than immediate unsigned) which sets v0 to 1 if v0 is less that one and zero otherwise. The 'neg' is mapped to a subtract using the 'zero' register to get 'tos = 0 - tos'.

This is actual generated code: The 'jr ra' (jump to return address) is like a return from subroutine but while the first instruction from the return address is being fetched the following 'sub' (neg) is executed in the 'delay slot' as it is already in the execution pipeline.

Feel free, but let me draw your attention to this: https://xkcd.com/927/



-Gordon

I've used Geoff's design too as a dedicated composite video display. Quite a versatile little gizmo.


I do plan on building up a terminal too, but will probably just layout my own board as I'll likely not need all the options.

One interesting note, if you want to plot a dot you can use the circle command and set the radius to 0. It would be nice to have a special command to plot a dot. Between 11 and 15 characters is a lot just to get a single pixel lit up.