How did early video terminals convert ASCII into font graphics?

Question

I'm building a Z80-based breadboard computer from scratch to learn more about simple processors, and I'm a bit stumped when it comes to the base concepts of building a text-based terminal.

I've got an LCD screen to which I can send pixel data. Currently I'm trying to use the Z80 itself to interface with the screen; I understand that a separate terminal processor would be doing this heavy lifting in the real world.

My idea was as follows:

• I have a buffer of ASCII characters in the Z80's RAM.
• I have a bitmap font stored in the Z80's ROM as a set of six bytes per character.
• I have a section of RAM set aside for the framebuffer.
• Every time I press a key, it's added to the buffer.
• Then, the Z80 loops through each character in the buffer, finds the matching bitmap character, and loops through its rows, writing them into the framebuffer one row at a time at the current location to build up a character. This piece of assembly code is hideously long and seems very slow and bug-prone.
• The framebuffer is then sent to the screen via a parallel interface.

Is this really how video terminals worked originally, or do I have the basic concept all wrong? I'd appreciate any advice, extra reading, and even old code.

Edit: This question is interesting, but is a bit more high-level than mine.

Answer 1

Video Terminals

I understand the term "video terminal" to refer to things like the DEC VT-100 or Lear-Siegler ADM-3A.

They get characters (typically ASCII-encoded) over a serial line from the computer, and they send keystrokes (typically ASCII-endoded as well) to the computer. As your question only applies to the display part, I'll ignore the keyboard-input part.

The terminal has a character-oriented frame buffer, with one byte for each character position on screen (typically 25*80 = 2000 bytes). The terminal also keeps track of the "cursor position" (the place where to put the next character received, and the place to be visualized with e.g. a blinking block).

The typical process done inside the terminal is:

• Receive a character code from the serial line
• Place the character code into the frame buffer at the cursor position
• Advance the cursor position by 1

Besides the visible ASCII characters, terminals understand special control codes, to be handled differently, e.g.

• CR moves the cursor to the beginning of the line
• LF moves the cursor down one line (and scrolls the screen by one line if at end of screen)
• BS moves the cursor left one position.

Now that the frame buffer is filled with the characters for the display, how do they get visible?

A typical CRT needs to refresh every single dot 50 times per second (or so) to avoid nasty flickering. The display is physically driven by an electron beam deflected in a regular "scan lines" pattern that covers the whole screen and is repeated 50 times per second. White and black pixels are produced by switching the beam on or off while passing the pixel position.

If characters are displayed as 10(H) * 8(W) pixel patterns, we get 250 visible scan lines (vertical resolution), each showing 640 "pixels" (horizontal resolution).

To translate the (ASCII) character codes into the pixel patterns, a "character generator" ROM is used that contains the (10-bytes) pixel pattern for every ASCII character.

A continuous readout circuit runs synchronously with the electron beam (synchronized by emitting the appropriate SYNC signals to the CRT).

For every scan line, it loops over the 80 characters in the corresponding text line, wiring the character code output from the frame buffer to the character generator ROM input, to have the ROM output produce the pixels. Typically, the ROM delivers 8 pixels as parallel outputs, and a shift register first sends the leftmost pixel to the CRT, then the second, and so on for all 8 pixels.

As a text line consists of 10 scan lines, the very same text line is scanned 10 times, and sent to the character generator ROM 10 times. As these 10 lines have to look different (from top to bottom row of the character pattern), the character generator ROM needs more than just the charater-code inputs. It also has scanline-number inputs, and these get counted up from 0 to 9 over the 10 scan lines, before the readout circuit switches to the next text line and resets the scanline-number inputs to 0.

One special feature is scrolling. When your cursor advances past the last row, you don't want it to show up at the first row, and have the screen unchanged. You want a fresh, empty line at the bottom, want every text line to move up one row, and forget the text that previously occupied the first row.

Instead of really moving every character up one position, this is done by having a variable screen start address, which is just incremented by one row when scrolling.

Your Approach

Your approach is fundamentally different, but for a very valid reason. LCDs don't follow the same model as CRTs, there is no electron beam that has to switched on or off at a very high frequency. Instead, they contain their own intelligence so you can send commands from your CPU, e.g. to fill some area with a given bit pattern (assuming it's a graphic LCD). So, your CPU needs to translate character codes into bit patterns and then command the LCD to draw these patterns at a specific location.

