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

Alpha mode characters should be drawn as dots #14

Closed
LegalizeAdulthood opened this issue May 16, 2019 · 3 comments
Closed

Alpha mode characters should be drawn as dots #14

LegalizeAdulthood opened this issue May 16, 2019 · 3 comments

Comments

@LegalizeAdulthood
Copy link

To be more authentic, the real Tektronix terminals used a character generator ROM and drew the characters in alpha mode as a grid of single dots.

The font is shown on PDF page 23 of the 4010 Maintenance Manual. The illustration has lines drawn around the dots, but the terminal just displays the dots. (In the diagram drawn dots are shown as a '1' and blank spaces are shown as a '0'.)

@rricharz
Copy link
Owner

You are making an extremely valid point here, and I have spent several days experimenting with more realistic, pixelated fonts on a number of displays. There are some realistic scalable 5x7 monospace true type fonts available, which could be used, or a font for tek4010 could be designed by somebody having experience with scalable font design. But there are 3 reasons which made me use a non-pixelated font:

  1. You are certainly aware that the 4010 screen had no pixels, but the coordinate system for drawing vectors had a resolution of 1024x780 so called tek points (4096x3120 on the 4014 with the extended display module). Reading page 2-2 of the 4010 Maintenance manual I understand that the 5x7 character matrix dots were not fitted into tek points. As far as I understand the character generator had its own deflection mechanism with its own calibration. Therefore, emulating this exactly on a modern dot matrix display would require to use a resolution which is a multiple of the character points. This would then lead to undesirable effects because tek points would not fit exactly into the dot matrix points. Evenly spaced dots and lines would show up not evenly spaced on the display, unless you are using a very high resolution display. So we would trade a better character display for a worse vector display.

  2. The problem is worsened by the 3 additional much smaller character display modes of the 4014, and by one of the design goals which I had in mind when coding tek4010: That it would work reasonably well on any display the user might have, even if its resolution is below 1024x780 points, and in full screen mode for any display, whatever resolution that display has, as long as the hardware can support that resolution. Of course, on small screens and in full screen mode you always get the problem of unevenly spaced tek points.

  3. Most videos and pictures on the Internet did not show any pixelation effect, and the still working 4014 I had visited to look at the character set did not show them either. The reason for that might well be that the character display circuit, which requires separate calibration, had not been calibrated very well. There are a few pictures on the internet that show a bit of pixelation, but only for certain characters, most notable the X.

So I decided against a pixelated font, because the pixelated fonts I tried did actually not show a more accurate representation of the original at the screen resolutions I had available for my testing.

But if you want a better representation of the actual character display for one given screen resolution, it is easy to install a 5x7 pixelated true type font, and to change line 4 of tube.h to that font. You might also have to change line 235-238, 317 and 332 of tek4010.c if the characters are too large or small. Of course, if you or somebody else comes up with a better font or any other way to improve the character representation I am certainly willing to use it in tek4010. Another way to address the problem at least to some degree would probably be to use bold instead of normal style (line 848 of tube.c). This would make the characters a bit more realistic at the expense of readability.

One last thing: Which font to use might also depend on the situation. I a museum, for example, the exact representation of the original might be the topmost priority, whereas when used for some real work readability and minimal eye fatigue might be more important. Would it meet your needs if I would make the font size and the font style constants in tube.h like the font name, together with a link to an example of a pixelated font?

@rricharz
Copy link
Owner

rricharz commented May 16, 2019

This is an example of using the font "basis33" on my 1920x1080 screen in fullscreen mode. Not perfect, but maybe what you are looking for.
Screen - 1
The small m and x are examples of characters which show the problems best in the smallest character display. The lower the screen resolution, the worse this gets. The original terminal had no such problems, because it was not a dot matrix display.

@rricharz
Copy link
Owner

Version 1.4.1 allows to use any scalable true type font by changing the font name and font size in tube.h and recompiling the program.

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

2 participants