-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terminal integration support #24
Comments
I'd like to think of the decoder as something that takes a character stream as input and outputs:
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. |
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:
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. |
Thanks, adding to my issues above:
|
Ah, thank you, I should have closed this myself after I implemented Tek mode for mintty :) |
I'd like to integrate Tek4010 into the mintty terminal. As a standalone project, Tek4010 lacks some modularity for seamless integration.
@larsbrinkhoff has offered some adaptation support.
The following issues come to my mind:
The text was updated successfully, but these errors were encountered: