Terminal integration support about tek4010 HOT 4 CLOSED

I'd like to think of the decoder as something that takes a character stream as input and outputs:

• Characters
• Cursor movements
• Vectors

I'd like it to be able to support more then just Tektronix terminals, even though a first cut might just have one.

I believe a standalone decoder library wouldn't be overly hard to do. I'm not sure doing it as part of this repository would be appropriate, and secondly if @rricharz would be interested in accommodating the changes.

from tek4010.

I can help a bit in the next two weeks pointing you in the right direction and explaining details, but then I will be mostly unavailable for two months.

With the Tek4010 project I wanted to write a terminal emulator, which would give the exact look and feel of the Tektronix storage tube terminals of the 1970s. This is of course a lot more than a decoder as @larsbrinkhoff describes above. It includes the following key aspects:

1. Accurate timing
2. Emulation of the bright drawing spot of the storage tube

Timing involves time to draw certain graphics objects such as for example long straight lines (due to the limited velocity of the electron beam movements), as well as time to send an individual byte of the tektronix code to the terminal (simulated baud rate). Therefore, both input and output are timed. The tek4010 emulator basically uses the technique used in video game emulators, which is to calculate a time when the next step was finished on the original hardware, and then either run at full available speed if the emulation is behind or sleep if the emulation is ahead.

The emulation of the bright drawing spot involves two separate cairo drawing canvases, one which is permanent until the full screen is erased, and one which is erased after it has been pushed to the screen once. The screen always displays the "or" of both canvases. Things become of course much easier if the bright drawing spot emulation is abandoned. Then all thats left is drawing vectors and characters on the screen. Then it's also possible to use a decoder as @larsbrinkhoff describes, because you can just look at input again if the current output is complete, and you do not have to worry about handling the bright drawing spot while you are waiting for a character.

Because the Tektronix storage tube terminals were the dominant high resolution graphics terminals of the 1970s and most graphics applications were written using the Tekronix graphics code, most dot matrix terminals of the 1980s supported a "tektronix mode", which neither had the timing nor the storage tube appearance of the originals. Many of the 1980s terminals supported additional escape sequences, for example to draw in color, and allowed for text scrolling.

I think the first decision is what you want to achieve with mintty. If it is just being able to display Tektronix codes, such as the terminals of the 1980s and xterm, that is not trivial, but not too hard either. One approach would be to take tek4010.c and just strip off everything related to timing and the second canvas. As the original, tek4010 just decodes the tektronix codes as a state machine, because depending on in which state the decoder is, the incoming bytes have different meanings.

from tek4010.

Thanks, adding to my issues above:

• I'd indeed be satisfied with "Tektronix mode" and could do without the timing and glowing effects. So I could also check out xterm's Tektronix mode but I remember some notes it's not as complete as this project.
• GIN mode...

from tek4010.

Ah, thank you, I should have closed this myself after I implemented Tek mode for mintty :)

from tek4010.