Raster CRT Typography According to DEC(masswerk.at)
masswerk.at
Raster CRT Typography According to DEC
https://www.masswerk.at/nowgobang/2019/dec-crt-typography
53 comments
Reminds me a bit of a weekend project I did a few years back: When I was about 6, my dad went out and bought what would be the family computer for half a decade, a TI-99/4a. The thing that stuck in my craw was that even though Apple and Commodore had mastered the lowercase Latin font, the lowercase letters on the TI were just tiny uppercase ones. So flash forward 25 years or so, and I'd downloaded a TI-99 emulator to play with, and decided to see if I could put an Apple II font on it. It was relatively easy to find the font in the ROM, and I found a donor font through Google. Kludged them together, and it worked beautifully. Lowercase letters on a TI-99! No idea WTF they were thinking with the original font.
I don't know either, however TI at the time also produced the "Silent 700" terminal series and it had the same font (all essentially upper case characters just some larger and some smaller.
Perhaps it was an early example of the DRY mantra being applied incorrectly.
Perhaps it was an early example of the DRY mantra being applied incorrectly.
That was an unobjectionable comment, so I guess the downvotes are a stimulus to try to get me to write more. The Wikipedia page for the TI-99 mentions the "small capitals" but does not link to the page I linked to. So some people, at least, who read that page won't get the reference to the typographic tradition (if that's what it is).
A larger issue is the idea that, by choosing a small caps style for their font, TI were acting inexplicably or irrationally. It is worrying but not surprising that the HN crowd finds it disturbing when a company makes a creative decision that doesn't have a clear business case behind it, while being completely innocuous, and which potentially could have helped to differentiate their products. It's the typical negative engineer stereotype coming through: "No imagination or creativity allowed, except if it's to solve a specific problem".
A larger issue is the idea that, by choosing a small caps style for their font, TI were acting inexplicably or irrationally. It is worrying but not surprising that the HN crowd finds it disturbing when a company makes a creative decision that doesn't have a clear business case behind it, while being completely innocuous, and which potentially could have helped to differentiate their products. It's the typical negative engineer stereotype coming through: "No imagination or creativity allowed, except if it's to solve a specific problem".
That Wikipedia page you linked to explains that small caps are used almost exclusively to emphasize or distinguish text from text set using the usual mix of uppercase and lowercase letters. So pointing out that small caps are a well-established typographical practice does nothing to explain what TI was thinking by including small caps but not lowercase. And no matter how innocuous you consider it, it is clear that the decision strikes many users as odd, and that it comes across as something of an unattractive technological limitation, akin to the then-recent systems that only supported uppercase.
It's slightly complicated, but the smaller caps of "small caps" are the lower case. As Wikipedia says, setting text in small caps is "technically not a case-transformation". In those days it would not be surprising that a system would only have one font.
I don't know about the Silent 700's font, but it looks to me like this probably wasn't a mistaken case of the DRY principle: after all, the TI-99's lower case letters are still stored as separate bitmaps (they are reproduced in an image here: http://electrickeet.com/line-itfont.html).
So it is clear, at least, that they had the storage for lower case, and for whatever reason decided to go with a small caps font. It isn't a result of a simple limitation that they hacked around by scaling bitmaps or something like that. I wouldn't like to speculate about what fraction of users found it odd at the time.
I don't know about the Silent 700's font, but it looks to me like this probably wasn't a mistaken case of the DRY principle: after all, the TI-99's lower case letters are still stored as separate bitmaps (they are reproduced in an image here: http://electrickeet.com/line-itfont.html).
So it is clear, at least, that they had the storage for lower case, and for whatever reason decided to go with a small caps font. It isn't a result of a simple limitation that they hacked around by scaling bitmaps or something like that. I wouldn't like to speculate about what fraction of users found it odd at the time.
Some people prefer smallcaps
over lower case letters when the font matrix is too small for descenders on letters like j, q and p. If you're limited in pixels, those have to be pushed up and they look odd.
It appears to be a 5x7 font, which would mean little room to work in.
It appears to be a 5x7 font, which would mean little room to work in.
Interesting post. From my work on 1980s micros that used CRT TVs for display, the phosphor response described here seems to be a bit oversimplified.
In my purely subjective experience, rise time seems to be shorter than fall time - pixels will usually be visibly blurred on the trailing (right) edge, but sharper on the leading (left) edge. Another thing I noticed is that a longer horizontal row of pixels will leave a longer decay on the trailing edge than a single pixel. For example, the Ts will usually have their horizontal line visibly stretched on the trailing edge, even when the vertical line seemed sharp.
Of course, purpose-built terminals might have used different phosphors than cheap TVs of the time. It might also have to do with video amp bandwidth, or something else electrical.
In my purely subjective experience, rise time seems to be shorter than fall time - pixels will usually be visibly blurred on the trailing (right) edge, but sharper on the leading (left) edge. Another thing I noticed is that a longer horizontal row of pixels will leave a longer decay on the trailing edge than a single pixel. For example, the Ts will usually have their horizontal line visibly stretched on the trailing edge, even when the vertical line seemed sharp.
Of course, purpose-built terminals might have used different phosphors than cheap TVs of the time. It might also have to do with video amp bandwidth, or something else electrical.
Without disagreeing with you, the diagrams from the linked page are pretty much reproductions of the ones from an official VT100 technical manual, https://vt100.net/docs/vt100-tm/
It appears to me that the rise/fall graphs are just graphs of ideal RC networks, while the whole true CRT system will have lots of other factors such as inductance going on.
When it comes to comparing what you might recall of CRT TVs and 80s micros to what a dedicated monochrome CRT would show, well, the dedicated CRT was much better and sharper, particularly if your color display technology involved a "composite" system like NTSC or PAL, where horizontal luminance (Y) bandwidth was SEVERELY limited to "make room for" the color information (I/Q).
To get an idea of how much Composite video encoding degraded picture information, take a look at modern videos of "RGB-modded" classic consoles such as https://www.youtube.com/watch?v=kpdpAxzjmA8 -- As far as I understand from the video explanation, both signals are video-captured, so this is not a "CRT effect", it's a "composite video effect" that makes the right-side image so smeared. There's also the palette difference, but that's more a matter of preference.
It appears to me that the rise/fall graphs are just graphs of ideal RC networks, while the whole true CRT system will have lots of other factors such as inductance going on.
When it comes to comparing what you might recall of CRT TVs and 80s micros to what a dedicated monochrome CRT would show, well, the dedicated CRT was much better and sharper, particularly if your color display technology involved a "composite" system like NTSC or PAL, where horizontal luminance (Y) bandwidth was SEVERELY limited to "make room for" the color information (I/Q).
To get an idea of how much Composite video encoding degraded picture information, take a look at modern videos of "RGB-modded" classic consoles such as https://www.youtube.com/watch?v=kpdpAxzjmA8 -- As far as I understand from the video explanation, both signals are video-captured, so this is not a "CRT effect", it's a "composite video effect" that makes the right-side image so smeared. There's also the palette difference, but that's more a matter of preference.
What does the long decay times of forbidden transition lines have to do with analogue circuits?
TVs had their sub-pixels arranged differently to the CRTs on many computer displays. This lead to a lot of “fuzzing” beyond that phosphor response when computers were hooked up to TVs.
A classic example of this is when you play retro consoles on an authentic household TV verses VGA.
Some systems actually used this technique as an additional rendering trick. For example having a foreground sprite where every other pixel was invisible and those pixels would be blurred by the TV to give a more authentic looking transparency effect.
A classic example of this is when you play retro consoles on an authentic household TV verses VGA.
Some systems actually used this technique as an additional rendering trick. For example having a foreground sprite where every other pixel was invisible and those pixels would be blurred by the TV to give a more authentic looking transparency effect.
(OP here). There are actually no pixels on a monochrome screen, rather, there's just an even phosphor coating. What we may assume to be a pixel is just an effect of the signal generating the pattern. Color TV changed this radically, as there was now a shadow mask and (usually) vertical strips of phosphor. However, pixels were still determined rather by the generating signal than by the subpixels of the shadow mask. (So a pixel may illuminate any number of phosphor regions exposed to the cathode ray at this very moment.) Moreover, a TV usually included some kind of sharpening circuitry, which was more tuned to moving images and didn't perform that well with static content. And, of course, various color systems (NTSC/PAL/SECAM) generated different effects and artefacts of their own.
Yes I know. My point was the arrangement of the RGB dots that made up a region was different on CRT TVs to that of colour CRT monitors (ignoring the old terminals for now because they’re a different era of device entirely). That did have an effect on the sharpness of the image.
What I didn’t mention but is also worth noting is the quality of the input signal would have mattered as well. 8bit micro monitors, even in the 80s, generally took RGB input. Whereas any micro that output to a TV would often do so via a the antenna, ie the computer would have to be tuned in like a TV station. This means you then have all of your prime colour “wires” as well as audio mixed into one analogue signal. Which obviously degrades the overall image and sound quality. Plus TV tuning isn’t nearly as precise as having a proper dedicated cable. The devices from the 80s (and 90s) which supported both ANT and RGB really show just how significant the difference between the two is. Which is also why you often see a lot of retro gear being sold as “RGB modded”.
Basically what I’m saying is comparing a budget micro on an 80s home TV to a raster CRT terminal is rather pointless. Different tech, different target audience, different eras.
What I didn’t mention but is also worth noting is the quality of the input signal would have mattered as well. 8bit micro monitors, even in the 80s, generally took RGB input. Whereas any micro that output to a TV would often do so via a the antenna, ie the computer would have to be tuned in like a TV station. This means you then have all of your prime colour “wires” as well as audio mixed into one analogue signal. Which obviously degrades the overall image and sound quality. Plus TV tuning isn’t nearly as precise as having a proper dedicated cable. The devices from the 80s (and 90s) which supported both ANT and RGB really show just how significant the difference between the two is. Which is also why you often see a lot of retro gear being sold as “RGB modded”.
Basically what I’m saying is comparing a budget micro on an 80s home TV to a raster CRT terminal is rather pointless. Different tech, different target audience, different eras.
My post wasn't meant as a critique, rather as an expansion on yours. We are so used to thinking in pixels that we often forget there weren't any hardware pixels in B&W. It was whatever the circuitry could produce. You observations on color TV are certainly right. From what I remember, the most obvious distortion came from the sharpening (which is seldom mentioned today), resulting in hard, double vertical edges. This may have been more prominent in PAL than NTSC. – How I did long for a legit RGB monitor, but it was just a color TV for my C64 anyway. :-)
I'm not sure this is a consequence of the phosphors. It looks to me like this is an effect of how quickly the electron gun turns on and off. I would expect the horizontal sweep rate to be unaffected by whether pixels are supposed to be on or off, so the blurring at the left edge is determined by how quickly the beam ramps up to full current when turned on, and the blurring at the right edge is determined by how quickly the beam current is switched off.
The slow decay of the phosphors is on an entirely different timescale: more on the order of the time taken to refresh the entire screen, rather than the time taken for the e-beam to sweep across a single pixel. The asymmetry in the phosphor's activation vs decay is vastly greater than the asymmetry in the electron gun's switching on and off.
The slow decay of the phosphors is on an entirely different timescale: more on the order of the time taken to refresh the entire screen, rather than the time taken for the e-beam to sweep across a single pixel. The asymmetry in the phosphor's activation vs decay is vastly greater than the asymmetry in the electron gun's switching on and off.
There's a really interesting video about character generation on HP 264x series terminals: https://www.youtube.com/watch?v=QikO0WOAGWI
That's nothing! Tektronix did vector fonts in the 60s using analogue ROMs.
That's nothing, the Jaquet-Droz family were producing glyphs from mechanical analogue storage in ~1770. https://www.youtube.com/watch?v=bY_wfKVjuJM
That’s nothing, the Egyptians were writing glyphs to solid state analogue storage two thousand years before that. /s
Also, see the use of a metal plate as a binary storage device for fonts used for the print on punch cards with the IBM key punches:
https://www.masswerk.at/misc/card-punch-typography/
https://www.masswerk.at/misc/card-punch-typography/
Highly recommended! As are all these videos by Marc Verdiell.
Fantastic. My favourite terminal I worked on was the amber-colored vt320 hooked to a sun box and sometimes to an sgi. There was something special to it, even 'back in the day'.
Truth - the only problem with those old terminals was the keyboard. They tended to not have the control key or ESC key (DEC terminals) in a nice spot.
Similar project is cool-retro-term [1] although I think the defaults are a little over the top.
[1] https://github.com/Swordfish90/cool-retro-term
[1] https://github.com/Swordfish90/cool-retro-term
I love cool-retro-term! I'd say the defaults are way over the top and probably hurt the projects adoption. Once I turned everything down, it has become the most readable modern terminal I've ever used!
cool-retro-term is my go-to terminal program for quick projects that don't need multiple panes.
It freaks out the IT guys and our workspace consultants, which is a bonus.
The only downside is that on macOS it crashes on quit. But since I'm quitting it anyway, no harm done.
It freaks out the IT guys and our workspace consultants, which is a bonus.
The only downside is that on macOS it crashes on quit. But since I'm quitting it anyway, no harm done.
Why would cool-retro-term “freak out” IT professionals any more than a typical terminal emulator? Does “freak out” have some additional definition I’m unaware of?
Personally I found cool-retro-term lacked support for a few ANSI escape sequences I needed for tmux to work quite how I liked which prevented me using it as my daily $TERM. I’m sure with a bit of effort I could have gotten it working but it was an effort not work making when there’s literally dozens of other ${TERM}s I could use and the only thing in favour of cool-retro-term is novelty.
I do really like how cool-retro-term is an expansion of the acronym CRT. Clever project naming.
Personally I found cool-retro-term lacked support for a few ANSI escape sequences I needed for tmux to work quite how I liked which prevented me using it as my daily $TERM. I’m sure with a bit of effort I could have gotten it working but it was an effort not work making when there’s literally dozens of other ${TERM}s I could use and the only thing in favour of cool-retro-term is novelty.
I do really like how cool-retro-term is an expansion of the acronym CRT. Clever project naming.
Why would cool-retro-term “freak out” IT professionals any more than a typical terminal emulator?
Because a typical terminal emulator doesn't make the brand new monitor they just installed look like it's broken.
Because a typical terminal emulator doesn't make the brand new monitor they just installed look like it's broken.
Cool-retro-term doesn’t make a brand new monitor look like it’s broken. The effect of CRT isn’t even remotely what an LCD looks like when it fails.
So I’m guessing when you say “IT professionals freak out” what you actually mean is “idiot desktop support engineers who think anyone who uses the command line are ‘l33t h4xx0rz’”.
In which case they’d have a hernia if they saw the kind of workspace a typical non-poser runs.
So I’m guessing when you say “IT professionals freak out” what you actually mean is “idiot desktop support engineers who think anyone who uses the command line are ‘l33t h4xx0rz’”.
In which case they’d have a hernia if they saw the kind of workspace a typical non-poser runs.
So I’m guessing when you say “IT professionals freak out” what you actually mean is “idiot desktop support engineers who think anyone who uses the command line are ‘l33t h4xx0rz’”.
You guessed wrong, since they're used to seeing me use iTerm all over my other monitors.
You guessed wrong, since they're used to seeing me use iTerm all over my other monitors.
pushpop(1)
On an unrelated note, I wish somebody made a modern portable and low-power hardware terminal. Something with eInk, or maybe even reflective LCD, like those old "electronic organizers", but with a full-size screen. If it can do serial and serial-over-USB, that can come in handy with headless boxes, RPi etc.
Until that happens, Prompt for iOS by Panic Software out of Portland is very useful. I've used it on my iPhone in emergencies for years, and recently put it on an iPad and it really shines.
Is the HTML5 "workbench" VT100/220 emulation available to try?
(Didn't see a link to it)
DEC Terminal Modern, fitting the old character shapes but having smooth outlines, is rather nice. It's almost like the new Chicago font, which Apple remade as a vector font that would produce the original bitmaps if rendered at the original size.
I'd like to see that for the "fixed" font used as the xterm default. I got addicted to this font, but pixels are getting smaller and my eyes are getting worse.
I'd like to see that for the "fixed" font used as the xterm default. I got addicted to this font, but pixels are getting smaller and my eyes are getting worse.
We need the VT52 experience: relay clicks as you type.
My favorite VT52 experience was at a science fiction convention with Doug Humphrey (DIGEX).
In the middle of a party in a hotel room, DIGEX announced: "OK, it's time to go down to the garage and bringing up all the VT52's from my car!" Trusting Doug unconditionally, several of us volunteered to help.
After we hauled a bunch of VT52's from the parking garage, through the hotel lobby, up the elevator, and back to the room, and set them down, Doug opened up one of the cases and announced:
"The great thing about VT52's is that if you take the printer module out, there's just enough room for a 6 pack of Guinness Stout bottles inside!"
https://vt100.net/docs/vt52-mm/chapter7.html
https://vt100.net/docs/vt52-mm/figure7-2.html
In the middle of a party in a hotel room, DIGEX announced: "OK, it's time to go down to the garage and bringing up all the VT52's from my car!" Trusting Doug unconditionally, several of us volunteered to help.
After we hauled a bunch of VT52's from the parking garage, through the hotel lobby, up the elevator, and back to the room, and set them down, Doug opened up one of the cases and announced:
"The great thing about VT52's is that if you take the printer module out, there's just enough room for a 6 pack of Guinness Stout bottles inside!"
https://vt100.net/docs/vt52-mm/chapter7.html
https://vt100.net/docs/vt52-mm/figure7-2.html
Some of IBM's mainframe terminals used a solenoid which would hit the side of the keyboard's case to indicate that a key-press was successfuly registered. This was in addition to the well documented clicking noise of IBM's keyboard switches.
IIRC original 3270 keyboard had solenoid that physically prevented user from pressing any key when the terminal was busy and would not be able to register the key press.
The solenoid on the one which I have (a 3278 keyboard) is separate to the keys. It is true that the solenoid will not operate when the terminal is unable to accept any key press, but it does not impede the operation of the keys themselves.
To the best of my knowledge, the only IBM keyboards that could flat out prevent the keys from being pressed were ones based on the Selectric typewriter mechanism, such as the 2741
To the best of my knowledge, the only IBM keyboards that could flat out prevent the keys from being pressed were ones based on the Selectric typewriter mechanism, such as the 2741
In order to prevent two keys being active simultaneously, the Selectric had a linear track full of steel balls running from side to side, with just enough free space to allow a metal tab from a single key to enter. So locking the keyboard was just a matter of having a solenoid occupy the free space.
Excellent research. I wonder who the artist is who drew the typeface and whether they realized at the time that it would have such significance that somebody would still be studying their work so many decades later
It's interesting that DEC did horizontal pixel stretching because individual dots would be too precise to be seen because of phosphor latency.
The Commodore 64 had a similar problem with single-pixel latency, which is why the vertical portions of its character ROM are all two pixels wide. Otherwise, the character would be too blurry to be read comfortably on televisions of the era.
I used to love making my own C-64 fonts pixel by pixel and comparing how they looked on a Panasonic portable TV versus my Commodore CM-141 monitor.
The Commodore 64 had a similar problem with single-pixel latency, which is why the vertical portions of its character ROM are all two pixels wide. Otherwise, the character would be too blurry to be read comfortably on televisions of the era.
I used to love making my own C-64 fonts pixel by pixel and comparing how they looked on a Panasonic portable TV versus my Commodore CM-141 monitor.
this is great!
I'm a regular user of the glasstty font + the 'tritty'[1] utility which emulates serial line I/O to create the 'true unix terminal' experience.
Looking forward to the next post!
ps: improved smeary-220 font would be great :b
.. [1] https://github.com/sjmulder/trickle
I'm a regular user of the glasstty font + the 'tritty'[1] utility which emulates serial line I/O to create the 'true unix terminal' experience.
Looking forward to the next post!
ps: improved smeary-220 font would be great :b
.. [1] https://github.com/sjmulder/trickle
I'm not sure that all the smearing and blur is historically accurate for vt220. I still have Wyse WY-150 (IIRC) on my desk and while it has somewhat poor contrast (which seems to be mainly caused by worn out contrast pot, I gotta fix that someday), it has exceptionally crisp display. I remember the same "crispness" feeling from various amber phosphor MDA monitors.
good point - I actually do have a 320 and the topics discussed in the article seem to jive with my experience with it..
but yes, it is very crisp - i think the point of the 'fuzzing' details discussed here is that they actually help the overall clarity (e.g. a 'dithering' sort of effect)
but yes, it is very crisp - i think the point of the 'fuzzing' details discussed here is that they actually help the overall clarity (e.g. a 'dithering' sort of effect)
I need to find/buy an eeprom and programmer for my VT102, the character ROMs are failing and the text is totally garbled
This is great! Id love if this expertise was added to the cool-retro-term project.