for a nutshell history, please see the decwar/history readme and for push button installation and usage please see the decwar/merely-players readme
vector display of the galaxy for 'watching' a decwar game. want to read game data from a local json file. the json file can async update periodically in whatever manner, and the display can async update from it. total separation between decwar and the display, via the json file.
the reference baseline here is the original sage display and its direct descendant dec 30 / 340 display. a more modern, eighties, example is tempest. note from this wiki discussion that an important factor was the cost of core memory. only vector endpoints needed storage, providing what was in some sense 'image compression'. this could be a useful definition for 'vector display' in the decwar context. only certain positions are specified / stored, ideally in an arbitrary floating-point space.
in a vector display, the image is composed of drawn lines rather than a grid of glowing pixels as in raster graphics. the electron beam follows an arbitrary path, tracing the connected sloped lines rather than following the same horizontal raster path for all images. the beam skips over dark areas of the image without visiting their points. some refresh vector displays use a normal phosphor that fades rapidly and needs constant refreshing 30-40 times per second to show a stable image. these displays, such as the imlac pds-1, require some local refresh memory to hold the vector endpoint data. other storage tube displays, such as the popular tektronix 4010, use a special phosphor that continues glowing for many minutes. in the 1970s, both types of vector displays were much more affordable than bitmap raster graphics displays when megapixel computer memory was still very expensive.
vector displays have no direct historical connection with decwar. with modern robots playing however, a way to watch the whole galaxy is useful and vector display would be fun. there's at least an indirect connection, as trek / decwar grew from around 1971 because of the lack of a pdp-1 display. the iconic 'scan command' ascii art output, often seen via teletype as well as crt, was a practical solution for low end hardware.
to approximate some of the characteristics of a sixties vector display crt, the dec type 30 is a useful reference baseline. based on common sense, it was a direct descendant of the sage terminal crt. both were 16 inch circular tubes, both worked with light-guns, and both were created by the same people in the boston area. dec was essentially a commercial splinter from the sage project.
for a circular 16 inch tube face, the largest square has sides of length 16 inches / sqrt(2) = 11.3 inches. the type 30 had 1024 x 1024 coordinate addresses within a 9.5 inch square on the tube face. so the usable square on the display was approaching the largest square possible, with sides sacrificing roughly two inches to avoid the edges of the tube face.
at the center of a 9.5 inch square side, the edge of the tube face was (16 - 9.5) / 2 = 3.25 inches away. this seems to somewhat roughly agree with the relative sizes of the tube face and of the 'square of dots' in this photo of a sage display. if the sage display provided the maximum 11.3 inch square, that would change to (16 - 11.3) / 2 = 2.35 inches. possibly the photo's 'square of dots' is the full 11.3 inches. the corners of the 'square of dots' do appear to be approaching the edges of the tube face.
just collecting interesting and fun discussions. to avoid confusion between 30/340, xyz is used here.
The xyz was an early vector graphics display, that was used for an astonishingly wide range of applications for the 1960s. It used a 16-inch circular CRT with high persistence phosphor originally designed for use as a radar screen, and the resolution (presumably determined by the DEC-built digital electronics) was 1024 x 1024.
I've been trying to look up just how quickly it could refresh, and the figure I'm seeing is one operation every 50 microseconds, which seems straightforward enough, but https://www.masswerk.at/nowgobang/2021/spacewar1
The PDP-1 is capable of displaying a maximum of 20,000 dots per second — assuming our program doesn’t anything other than issuing display command. Which gives us, with a reasonable frame rate for a flicker free display of, say, 18 fps, about 1,100 display instructions per frame, which is just good enough for a single line accross the display.
That didn't look quite right, so a bit of searching found what looks like an original manual, http://www.computinghistory.org.uk/userdata/files/digital-precision-crt-display-type-30.pdf
Discrete points may be plotted in any sequence at a 20 kilocycle rate (one point every 50 microseconds)
Okay, that does seem to confirm.
... huh? In a vector display, the fundamental operation is not plotting a point but drawing a line between two points. That's useless if what you want to show is a photograph, but great for things like circuit diagrams, molecule diagrams and suchlike visibly geometric things that were representative of early graphical applications.
If you can only do one point at a time, well it will still work in principle, but effective performance will drop by orders of magnitude, and you lose the ability to draw lines at angles that don't necessarily stick to the grid of points defined by the resolution.
Did the xyz really only draw one point at a time? If so, why? Had a vector display just not been thought of yet, or was there some other reason it couldn't be done?
maybe we should clarity that the xyz display used with the PDP-6 and other PDP computers was still point plotting. It was just that the display hardware handled plotting the points on a line autonomously on command from the main CPU. The display could also draw characters. – Lars Brinkhoff CommentedMay 28, 2021 at 7:18
This might just be stating the obvious, but xyz manual linked in the question describes the device as a random-position point-plotting cathode ray tube. Nowhere does the manual suggest it's a vector graphics display.
It then further describes how the computer supplies the X,Y coordinates of a single point to be plotted. There is no facility to plot a line.
The description of the Spacewar game gives some clues that the xyz was not able to display lines, but instead dots.
Towards the end of the description, there is the listing how the spaceships were rendered, and even linear sections were given as repeated individual dots. With a true line-rendering capability, the engineers had surely used that instead of the single-pixel approach.
And, from a technical point of view, producing a line on an X/Y display has a few quirks. To have short and long lines appear with the same intensity, you need to move the beam with constant speed, meaning that long lines take more time than short ones, which doesn't fit the documentation of an apparently fixed 50-microsecond cycle.
And you need circuitry to do a linear interpolation between start and end point of the line. Around 1961, I bet that integrating a digital solution (based e.g. on Bresenham's algorithm) was no option - it was invented in 1962 at IBM, if Wikipedia is correct, and would need complex digital circuitry close to an ALU. So, it would have been based on analog processing, and apparently, the DEC engineers decided not to go that way.
The xyz input commands worked in several different "modes", including point mode, vector mode, and character mode (with an optional character generator).
The actual xyz display was always point-based, unlike the Tektronix 4011/4014 displays which drew straight line vectors using analog circuitry.
The "internal clock increment" for rasterizing vectors to points was 1.5 microseconds.
https://groups.google.com/g/pidp-10/c/zRqPCo5_S1A/m/GyNDbTGgCAAJ