On 2020-Dec-14, at 6:28 AM, Paul Koning wrote:
>> On Dec 14, 2020, at 9:26 AM, emanuel stiebler via cctalk
>> <cctalk@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