Your current approach seems to always transfer the whole frame buffer to the LCD. If that's the only operation supported, it will become quite tricky to achieve a reasonable performance (send at regular intervals, only if something really changed). If the LCD also supports partial transfers (ideally with the size of your character cell), you can greatly improve the process by just sending the area just modified.

Answer 2

Translating characters to their bitmap representation is usually handled by something other than the main system CPU.

In terminal-oriented systems (e.g. typical CP/M setups), the main system only sends characters (including escape codes) to the connected terminal, usually over a serial connection; the terminal takes care of displaying the characters. There might not even be a local framebuffer; all the main CPU needs to handle is a stream of characters to and from the terminal.

On micros producing the video signal themselves, there’s dedicated circuitry handling both the video signal itself, and the character generation. Understanding the Apple IIe includes a detailed description of the setup there. On 8-bit Ataris, this is handled by the ANTIC chip. On MDA or CGA-equipped PCs, character generation is taken care of by dedicated “alpha-serializer” circuitry (which IBM also refers to as a “ROS character generator”, i.e. a read-only storage character generator, which uses each display character as an index into the font ROM). In all these systems, the framebuffer contains either individual pixels, or individual characters (possibly with attributes), or a mixture.

One notable exception is early Amstrad computers, where character generation is handled by the CP/M XBIOS.

The various answers to Which computers had redefinable character sets? provide lots of information on the different approaches to character generation seen in micros.

Answer 3

Currently I'm trying to use the Z80 itself to interface with the screen [...] I have a section of RAM set aside for the framebuffer.

While there are actually some systems that directly "interface to the screen" in the sense of producing the output signal itself (which becomes even more interesting with the rigid timing required for TVs), the approach of "have a framebuffer, and let something else read out the framebuffer, so the CPU can do useful work" is a lot better.

So assuming your LCD screen needs a sequence of bytes describing the color of each pixel, you'd typically have a bunch of counters that control this timing, read out the framebuffer, do the font lookup, and send out the signal. The MC6845 and derivatives were popular chips for that, and even in today's graphics cards we still have the same concept.

Every time I press a key, it's added to the buffer.

This might be fine for a proof-of-concept, but that's not the general principle.

Is this really how video terminals worked originally, or do I have the basic concept all wrong?

For "I'm building a Z80-based breadboard computer from scratch to learn" I'd say it's a lot easier to just pick a cheap chip to drive your LCD from the framebuffer.

Answer 4

Before analog video interfaces pretty much disappeared entirely, one could find a handful of microprocessor-only video generators, mostly built for fun. My favorite was a recreation of the classic Pong game. Back then, a 4MHz PIC16 (with no frame-buffer) could keep up with a low-resolution, monochrome 15kHz raster display (e.g. VGA, NTSC, PAL, SECAM) if it did almost nothing else. Practically no modern CPU can "bit bang" the proper timing signals to drive a digital display like an active-matrix, raster LCD, unless they have a dedicated LCD interface built-in (which many systems-on-a-chip do). [Addendum: okay, maybe you could in a pinch, but accurate "cycle counting" is a thing of the past, so there will be glitches.]

Back to your "how would I build a video terminal," many early computer terminals contained no microprocessor at all. The video signal generator and font rendering were done entirely in hardware, first using a font-ROM and lots of simple chips, and later with a single video chip. Studying vintage computers will tell you how these video chips were used. Though many such video chips are themselves considered vintage, you'd be surprised what you can find on eBay.

If you want to do everything in software, consider building a light show out of an XY galvo laser scanner. A 25kpps unit can be purchased for under $65 on AliExpress, or double that on eBay. Lots of fun to show off. Sometimes even "bugs" will look cool.

Answer 5

I think you might have got it backwards.

If you consider your font bitmaps as a textures, the text location as spacial location, then you have a texture mapping problem, just like what GPU does today.

But GPU (and virtually everything else) implements this via reverse-mapping, i.e. iterate through each pixel, calculate which text location it is (of which you can easily keep a record while incrementing pixel row and column index) and what character it is, lookup its font bitmap, then output that pixel.

If you follow this procedure you'll find it's exactly what Ralf has described in his answer but optimized/vectorized.

Another issue of your issue with your approach is, you didn't make good use of the display's hidden memory. Any display device is a two-port RAM, with the 2D ramdom-access reading port facing us, the user, and the 1D sequential-access writing side facing the computer, the video cable. The operations described by Ralf and me are purely sequential, so no additional frame buffer is needed. The display itself is the frame buffer.