tty and video displays

Brent Hilpert bhilpert at
Mon Dec 14 15:38:03 CST 2020

On 2020-Dec-14, at 6:28 AM, Paul Koning wrote:
>> On Dec 14, 2020, at 9:26 AM, emanuel stiebler via cctalk <cctalk at> wrote:
>> On 2020-12-14 05:41, Brent Hilpert via cctalk wrote:
>>> On 2020-Dec-14, at 1:26 AM, ben via cctalk wrote:
>>>> Often for data input one could use over strike characters for input. Not EQ might be = BS | Did any video display terminals
>>>> repeat the same effect?
>>> Yes. Coincidentally I've just been refurbishing one - a Teleray 3931.
>>> It's an ASCII/APL terminal, overstriking was included for the APL mode.
>>> Note the screenshots in APL mode.
>> Is it really an overstrike? They look simply like different characters.
>> At least, I didn't (probably missed it) how they can be generated out of
>> the available ones...
> I wondered too.  General overstrike requires a bitmap display, or some sort of persistent display.  Paper is an example; a Tek 4010 would also handle overstrike since it uses a storage tube.  And PLATO terminals did overstrike just fine since they are bitmap displays with per-pixel memory.

Yes, it really is overstrike. This is pretty much explained in the text. You generate overstrikes by backing up and entering a 2nd character.
There are two full screen buffers, but only one page of display. There is a spring-loaded 3-position switch that allows you to temporarily 'disable' either of the buffers, so that only the characters in the other buffer are on screen while you hold the switch.

There are 95 symbols in the APL set encoded in the range 0x20 to 7E, as shown on the screenshots.
Now I haven't tried all 9025 possible overstrike combinations, but all sorts of non-sensical combinations produce what would be the expected result - an OR of the pixels of the contributing characters. For example, "A" can be overstruck with all the other letters of the alphabet, and all the letters of the alphabet can be overstruck with "A". It's not just the valid APL overstrike combinations.

A general overstrike capability like this doesn't need a bitmap display to accomplish. I haven't RE'd the character-pixel generation section, but the ICs present and the behaviour points to it doing something along the lines of:
	In raster scanning, for each screen character cell:
		- address buffer 1, send code through character generator, store result in pixel shift register.
		- address buffer 2, send code through character generator, OR result into pixel shift register.
		- shift the shift register pixels out to CRT.
		- repeat for next character cell

More information about the cctalk mailing list