I have been working lately on creating new image files to display on Tektronix 4050 computers.
I posted a new folder in my Tektronix program repository for these images and programs:
https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/SVG-to-Fast-Graphics-R12
Since vintagetek.org has been selling their updated Tektronix 4051 MAXIROM which includes the Fast Graphics / 4051 R12 Graphics Enhancement ROM,
https://www.ebay.com/itm/115028129145
and 4052/4054 users can purchase Jos Dreesen's 4052/4054 Multi-function ROM Pack (MFM) which not only includes 8 ROMs but adds a TransEra Real-Time-Clock plus Tektronix 4052/4054 Serial Printer Interface:
https://www.vcfed.org/forum/forum/genres/other/76192-tektronix-4052-4054-multifunction-modules-available
which can hold my posting of the 4052 R12 Graphics Enhancement ROM and other great 4052 ROM packs posted on my repo:
In addition to the 4051 MAXIROM, vintagetek.org also has been selling their 4051 RAMPACK
https://www.ebay.com/itm/115063476625 which replaces the internal tape drive with solid state storage. They include Micheal D. Cranford's Fast Graphics files preprogrammed into the RAMPACK.
My work with
WaveyDipole on a GPIB Flash Drive for all Tektronix 4051/4052/4054 computers is almost ready to offer, and also replaces the internal tape drive with a microSD flash drive and Arduino microcomputer.
One major issue with the 4051/4052/4054 R12 Graphics Enhancement ROM is the CALL "IMAGES" command to read the Fast Graphics files only works with the internal tape drive
Michaels' Fast Graphics ROM in the MAXIROM adds the capability to read FG image files from the RAMPACK with a different command.
I found a workaround to do the same thing with a short BASIC program and the GPIB Flash Drive.
The Fast Graphics/R12 image file format uses three 7-bit ASCII characters for each 10-bit X and Y data point including one bit for MOVE/DRAW.
This means the data will include the 32 control characters including Carriage Return (0x0D), and therefore cannot be handled with the INPUT command, which will terminate each INPUT of a character string when it finds a CR and will delete the CR.
My workaround is to use the binary READ command with my Flash Drive - which supports both numeric and string variables, although the maximum string length is limited to 8191 bytes.
The example program below assumes the image data file has been converted from ASCII FG format to BINARY string format with each string limited to 3000 bytes, and a final string of "|EOG|" terminates the file.
Code:
100 INIT
110 DIM S$(20000),T$(3000)
120 PRINT "Input FG file #:";
130 INPUT F0
140 S$=""
150 FIND @5:F0
160 READ @5:T$
170 IF T$="|EOG|" THEN 200
180 S$=S$&T$
190 GO TO 160
200 CALL "RDRAW",S$,1,0,0
210 END
The two advantages of using the Fast Graphics/R12 format for images is the huge (over 10x) performance speedup, and the smaller image file size versus BASIC MOVE, DRAW commands.
The smaller file size is very important due to the limit of 32KB of RAM in the 4051.
All of the FG image files expect the image to be loaded into RAM, and then displayed with one of the FG/R12 option ROM CALLs, such as RDRAW.
However, since the FG format is a regular pattern of 3 bytes per vector endpoint, I believe the FG images can be larger than available RAM if the file is read in 3000 byte 'chunks' like my program above. After READing a chunk - the program could CALL "RDRAW" that chunk and eliminate the need for the large string entirely!
Another advantage of using Fast Graphics images is the commands like RDRAW can transform or offset the display of the data - so the image becomes an object!
I take advantage of that in my new image of the three main Star Wars DROIDs: C-3PO, BB-8, and R2-D2.
There was an R2-D2 Fast Graphics image in Micheal's original demo files - hand digitized, that I have already posted.
I decided to try to create a new set of FG images for all three droids - and found a way to use Inkscape with images I found on the web to create vector files that I could use.
I found the Inkscape SVG output format was very optimized for file size and did not include the "L" in front of each draw command, plus did include curves - which I found very hard to emulate on the Tektronix. So I saved the Inkscape output in HPGL format - which targets CNC and only has move and draw commands. Since I had already created a Tektronix BASIC program to convert SVG files that only contained "M" and "L" (move and draw) commands, I used Notepad++ to convert the Inkscape HPGL files into pseudo SVG files only containing M and L commands. Then I used my SVG to FG conversion program to scale and convert the 'SVG' file into the 3-byte ASCII FG format.
My short Star Wars program first loads and displays the "Star Wars" and "DROIDS" images, then loads and displays the three droids - taking advantage of the CALL "SCALE" command to resize the BB-8 and R2-D2 images, and move the images into their proper position:
Encouraged by this process - I wanted to try to create an FG "TEAPOT" image, since the 4010 teapot.plt file from Chuck Forsberg's demo is NOT the right file, I used Blender, which includes a TEAPOT image, and used the technique posted in this youtube video "Exporting vector files from Blender"
https://www.youtube.com/watch?v=t0h-LzO84-g and created this image:
This photo is from my 4054A. I notice the lines are not straight - that is not a 4054A issue - I believe the Blender conversion to vector format introduced multiple line segments.
I also edited the Blender SVG file in Inkscape since the Blender output did not connect the neck of the teapot to the body, so I manually added those lines. I didn't notice these artifacts on my 4052 output - since the 4052 vector lines are much wider than the 4x higher resolution 4054 vector lines.
Here is the 4052 Teapot photo: