Replying to myself here - I decided to just actually go read wikipedia about this. Here's the answer:

<quote>

By default, when a processor is executing an instruction, its LED is on. In a SIMD program, the goal is to have as many processors as possible working the program at the same time – indicated by having all LEDs being steady on. Those unfamiliar with the use of the LEDs wanted to see the LEDs blink – or even spell out messages to visitors. The result is that finished programs often have superfluous operations to blink the LEDs.

</quote>

Depended on what was running.

As a developer you had explicit access to them, so you could use them for debugging. A lot of times, they were just running an RNG to look cool though.

Blinkenlights

There is no documentation of what the LEDs were _actually_ doing. There are descriptions, like 'Random and Pleasing is an LFSR', but no actual information that maps to actual pixel coordinates spaced in time. Nearly zero code.

I'm saying this because I need this information, and the fastest way to get information is to state that it's impossible or doesn't exist.

Worked on the CM-1 and CM2. I felt they were awful buggy. At one point they asked if they could use my code to run as a diagnostic, it would break the log() function on occasion.

The Cray fluorinert fountains were way cooler :)