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 classiccmp.org> 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.
http://madrona.ca/e/teleray3931/index.html
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