THE RANT / THE SCHPLOG
Schmorp's POD Blog a.k.a. THE RANT
a.k.a. the blog that cannot decide on a name

This document was first published 2015-11-10 21:07:07, and last modified 2015-11-10 21:07:07.

Emulating VT102 Hardware in Perl - Part 1: Introduction

Welcome to another installment of Schmorp Writing Emulators Without Apparent Use (SWEWAU!), this time, we'll look at a DEC VT100/102/131 hardware emulator/simulator, written, of course, in Perl. Now, before I started writing this, I actually looked up what an emulator vs. a simulator would be, and the answer seems to be: both terms are pretty much interchangeable - emulating is often used for things that emulate hardware, while simulating is often used to indicate when you fudge it up and just play pretend. Which would make all VT102 emulators such as xterm or rxvt-unicode actual simulators.

Ignoring this ambiguous terminology, what this is about is a script that emulates enough of the original Vt100/102/131 hardware to run with the original ROM firmware. The actual hardware components, such as the video interface, are merely simulated, and in fact, the emulator actually needs a VT102 compatible terminal emulator to run to make sense of the output.

Motivation

Ok, so this is about a hardware emulator that runs the original ROMs, but depends on another VT102 emulator to display anything. Isn't that a bit pointless?

Indeed, it would be, if the goal would be to write a terminal emulator such as rxvt-unicode. The goal, however, is slightly different: While working on rxvt-unicode (which claims to be a VT102 emulator), sometimes questions such as "how does margin handling actually work, does xterm do the right thing, or is urxvt more correct". And while I have a few X-Terminals, Wyse terminals and even some godforsaken HP X terminals, I do not actually have a real VT102.

So when we run into such a question some time in 2014, I wondered how hard it would be to write something that would run the original ROMs and would be good enough to answer such questions. Turned out writing it was quite easy (I head a hackish working version a day later), and making it ready for release was as hard as usual (took about two weeks).

So, let's begin this series by giving a few screenshots, and explanation of how to use it, and some rummaging around in old documents. Ah, but first...

What is a VT102 terminal?

I am sure most people reading this already know what a VT terminal is, but for those who don't, a terminal is simply the thing that is at the end of the communications line to your local 10MHz supercomputer. They usually consisted of a screen, a keyboard, and some way to connect it to the minicomputer in the other room, so you can have 50 people work on a 8086 speed machine. Full multitasking included!

Wikipedia seems to have an acceptable page (with colour pictures!) about the VT100 and related terminals. Suffice to say, it was a very popular terminal series. The fact that it was the de-facto standard in the early 1980ies is reflected by the fact that many terminal emulators strive to emulate it nowadays - either the VT102 directly, a successor such as the VT220, or the stripped down version for the OS-challenged called "ANSI escape codes". And while it seems xterm and rxvt-unicode are the only emulators who care about details, most terminal emulators have some kind of VT100 mode that more or less acts similar to a VT102.

Using the emulator

First, you have to download it (direct link). Then you need to fire up a terminal window (size is 86x28 or more), such as rxvt-unicode and then run it:

./vt102

This should give you some flashy initialisation sequence and then run sh inside it, which often is bash. To work, it needs perl 5.10 or newer with a working IO::Pty module and stty in your path.

vt102 started without arguments in a urxvt window, showing a shell prompt.

(The above is the first image in my blog - I know because my "blog software" couldn't even do images before this article was written).

The bootup sequence is a bit flashy - the reason for this is that the ROM defaults to rather slow and unusable (for a modern audience) settings, so the emulator feeds a key sequence that configures it first. The alternative would have been to provide proper set-up data in the NVRAM, but it's format is more dependent on the ROM version - and the NVRAM storage and access protocol is beyond the arcane.

Here are some impressions from a boot (it's usually too fast to follow in detail):

Part of the self test - the line with asterisks is repeated by the video hardware (this will be explained when I write about the video chip).

Sure, we are waiting - this can take up to 30 seconds on real hardware.

The ROM got the keypress to enter the main Set-Up screen, where you can configure tab stops.

Set-Up screen B, where setrial line parameters and other details are being configured.

Invocation

Apart from running a shell, you can run other programs with parameters, simply by giving them as extra command line arguments:

./vt102 telnet towel.blinkenlights.nl

The default is to run these in VT102 mode - the VT100 is just a tad buggy, so when people say "VT100", what they usually mean is "VT102". You can also run in VT100, VT100+AVO and VT131 modes (the script comes with ROM images for all of them):

./vt102 --vt100
./vt102 --vt100+avo
./vt102 --vt131

Keyboard and Configuration

vt102 will accept VT100-compatible keyboard input and will pass most keys through in the way you would expect it. Since the VT100 keyboard is rather different than a PC keyboard, there are some keys that are non-obvious and are being mapped to other keys:

SET UP     Home
BACKSPACE  Rubout
CAPS LOCK  Prior/PgUp
NO SCROLL  Next/PgDown
BREAK      End
CTRL-C     Insert

The reason CTRL-C is not mapped to CTRL-C is to reduce the deep fear when you run the command, press ^C, and you can't get out!!!.

If you want to make sense of the Set-Up screens, you can find a description in the VT102 User Guide.

Screen Features

As you might have noted already, vt102 outputs more than just the raw VT102 screen. The top line is a status line of the emulator. It is followed by as many lines of the actual video buffer as programmed, with row number and the row contents in | characters:

--- LED [ BEEP SCAN LOCAL LOCKED CTS DSR INSERT L1 ] CLK 44761088
 0 ││
 1 ││
 2 │                                                                                │
...
25 │                                                                                │

The LED [] section, unsurprisingly, shows the state of the LEDs. Well, for the most part - BEEP is not actually an LED but a beeper, and SCAN is actually a internal line that initiates a keyboard scan (the keyboard uses some discrete logic to do most of the key scan itself).

The CLK section shows how many "clock" cycles the CPU has run, or rather, how many extended basic blocks have been executed (which contain multiple instructions). Unlike 1978, where only the oil industry knew about fossil fuel causing global warming, today we should be more conscious about energy usage, so the vt102 emulator contains a power saving feature, where it completely sleeps when no input or output happens - which is why the CLK counter stops when it is idle, and is also why the cursor stops blinking.

Resources

At the time the VTxxx series was in heavy use, it was still common to actually repair (and extend) electronic devices, so you could usually get schematics and hardware documentation.

This is good, as it means I had reasonably good documentation to start with, at least for the VT100. Apart from the users guide (local PDF copy), there are others that you can find if you dig a bit, and which were useful:

VT100 SERIES VIDEO TERMINAL TECHNICAL MANUAL - this describes the hardware in more detail, and more so, the programming interface for the hardware. It was the primary reference when writing this software, and apart from some minor errors, pretty much describes the actual hardware.

VT100 Field Maintenance Print Set - these are the schematics of the hardware, which are very useful when you want to trace some CPU pins, or understand how this attribute RAM is being wired, and so on.

VT103 Field Maintenance Print Set - VT103 schematics - not as useful, but good to makesome educated guesses about other hardware.

VT125 Field Maintenance Print Set - VT125 schematics. The VT125 is rather different to the VT100, but still, some details can be used to make guesses about the VT102.

WD8250 Data Sheet and WD8250 Register Description - this is a chip that is very similar to the serial interface chip in the VT100.

VT180 SERIES TECHNICAL MANUAL - some of the hardware interface documentation here is actually correctly describing the VT100 hardware.

Intel 8080A Data Sheet and 8085 Instruction Set Reference the VT100 used an Intel 8080 CPU, while the VT102 and VT131 used a 8085 CPU. They are mostly compatible, but there are some inportant differences that are explained in future installments of this series.

VT220 Schematics - while the VT220 is a very different beast (using, among other things, a 8051 CPU which is completely different to the 8080 CPU), part of the schematics enabled me to make some educated guesses about actual VT102 hardware.

That's a lot of documentation - you might wonder why there is a need for so many "educated guesses"! Well, sadly enough, while the VT102 Technical Manual was published, nobody capable of digitizing it has a copy. In fact, the document with DEC part number EK-VT101-TM (101, not 102), which describes the VT102 and VT131 hardware, is one of the most sought after documents on the internets. If you have one, by all means scan it and send me a copy so I can share it!

What's Next?

I am not sure how I will structure this series, but the next article will likely give a high level overview of the VT100/101/102/131 hardware. Then I will work through the emulation of the CPU and other hardware components.