From Daniel Smith:
The time is 1964, the place is room 26-200 at MIT...
This program is impressionistic. It is an imitation, not a simulation. I wanted to capture something of the feel of running a display hack on the PDP-1, watching those mysterious, glowing, fading patterns. There is no PDP-1 emulator in this program. Nor does this program perform quantitative simulation of the phosphor decay. I just hacked around until it felt right. Oh, there's no processor-speed correction, either; it looks about right on a 400 MHz G4, your mileage may vary.
Display hacks were short programs, often less than a dozen instructions, that repetitively calculated new x and y values, then invoked the "dpy" instruction which plotted a single point on the screen. More accurately, the "dpy" instruction would position the beam at an x-y location, then turn the beam on so as to cause the phosphor underneath to glow. The PDP-1 display used a phosphor which was a mixture of a blue phosphor with a short-persistence bluish-white fluorescence and a long-persistence yellow phosphorescence. The PDP-1 manual doesn't say what kind it was, possibly P17. In a short loop, you could plot 20,000 dots per second, and the long persistence meant that about a seconds' worth of output was visible at any instant.
The name of the game was to write short programs that would "keep things changing." One technique was to write code that performed some kind of sensible analog simulation--numerically integrating the differential equation of simple harmonic motion, or the like--then throw in a few bizarre twists, such as an exclusive-or where an subtraction would have been appropriate. Another technique was to start with code for a pseudo-random number generator, and tinker with it until it wasn't so random any more.
If you were lucky--certainly in MY case it was always luck--you could get fascinating patterns on the screen. Then you could show it to someone like Bill Gosper who might be able to explain some of the behavior in terms of the number-theoretic characteristics of 2^18 - 1.
The classic PDP-1 display hack was "munching squares."
The code for it was something like this:
foo, lat /load the 18-bit AC from the Test Word
add v /add the contents of memory location v to the AC
dac v /deposit the contents of the AC into v
rcl 9s /Rotate the combined AC-IO 9 bits to the left
xor v /exclusive-or the contents of v into the AC
dpy-i 300 /plot point at x = high ten bits of AC, y = high ten bits of IO
I have tried to reproduce this calculation accurately at the bit level, including the use of ones'-complement addition and "minus-zero gronking" (if a minus-zero results after an addition,it is replaced with plus-zero).
I said that the instruction used was "dpy" (pronounced "dippy"), but it was commoner to use "dpy-i 300."The dpy mnemonic included a 50 microsecond delay to allow the beam to settle, or something. If you knew that the loop was long enough to allow beam settling, you could eliminate the delay by subtracting the "i" bit, speeding up the loop. An intensity argument allowed setting the intensity to different levels, 300 being the highest available.
One problem with "dpy-i 300" was that if, by any chance, your algorithm hit a singularity in which it produced the same point over and over, the beam would be stationary, and a stationary point plotted with dpy-i 300 created a serious risk of creating a phosphor burn.
The use of point-plotting displays with long-persistence phosphors lent itself to a form of recreational programming that has no real equivalent in a world of raster displays. Perhaps the nearest thing I have seen to it recently is the creative experimentation with Mandelbrot sets in the nineties.
Indeed, it seems to me in retrospect that some of these display hacks would now be described as "chaotic" (in the sense of chaos theory).