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

[pawosm-arm]

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.

[udo-munk]

Hello,

when I wrote the Tek driver I only had UNIX xterm available, that includes a Tektronix 4014 emulation besides the ANSI terminal. This terminals are vector units with a storage tube, that allows to draw a vector, but not to erase one. After some drawing only the whole tube can be erased.

DrDraw was written for graphics terminals which can set and erase pixels and graphics primitives are used to erase and redraw parts of the screen. This is not going to work without a terminal that supports this, so it is difficult to use the program with the Tek driver.

I don’t know the terminal emulation you are using and it’s capabilities, but it might be possible to improve my driver. There have been Tektronix terminals with redraw and/or erase vector options, for one of these a better driver can be written, or the existing one improved.

Best regards, Udo

On 14 Jan 2020, at 16:23, pawosm-arm notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

Hi Udo,

Thanks for your comment. I'd never expected to use xterm for that purpose, but combined with rs232-console program (as recommended by Tek4010) it does something similar as Tek4010 can do. I've tried following:

xterm -t -baudrate 4800 -e ./rs232-console -p ttyUSB1 -b 4800 -m 8N1 -f hardware

yet the outcome (and the problems) was similar to what I could observe with Tek4010.

Is your driver (I've found version 1.5 from 2014) expecting particular version of GSX.SYS? The one shipped with DrDraw is 1.1 (01 Oct 83) while the one I've found along with GENGRAF.COM v1.0 is... 1.0 (15 Nov 82).

Thanks, Paul

[udo-munk]

Hi Paul,

you’re welcome. Nowadays most people are not aware anymore about the Tekronix emulation included in xterm, one of the reasons I wrote the driver for this, a Tektronix (emulation) is available everywhere. Yep, the outcome is the same, the documentation for xterm mentions that it emulates a storage tube and that this doesn’t support erasing of a vector once drawn. I don’t know about the Tek emulation you are using, need to have a look sometime what it can do … DRI made two versions of GSX-80, 1.0 and 1.1, you’ll find disk images with both in the z80pack repository here:

https://www.autometer.de/unix4fun/z80pack/ftp/

The driver works with both versions, there were no changes in the graphics API, only internal improvements.

There also was DrGraph, a tool for generating charts on graphics terminals. This one works better with xterm, because it switches between the text terminal und the graphics terminal. The text terminal is used for menus and data entry, while the Tek is used to draw the charts on it. Disk image also available at the link above, besides several other GSX-80 programs.

Enjoy, Udo

On 14 Jan 2020, at 22:22, pawosm-arm notifications@github.com wrote:

Hi Udo,

Thanks for your comment. I'd never expected to use xterm for that purpose, but combined with rs232-console program (as recommended by Tek4010) it does something similar as Tek4010 can do. I've tried following:

xterm -t -baudrate 4800 -e ./rs232-console -p ttyUSB1 -b 4800 -m 8N1 -f hardware yet the outcome (and the problems) was similar to what I could observe with Tek4010.

Is your driver (I've found version 1.5 from 2014) expecting particular version of GSX.SYS? The one shipped with DrDraw is 1.1 (01 Oct 83) while the one I've found along with GENGRAF.COM v1.0 is... 1.0 (15 Nov 82).

Thanks, Paul

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

Hi Udo,

Thanks for all of your tips! Now things are getting more clear.

Thanks, Paul

[pawosm-arm]

I think the issue can be closed. Tek4010 does what xterm does, so there's no error.

[udo-munk]

Had a brief look at the Tek4010 project on GitHub. In the overview it says:

• All Tektronix 4014 modes, including graphical input mode (GIN) and write-through mode And write-through is what xterm is missing, with this one can write a better driver.

On 14 Jan 2020, at 22:22, pawosm-arm notifications@github.com wrote:

Hi Udo,

Thanks for your comment. I'd never expected to use xterm for that purpose, but combined with rs232-console program (as recommended by Tek4010) it does something similar as Tek4010 can do. I've tried following:

xterm -t -baudrate 4800 -e ./rs232-console -p ttyUSB1 -b 4800 -m 8N1 -f hardware yet the outcome (and the problems) was similar to what I could observe with Tek4010.

Is your driver (I've found version 1.5 from 2014) expecting particular version of GSX.SYS? The one shipped with DrDraw is 1.1 (01 Oct 83) while the one I've found along with GENGRAF.COM v1.0 is... 1.0 (15 Nov 82).

Thanks, Paul

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

That idea sounds really cool! It could provide means for interactive graphics to Speccy's CP/M. BTW, do you have plain .tar or .zip archive with gsxbasic? The .dsk format you're using is incompatible with CPCEmu format that I'm using, my tools can't extract files from your ftp :(

[udo-munk]

No, but the disk images are IBM 3740 format (8” single side, single density, 26 sectors/track, 77 tracks). Use cpmtools to access these images, the tools can access most disk formats that have been used with CP/M.

On 14 Jan 2020, at 23:24, pawosm-arm notifications@github.com wrote:

That idea sounds really cool! It could provide means for interactive graphics to Speccy's CP/M. BTW, do you have plain .tar or .zip archive with gsxbasic? The .dsk format you're using is incompatible CPCEmu format that I'm using, my tools can't extract files from your ftp :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pawosm-arm]

I've just learnt that gsxbasic is just a BASIC.COM treated with GENGRAF.COM. Thanks for the hint anyway :)

[rricharz]

Hi, I'm reading your comments here with great interest.

tek4010 is a faithful emulation of the original Tektronix 4010, 4013, 4014 and 4015 storage tube terminals. I have written in with the idea in mind, that people who still have historic systems (mainly of the 1970s), or replicas of such systems, can use it on their systems to provide the true original feeling of using these terminals, which were extremely important in the early history of high resolution computer graphics.

Therefore, tek4010 implements only the codes which were available on the original systems, and does not allow to erase any part of the screen, because the original hardware (storage tube) could only erase the whole screen.

The only compromises I have made to that goal of emulating the original terminals were in situations where the original experience could not be achieved on modern equipment except with some minor additions. One of those was to ignore ANSI escape sequences, which were defined later and used heavily on so called Tektronix compatible terminals. A second compromise is described below.

The so called write-through mode is implemented, which allowed to display a limited number of around 30 vectors in a non-permanent way, but these vectors had to be redrawn over and over again to be visible. Up to now we have really not found any historic programs which used this write through mode and have survived, but I have written a program to demonstrate it, see animation.c, tekio.c and tekio.h at

https://github.com/rricharz/pidp11-2.11bsd/tree/master/tek

Unfortunately this program has been written using the original Berkeley C, which was used in 2.11 BSD Unix on a PDP-11. But I could easily convert it to modern C. A video of what it does is at

https://youtu.be/7FMewaoEOmk

In order to look good on modern terminals without too much flickering and ghosting, I had to add some synchronization between drawing the write-through vectors and the screen refreshes. This is achieved by leaving and reentering write-through mode at the appropriate time.

If anybody is interested to write a driver for CP/M or any other systems, I am certainly willing to add any necessary additional hook to tek4010, which is required to emulate the original experience of using the historic Tektronix storage tube terminals. I think it would be very nice to be able to use a program such as DrDraw on this historical emulation.

[pawosm-arm]

For a completeness, three screenshots from running lissa.bas in gsxbasic on ZX Spectrum +3 with DDTEK driver. Fortunately, clearing screen works hence lissa.bas can clean Tek screen between drawings.

[rricharz]

Beautiful images! Would it be possible to capture the plot codes in a .plt file, so that users on other computers can make these plots? If yes, please send them to my email address and also let me know how you would like your work to be cited under "Contributors" in the README.md of this repo. Or, if you prefer, you could make a pull request adding a new subdirectory in pltfiles.

[pawosm-arm]

Sadly, I can't be a contributor from this account. Also, LISSA.BAS wasn't written by me, I've just found it shipped along with GSXBASIC. I'm attaching PLT interactive session drawing those images. You have my full permission to make whatever use of this file (including publishing it) you want. Best viewed with tek4010 started as such:

tek4010 -b4800 -fullv -autoClear cat gsxbasic.plt

gsxbasic.plt.txt

[udo-munk]

I build the GSXBASIC disk, because in CP/M dicussions the question about graphics often came up. In the early 80's I was using GSX-80 and GSX-86 at work and GSX-80 a bit at home too. For that I also had to write my own driver for my graphics card, so I'm familar with the stuff. For many of the early homecomputers graphics enhanced BASIC interpreters exist, so I had the idea to show how to do graphics with some BASIC from any CP/M system. The program drawing this Lissajous figures originaly was written in Mallard BASIC, the author of the program is unknown. I just rewrote it for Microsoft BASIC-80 and GSX-80 to draw the figures using the GSX driver I wrote for Tektronix terminals. Feel free to use the software and it's output as you like.

[rricharz]

Thanks. I'm putting these nice plot files in the directory pltfiles/gsxbasic.

[pawosm-arm]

As I've prepared GSX-utilizing xplgraph.scr library replacement for CP/M port of DXForth (see https://sourceforge.net/projects/xplgraph-cpmgsx-dxforth for more details), I'm attaching some more screenshots and .plt files here. Note that gsx-dxforth-crystal.plt is not safe for a person with epilepsy. gsx-dxforth-crystal.plt.txt gsx-dxforth-hilbert.plt.txt gsx-dxforth-mandel.plt.txt gsx-dxforth-sierpinski.plt.txt

[udo-munk]

Very nice plots. I had a look at the project page at sourceforge, there is says:

• No READPIX function. GSX does not allow reading from graphics device; also it's a bad design to do so.

This is not correct, GSX also supports raster graphics devices, one can set and also read pixels, e.g. for doing bitblit operations on the pixels for drawing a mouse cursor and such stuff. DRI calls it cell arrays in the documenatation and the implemetation is optional, because plotters, or a Tek storage tube cannot manipulate single pixels, these devices only can draw a vector. So it's not implemented in the Tektronix GSX drivers, but other drivers for memory mapped framebuffer devices have cell arrays implemented. Examples are the screen drivers for the CPC, Televideo 803 systems, DEC Rainbow and so on.

[pawosm-arm]

@udo-munk thanks for spotting this, I've corrected the project page. I assume you referred to GSX's function 27 purpose of which I must have completely got wrong. With GSX virtual resolution 32768x32768 I couldn't imagine how one could rely on it not being worried by rounding errors caused by aspect-ratio conversions.

[udo-munk]

Right, function 27. No rounding errors because it returns an array with the device pixels.