rricharz / tek4010

Free Tektronix 4010, 4013, 4014 and 4015 terminal emulator for Raspberry Pi and Ubuntu

Tektronix 4010 and 4014 Storage Tube Terminal Emulator

This is a Tektronix 4010, 4013, 4014 and 4015 terminal emulator for the Raspberry Pi and other Linux systems.

Below is a screen shot of the spacelab from the ICEMDDN CAD package made on a CDC Cyber 175 mainframe emulator.

tek4010 can also display historical data for the MIT Project MAC 's ARDS (Advanced Remote Display Station):

tek4010 makes an effort to emulate the storage tube display of the Tektronix 4010, including the fading bright drawing spot. If the look and feel is not important, you can use "xterm" instead. "xterm" does not support all graphics modes of the 4014.

It can be used to log into a historical Unix system such as 2.11 BSD on the PiDP-11 or a real historical system. It can also be used to display historical plot data.

The following picture shows a scale model of the Tektronix 4010 crafted by Dave Ault using tek4010.

All instructions can be found in Manual.pdf in the main Tek4010 directory.

The storage tube emulator and the Tektronix 4010/4014 decoder were witten by Rene Richarz. The ARDS decoder was written by Lars Brinkhoff. He also provided some interesting historical documents and the ARDS plot files. Teunis van Beelen has written the helper program “rs232-console” to connect to a host using a serial link. Dave Ault tested the serial link to his PDP-11/73. The historical plot data for the Tektronix 4014 was obtained from Jos Dreesen. The special plot mode pictures with variable brightness were obtained from Monty McGraw. He also helped to debug the special plot point mode. The historical plot data of the spacelab from the ICEMDDN CAD package on a CDC Cyber 175 mainframe emulator was obtained from Nick Glazzard. He also helped to improve the GIN mode substantially. The CP/M GSXBASIC plot files are from Udo Munk. Thanks to Ian Schofield for his critical comments and a code snippet for drawing dashed and dotted lines, and to Oscar Vermeulen and Mark Matlock for their support. The manuals were obtained from bitsavers.org. Thanks also to all others who contributed important ideas, helped with the debugging and preserved the historical data. This program is the result of a community effort.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

tek4010's Issues

Using tek4010 with a telnet 3270 server

Hello,
I recently built this project on the latest Debian and was trying to use it like an interactive terminal. However if I run anything the application starts but any keyboard input I provide is not passed on to the application. I have read the documentation and don't see anything I'm doing wrong but I may be. If you could give any pointers as to why this would happen I'd surly appreciate the assistance because I'm chasing my tail here.

Thanks,
Vincent

ARDS mode does show a few wrong vectors in chain.pic

This appears to be a tek4010 problem. A few vectors go in the opposite direction as to where they should.

Improve and rationalize vertical positioning of characters

tube_drawCharacter draws an individual character at the position windowHeight - tube_y0, using cairo_show_text
see https://www.cairographics.org/manual/cairo-text.html#cairo-show-text

I haven't found a clear definition of how the character is placed vertically, but I think it's the lower left corner.

I also haven't found a clear definition where the character should be placed vertically in the Tek 4010/4014 manuals, but again I assume it's the lower left corner.

The current version seems to look ok at different windows sizes.

The ARDS manual says the symbols are plotter below and to the right of the current beam position. Therefore, a correction of the character size needs to be applied. vDotsPerChar cannot be used for that, because it is the number of dots in the window between two lines, and not the character height. We need to get that information and either pass it back to the decoder or apply it directly where we obtain the information.

Implement Tektronix 4015 emulation with APL keyboard and character set

The manual of the Tektronix 4015 is available at http://bitsavers.informatik.uni-stuttgart.de/pdf/tektronix/401x/

The 4015 has a APL keyboard and an alternative APL character set.

For now I will implement the APL character set using the scalable APL385 font and a code translation table.

Alternative mechanism for shell wrapper?

