Projects like the VecFever, and PiTrex, exist to make it possible to combine vector displays with much more modern CPU technology, allowing emulating even old Vector arcade titles like Star Wars or Battlezone.
It is criminal that Vector Computing never took off past the 1980s, and has died. Nothing, not even OLEDs (sorry Vectrex-Mini guys!) can replicate the beauty of phosphor glow.
Speaking of amazing forgotten lighting effects, the techniques for the cool lighting effects used in Don Bluth films (and his games like Dragons Lair) are also forgotten/unused and I find them analogous to vector displays.
I find the death of Vector Displays and the cool display tech Don Bluth did to be great examples of "Worse is Better" and counterexamples to the idea that progress overtime inevitably makes things better.
I wanted a TechTronix vector computer super bad, and still do, especially the one's with the fast 3D and color add-ons.
I'll drop a few motivating videos:
0. https://www.youtube.com/watch?v=M98VOoGFLL8 (TekTronix 3D/Color stuff)
1. https://www.youtube.com/watch?v=8Dv15YRAmzM
2. https://www.youtube.com/watch?v=j60DV0Ujp_E
I wonder if Lars got a GT40 emulator working with SIMH:
https://simh.trailing-edge.narkive.com/1AQn3HSi/simulating-a...
https://fritzm.github.io/gt40.html
This looks like it:
https://github.com/Isysxp/GT40
Playing Moonlander (LEM):
https://github.com/Isysxp/GT40/blob/master/PDP11/lunar11/lun...
The restoration of a GT40 to play lunar lander | VCFMW 18 (2023):
The original Tektronix terminals (I only ever saw one once) did all screen drawing with these vector commands (think the look of the classic Asteroids game which I think may have used a similar hardware interface to the CRT display), which naturally was not especially fast for ordinary text which is why hybrids like the abovementioned VT-series terminal (I think it was the 240/340/440 that had this) ended up supplanting the Tektronix displays.
What do you mean?
* Copyright 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley
*
* Permission to use, copy, and distribute this software and its
* documentation for any purpose with or without fee is hereby granted,
* provided that the above copyright notice appear in all copies and
* that both that copyright notice and this permission notice appear
* in supporting documentation.
*
* Permission to modify the software is granted, but not the right to
* distribute the complete modified source code. Modifications are to
* be distributed as patches to the released version. Permission to
* distribute binaries produced by compiling modified sources is granted,
* provided you
* 1. distribute the corresponding source modifications from the
* released version in the form of a patch file along with the binaries,
* 2. add special version identification to distinguish your version
* in addition to the base release version number,
* 3. provide your name and address as the primary contact for the
* support of your modified version, and
* 4. retain our contact information in regard to use of the base
* software.
* Permission to distribute the released version of the source code along
* with corresponding source modifications in the form of a patch file is
* granted with same provisions 2 through 4 for binary distributions.
*
* This software is provided "as is" without express or implied warranty
* to the extent permitted by applicable law.No graphics, though, not even TRS-80-style pseudographics. Not even inverse video.
I remember being skeptical that all that electronic map data would be very useful to anyone outside the agency without all of the required hardware. How little I knew!
kitty doesn't have Tektronix vector support right? Would be cool if they would consider adding.
But something interesting happened recently which is that it is now apparently a given that terminal programs support raster graphics. At least, the people at r/command line were treating it as such when someone recently posted a program that requires something like kitty graphics protocol to work at all.
The kitty raster protocol is somewhat efficient. It could be interesting to combine that with some ideas for low latency lightweight computing and social networking.
The simplest version of that might be just to have a group of people start setting up some type of BBSs over ssh, but designed to upgrade the graphics just slightly over ANSI, or even perhaps combined with ANSI. People could use emulated vector monochrome graphics for some screens if they wanted that Tek vibe.
Another step up possibly would be to make a few STUN/TURN servers or some setup so people on IPV6 could find and each other even if at home and if IPV4 still connect with whatever NAT traversal or maybe there can be such as thing as ssh over WebRTC? That might not make sense.
You could also make it content centric and set up something to easily do RSS over IPFS (I assume that exists) with a group that has agreed they will target ANSI plus kitty graphics with some set document size limits to keep things fast and lightweight.
Because kitty graphics are based on escape codes, you might also use such a social network for distributing lightweight (binary size limited) web assembly applications and games that are designed to run in a terminal supporting that. Because web assembly runtime support for text output is good I believe.
I do think that there should be some built in load latency or data size limit tested and enforced somehow to ensure that you keep the snappiness possible with text interfaces.
They were massive and printed a whole page at a time, similar to the thermal page printers from Perkin-Elmer for their model 3600 Intelligent Terminal of the early 1980's, but P-E printers were much smaller by then.
3600 had vector graphics too, these were very expensive but introduced the form factor of a horizontal box with two 5 1/4 floppies, monitor on top and wired keyboard with the first row of "F" function keys people had seen. Which is the desktop form that was later adopted by IBM when they issued their first PC.
A Williams Tube?
On a CRT with storage for oscilloscopes or computer monitors, you looked at the stored image, which is why they were called "Direct-view bistable storage tubes".
On the Williams tubes, the processor read back the data stored in the tube, i.e. the stored image was used by the CPU, not by humans, so Williams tubes had no need to contain fluorescent screens. On a viewing tube, there was usually no need to implement a read back method, but only means for writing and erasing.
Both the Williams tubes and the direct-view storage tubes were derived from the iconoscope tubes used before WWII in the early television cameras, according to a proposal made in the famous von Neumann report. In iconoscope tubes, illumination caused by an external image projected on the tube face created an electric charge distribution inside the tube, which was read electronically, generating thus a video signal, so it was the inverse of a direct-view tube, where an electric charge distribution is written inside the tube, where it controls the fluorescence of the screen, creating an image that can be viewed outside. Both iconoscope tubes and direct-view storage tubes differ from simple CRTs by having inside an insulating or semiconducting surface on which a distribution of electric charge can be stored.
The Williams tubes were a form of DRAM. An even earlier kind of DRAM had been used in the Atanasoff-Berry computer, where it was implemented with discrete capacitors and John Atanasoff had been the first who proposed to make a computer memory based on storing electric charge and refreshing it periodically, to prevent discharging.
You could also just mess with the horizontal/vertical position knobs and use it as a very expensive Etch-a-Sketch.
https://en.wikipedia.org/wiki/Storage_tube#Storage
Unlike a television CRT, the storage tube will "remember" everywhere the electron beam struck the screen as long as the voltage is below the erase threshold.
What's wild is that this information can be read back out of the device. So, it's not just a display but also memory. It's a destructive reading process (not unlike core memory) where detection is also erasure, but it really is RAM... of a sort.
However, I am compelled to point out that it doesn't have a "1024*780 pixel resolution", because it doesn't have pixels. Maybe "1024*780 vector endpoint precision"?
[0] Unix program to format high quality printed documents, similar to newspaper/magazine/book printing
[1]machine using photographic paper to output typeset pages, supporting a variety of fonts
Scroll Saver disassembly: https://github.com/PDP-10/its/blob/f6408e16cb1aaf7f2583c02cd...
My kludge to parse it into Hershey JHF format: http://canonical.org/~kragen/sw/dev3/imlacparse.py
The resulting Hershey font: http://canonical.org/~kragen/sw/dev3/imlac-pds-1-ssvchr.22.j...
Its appearance rendered: http://canonical.org/~kragen/sw/dev3/smolhershey-imlac.png
My 400-byte BSD-licensed C library for using Hershey fonts: http://canonical.org/~kragen/sw/dev3/smolhershey.md.html
If someone does get the Tek font, I'd love to do the same thing with it.
You should have seen the digitizing tables 4 feet square, and the oversized plotters that were surplus from oil companies after the oil price crash at the end of 1981.
https://bitsavers.org/pdf/tektronix/405x/070-2142-02_Tek_405...
>No[t yet…]
I believe in the community making this a yes.
> within the culture of DROE, simply getting Doom displayed on the screen of a novel device has been sufficient to consider the game played on that technology
Source: https://docs.google.com/document/d/1SFm1dS6myqq7psBKttP7CVYN... “1-Bit Pixels Encoded in E. Coli for the Display of Interactive Digital Media”
This is cooler than cool.
