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 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.