Skip to content
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

Closed
mintty opened this issue May 16, 2020 · 4 comments
Closed

Terminal integration support #24

mintty opened this issue May 16, 2020 · 4 comments

Comments

@mintty
Copy link

mintty commented May 16, 2020

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:

  • Factor out the cairo library from tek4010.c. The type cairo_t seems to be basically just a handle here so it could be easy, the name can remain.
  • Factor out pipe and keyboard stuff from tek4010.c/tube.c. Clarify the interaction of input, output, timing (tube_getInputChar, tube_isInput, tube_u100ResetSeconds, ...) so it can be replayed from mintty.
  • Describe the cairo functions used in tube.c (I’ve collected them in a fake cairo.h file; not all of them are obvious) so I can implement them via Windows graphic functions.
  • Factor out/describe the text and font functions which I’d prefer to implement directly using Windows functions.
  • Agree on supported screen models (I think there are 2 sizes?) and how to map them on a Windows screen (my part). The 4096 lines model will need to be zoomed down for most screens... Unlike xterm, I’d like to display Tek graphics within the same terminal window, maybe zoomed as appropriate.
@larsbrinkhoff
Copy link
Contributor

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.

@rricharz
Copy link
Owner

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.

@mintty
Copy link
Author

mintty commented May 16, 2020

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...

@mintty
Copy link
Author

mintty commented Dec 15, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants