VT100 Dot-Stretching and Double-Width Characters

Some years ago, I wrote a blog post on the dot-stretching of the DEC VT100 and VT220 terminals, “Raster CRT Typography (According to DEC)”, which enjoyed some traction. However, I’m by no means an expert on the matter, I just stumbled over an article by Paul Flo Willimas on vt100.net, which I found really interesting, dug a little into this and found it interesting to share.

So, what is dot-stretching? In a nutshell, the terminal repeats an active pixel for another pixel-length horizontal impulse, in order to assert at least 2-pixel wide horizontal stretches to compensate for the sensitivity of the CRT phosphor. A side effect of this is that this is applied differently in relation to the patterns stored in ROM with double-width characters. (So we get two fonts in one!)

(From the VT100 Series Technical Manual.)

And this is how this applies differently to single-width and double-width characters:

Notably, Paul Flo Williams asserts that this is the same for the VT100 and the VT220, on which his article is focused: “The VT220 Technical Manual doesn’t explain how this is achieved, but the VT100 Series Technical Manual does (although it gets the explanation wrong!), and a few experiments show that the VT220 works the same way.”
Moreover, the information provided in the VT100 Series Technical Manual suggests these should be, indeed, the same.

However, recently I was contacted on the matter, indicating that this may not be what the VT100 is actually doing. Rather, it was suggested, the VT100 applies pixel stretching for wide characters before the doubling of the pixels. Meaning, where the VT220 repeats a single pixel, the VT100 should repeat a pixel twice.

Images of double-width text on the VT100 are somewhat hard to come by, especially with lower-case characters, which should really give it away. However, there’s a YouTube video by Adrian Black (Adrian’s Digital Basement), which shows towards the end a VT100 demo including wide text:

Here are two (cropped) stills, one showing double-width text in normal video and another one in reverse video. Given the artifacts introduced by digital sensors (which tend to “blow out” anything on a CRT) and modern video codecs (which aggressively apply lossy compression in the FFT domain, meaning frequency / changes in intensity, which should affect the representation of any intensity flanks quite a bit), it may be best to look at the image with reverse video text.

Two observations:

  • There are no single-pixel gaps, where the rounded strokes meet the vertical strokes at the top and bottom of the character “d” and the top of the “p”. This should be indicative of double-pixel stretching, as it had been suggested.

  • However, the vertical strokes appear to be 3 pixel wide, which is consistent with single-pixel stretching like on the VT220. With double-pixel stretching, these should be at least 4 pixels wide!

The two observations are contradictory!
Moreover, while the technical manual of the VT220 is quite informative on the circuitry involved, the diagrams provided in the manual for the VT100 remain rather opaque on the matter. (So no help from this, either.)
Also, if there’s no chance of these gaps ever becoming visible in any display mode, why are the glyphs stored like this in ROM, to begin with? (Why are those not just continuous horizontal stretches of pixels?)

One hypothesis, I manage to come up with, is that dot-stretching like seen on the VT220 was intended for the VT100, but – for whatever reasons – not shipped. Maybe, there was a last-minute intervention, from outside engineering, and a fix was applied to make the wide characters more similar to the normal-width ones?

Does anyone know (a) how this actually works and (b) what happened?
(Or is there even just a common fault with the circuitry – and this what we’re seeing in this video? Can we verify this with actual hardware?)
I’d really love to correct that blog post, especially given its popularity!

3 Likes

I found the following
There are known limitations (maybe depending on the model).
According Jeff Parsons PCJS emulations, there is a mistake on the schematics maybe this is widely copied?

Here is a description of the escape sequences with some explanations (page 5)

It’s also a know issue on the Rainbow 100 emulation for MAME since 2020

Some more finds

https://unix.stackexchange.com/questions/308377/why-do-vt100-terminals-use-only-fixed-width-fonts

https://superuser.com/questions/1397399/why-doesnt-xterm-support-double-sized-characters-when-using-xft-fonts

Maybe Lars Brinkhoff can help?

1 Like