In your Readme you write "The emulator does use "rsh" or "telnet", because historical Unix systems do not support the secure ssh protocol, and because ssh does not allow using a virtual emulator such as tek4010 for security reasons."

I appreciate that it would be a significant restructuring, but have you considered wrapping the Tektronix input and output filtering around code based on the unix 'script' command instead? 'script' without the logging (or even if you keep the logging for debugging purposes) gives you a very accessible place to intercept keyboard input and tty output - and all linux commands work as normal within 'script', so there would be no need to prohibit the use of ssh for connections to some other system that may be generating Tektronix-like output.

Script for debian linux (which compiles easily on the Raspberry Pi for example) can be found at:
wget http://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.38/util-linux-2.38.tar.gz

• just ./configure, and "make script"...

(I've been doing something similar to enable a linux shell to use a Vectrex vector display, so I know this can work)

The only downside of this approach is that it is only as portable as the version of 'script' that you base it on, so it may be more appropriate as an addition to the existing mechanism rather than a replacement for it as I doubt it would work under windows or BSD.

regards,

Graham Toal [email protected]

Terminal integration support

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.

Break Key

Hello,

First, thanks for this emulator. Very interesting!!

Is there any provision to be able to send a break with it, as per the Break Key available with the Tektronix keyboards? Needed to have a emulated system to ask for login.

Thanks!

Guy

some issues compared to xterm

1st. Thanks a lot for this! Output really looks GOOD!
Some issues compared to xterm -e cu -l /dev/ttyUSB1 -s 9600
(small avrcpm usb-serial cp/m system connected)

1. line/output goes after last line from left bottom to half line right top - and continues until right bottom - than goes to left top - when pressing just return and system answers with A> prompt.
2. tek4014 also does no screen clearing, when it scrolls/should scroll.
   In both cases, xterm does, what was expected:
3. scrolls after last line reached + clears screen when scrolling
   --
   This arduino demo does work on output side, but NOT at GIN/input mouse side at all:
   https://forum.arduino.cc/index.php?topic=523751.0

best, Peter

libGL error: MESA-LOADER: failed to retrieve device information

tek4010 gives then following warning during the first call after a bootup:
libGL error: MESA-LOADER: failed to retrieve device information

This is a Raspbian problem
https://www.raspberrypi.org/forums/viewtopic.php?t=193902

Has no impact whatsover.

Alpha mode characters should be drawn as dots

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

Remove apltest binary from git repo and add to gitignore?

I build Tek4010 on a non-Raspberry pi, non-Linux system, and test it out using a freshly built apltest. To do this I have to maintain a local branch with some tiny modifications that remove some minor linuxisms, and keep that branch rebased off of master to stay up to date.

The presence of an RPi binary for apltest in the repo makes using git a little difficult, just as the older presence of the tek4010 binary used to.

It would be great if the apltest binary could be removed from the repo and apl/apltest added to .gitignore just as was done recently for the tek4010 binary.

Building on Windows with Cygwin/CygwinX

I've build Tek4010 on a Windows 10 system with Cygwin/CygwinX. For compiling a small change in tube.c was necessary, because FIONREAD is defined in another header file than under Linux:

...
...
#include <pwd.h>

#ifdef` CYGWIN
#include <sys/socket.h>
#endif

#include "main.h"
...
...

Here are screenshots from Tek4010 running with my virtual z80pack machines. The option -autoClear is a real nice addon and allows much easier usage of the terminal from a CP/M system.

Change foreground and backdround colors

Which files do I need to edit to change the drawing colors?

tek4010 is too slow or choppy on slow systems

tek4010 version 1.8 or later may not run fast enough on slower systems such a Raspberry Pi 3 in full screen mode. The emulation of the fading spot requires too much computer resources in in such a situation. Use version 1.9 or later and call tek4010 with the -fast option. The bright drawing spot is still emulated.

Test tek4010 on Raspbian Buster and Raspberry Pi 4

Testing planned during second half of July. Any feedback is welcome.

Program refuses to create a full screen windows

Hello, have an issue trying to get a full-screen window.
Build a "custom retro terminal" like you do but I'm using a CRT screen that is 1024x768.
My idea is to run the tek4010 on full screen, when launching the emulator on x-windows (x is in 1024x768) the emulator always creates a window-sized "903 x 688" passing the parameters -full or -fullv seem to have no effect.
When the software starts shows "tek 4010 version 1.6 Screen dimensions: 1024 x 768" so the resolution seems to be recognized correctly. But the final line output in xterm before opening the new window is "Window dimensions: 903x688 Scaling: 0.220"
There's any way to force the windows to be 1024x768 ?.

Thanks!.

Spurious '38h's appear at all vertices on Matrix Brandy BASIC Tek output

This may be more of an issue with stardot/MatrixBrandy BASIC's Tek output thank Tek4010's rendering, but testing output with three different Tek rendering devices gives the following results:

• xterm: output as expected

• tek2plot (GNU plotutils): output as expected

• Tek4010: spurious output on display.

The following Tek commands from Matrix Brandy BASIC should draw a square rotated 22° anticlockwise in the centre of the screen:

00000000: 1b5b 3131 3b33 306d 1b5b 3430 6d1b 5b3f  .[11;30m.[40m.[?
00000010: 3338 681b 0c1b 031b 5b32 4a1b 5b48 1b5b  38h.....[2J.[H.[
00000020: 3f33 3868 1b03 1b5b 3f33 3868 1d2f 7128  ?38h...[?38h./q(
00000030: 4234 6333 4b1f 1b03 1b5b 3f33 3868 1d2f  B4c3K....[?38h./
00000040: 7128 4224 682c 541f 1b03 1b5b 3f33 3868  q(B$h,T....[?38h
00000050: 1d24 682c 5428 7a37 5d1f 1b03 1b5b 3f33  .$h,T(z7]....[?3
00000060: 3868 1d34 6333 4b28 7a37 5d1f 1b03       8h.4c3K(z7]...

(zipped output: http://scruss.com/wordpress/wp-content/uploads/2019/11/mtxbrandy_box_tek.zip)

This is what the output from tek2plot looks like:
http://scruss.com/wordpress/wp-content/uploads/2019/11/mtxbrandy_box_tek2plot.png

The output in an xterm window looks similar, and is as expected.

The output from Tek4010, however, has spurious characters at the top left and at every vertex:
http://scruss.com/wordpress/wp-content/uploads/2019/11/mtxbrandy_box_tek4010.png

Tek4010 no longer clears screen during demos

Commit bdf1bed ostensibly changed tek4010 to clear the screen only with ESC FF rather than just FF, but seems to have disabled clearing the screen at all.

./tek4010 -noexit ./idemo.sh

winds up not clearing the screen at all between plots. The plotfiles also have ESC FF in them to clear the text from one screen and let the graphics show. These do not work either.

If I undo commit bdf1bed, the demos perform as expected.

tek4010 screws up on lower resolution displays

Any display having less than 1024x780 dots available in a decorated window is not handled properly in normal (not full) mode. It has to use scaling in such situations and pay attention to the actual window size supplied by the window manager, not the requested size.

This is a very serious bug because it affects many popular Raspberry Pi displays. I hope it can be fixed today.

The plan is to open the largest possible decorated window with the proper aspect ratio in such cases. Resizing the window will not be supported, as this is not compatible with the storage tube implementation.

screen modes

I have an xterminal the maximum screen mode is 1024x768.
is possible to make the program run in full screen ?, and cut a small piece of the display.
Because the resolution it will reduce the screen size to 640 now.

GIN mode returned coordinates are not scaled

Need to use efactor to scale coordinates

ARDS mode

Would you accept a contribution to add an ARDS mode?

http://www.bitsavers.org/pdf/computerDisplaysInc/RM86802_ARDS_RefMan_Dec68.pdf

Skipping frames

If individual frames are skipped rather than shown on the screen, only certain parts of the drawing are highlighted. The bright spot animation does not show up for all drawn objects. But all objects are drawn properly.

The reason for this is that my current implementation of gtk3+ and cairo in main.c assumes that each call to tek4010_draw() or ards_draw() actually ends up in a frame shown on the screen. But this assumption is wrong. The gtk3+ implementation does not show frames on the screen faster than the actual screen refresh rate, and just skips frames under these circumstances.

This happens with very high resolution displays, or if actual frame rates are low in virtual environments such as VirtualBox.

The goal is to put something into place to make sure that each frame is actually shown on the screen, without affecting overall speed or cpu/gpu usage. Version 1.2.3 has improved this already by forcing a short delay after each call to tek4010_draw() or ards_draw().

Cannot close tek4010 windows if the calling terminal window is closed

This only happens sometimes. Needs to be fixed.

Workaround:
close the tek4010 window first

If it has happened:
Opening any other window will close that orphaned window

Binary executable in the repository

The Tek4010 contains binary blob on it's master branch. There's an executable binary file called tek4010 which needs to be removed, otherwise the make command won't build binary for a specific system. Having rebuilt/usable binary causes git to print error message whenever I want to pull from upstream.

Note that you already export 6 releases for this project and that's the right place for executable binary files.

Moving window under wayland does not work

This seems to be a Wayland/gtk3 problem

PAGE resets font size

According to the 4014 manual the PAGE key and the ESC+FF sequence are equivalent and should not reset the font size.
I know there is the -keepsize option, but it seems to be more of a hack to be honest. The RESET key should reset the font size, but this key doesn't seem to exist in your emulation.
EDIT: just to clarify, I suggest to get rid of the keepsize option and instead implement the RESET key.

Serial communication

On an older 10.9 OSX system I'm not able to build the RS-232 serial console program. I have not bothered to have a closer look at it, because back in the day we used 'cu' for serial connections to other systems. Nowadays any modern UNIX system still comes with Taylor uucp, which also includes cu. To connect to my IMSAI 8080 replica I use:

sudo cu --parity=none --nostop -l /dev/tty.SLAB_USBtoUART -s 115200

To leave cu type: ~.

Use of gcc

Hello,

The use of gcc is hard coded in the makefile. Some platforms does not have gcc installed. I suggest using $(CC) which should be the right C compiler.

Tek4010 and CP/M's DrDraw on ZX Spectrum +3

Hi,

As I've accidently found CP/M's GSX driver for Tek4014 (written by @udo-munk in 2014) , I wanted to give it a try with DrDraw (despite my age, it's the only CP/M program I know that fully utilizes GSX capablilities). I've connected an old ZX Spectrum +3 to the USB serial port on my Linux PC, compiled and started Tek4010 and redirected CP/M console to the Spectrum +3's built-in serial port. On the Tek4010 window I could observe output as in the first attached screenshot:

So far so good. I've started DrDraw, and after a while, its main menu appeared, as in the second attached screenshot:

Now, from this point, I really don't know what to do. According to the manual, "Create" option should be highlighted by default with inverse colors, Tab (or Crtl+I) and Backspace should move highlighted selection forward/backward, alternatively pointing device should be usable. Nothing like that is happening. By stroking keys in random I managed to force DrDraw to ask me for a filename, yet typing the name started to cause more and more mess on the screen, and the Tek terminal seem to have problems with erasing things that should not be displayed anymore.

I've started Tek emulator as such:

./tek4010 -b4800 -fullv ./rs232-console -p ttyUSB1 -b 4800 -m 8N1 -f hardware

I've redirected CP/M console on the Spectrum side as such:

device con:=sio[noxon, 4800]

From my experience, going faster than 4800bps causes communication errors (+3's serial port is just an bit-banging interface hooked to the spare I/O ports of the AY programmable sound generator).

I don't know if this is a real bug and if it is, on what side it should be addressed (Tek emulator or Tek GSX driver), yet I'm reporting it here for a reference.