I’ve mentioned this before, but I was at Argonne National Lab doing a software demo and got the cheap tour (the expensive one was reserved for those supplying money, not those seeking to extract money). I saw their Connection Machine. The person doing the tour mentioned that they had some hacks for the blinkenlights, including Pong, Life and an application to scroll text across the face.
Well, the thread got a bit hijacked, so be patient until all the comics and idiots go away.
I’ll start by explaining a machine type I know quite well, the venerable IBM/360 series. These had a very large front panel covered with either bulbs or little slits behind which were bulbs. The bulbs or slits were labeled. Some had individual labels, while others were labeled in groups. The front panel also had dials and buttons.
The lights showed the state of the machine. They showed the current state of each register (the 360, not a stack machine had I think 16), the state of various I/O channels, and so forth. By turning dials and flipping switches you could get a bank of lights to show you the contents of a memory address.
Why? The answer is that the 360 and its OS (OS/360, natch) were very crude. Sometimes your program would die and take down the OS with it. If that happened, you had no other way of seeing what was happening in the computer except to look at those lights. There were no small bits of OS that could display a blue screen of death (and no screen, either), not even a sound generator that could send out a series of beeps to tell you that your BIOS was screwed. All you had were those lights, if you knew how to read them.
Of course, the lights were really only useful to the .01% of the programmers who could do something useful with them. I never could; I never bothered to learn.
By the time IBM released the System/370 series in the early 1980s, the lights had been replaced with a CRT and some semi-permanent OS software for diagnosing problems.
Now, what good did the blinking lights do? None, except that if they were blinking, then the values they represented were constantly changing. This implied that things were changing in the hardware, and thus that a program was running in there. If the blinking stopped, then the values were not changing, and the program (and OS) had stopped.
If you knew your computer really well, you might eventually learn that a certain pattern indicated a loop somewhere, but AFAIK the lights were not specifically programmed to show errors, only to reflect the values inside.
In summary, the patterns meant nothing. If they were blinking, then usually everything was OK. If they were stopped, then the computer had crashed. If there were no lights at all, you had lost power.
Oh, I forgot to mention that sometimes they looked like they were stopped, but were actually blinking the same tight pattern so fast that you couldn’t tell. This was usually the sign of a bad problem in the OS.
OK, so why do the lights on a computer on TV or in the movies always blink rapidly, and speed up just before Kirk causes the machine to blow up with some trick of logic? I think it’s partially that some writer or director once saw a computer with blinking lights, and concluded that all computers have to have blinking lights. The lights are more interesting to look at than a flat slab of metal, and usually pretty cheap to make. I do notice that in the old Star Trek the computer had a voice, and Spock’s readouts were only visible to him. Was this predicting the future, or just saving money by not having to set up lots of blinking lights? Of course, they couldn’t have used CRT screens, which really weren’t available for computer use back then.
PS - Somebody mentioned War Games. I kinda liked that movie, except for the WOPR, which to me looked like an old IBM 401 Accounting Machine or an old-style card deck duplicator. Funny that they built this incredibly detailed set that duplicated the inside of Cheyenne mountain, then put a piece of 1950s junk in the middle of it, complete with blinking lights that (since they had no labels on them) could not have served any purpose at all!:smack:
Thanks 633squadron. From that answer, I understand a bit more. Did the people who constructed these types of computers and light displays know going in how the light displays were going to convey information? Or was it “put the lights on and see what happens?” For example, you said there was a pattern where they looked like they were stopped, but they were blinking really fast and that meant something was wrong in the OS. Had they accounted for that, or was it something you learned by dealing with the lights? I guess it was probably something like “Lets stick these lights on so we can get some basic information about what it’s doing. Oh, it looks like it stopped, better figure out what that means.” Is that basically correct?
Thanks.
Well, kinda. There were multiple OSes developed by IBM and others for that hardware (the /360 series, including the /370 and later variants), all released at different times and used by different people. Off the top of my head, I can name MVS, DOS/360, VM/CMS (including the earlier version of VM called CP), and MUSIC/SP.
This is verging on being wrong, but only due to very early uses of CRTs as RAM (Williams tubes), which I mentioned above: The Manchester Small-Scale Experimental Machine used CRTs as both RAM and as part of its front panel in the late 1940s.
Not really. 
See, the whole Cheyenne Mountain shebang was classified back then. They couldn’t get access to it in order to construct an accurate set. What they did construct was a lot cooler, anyway:
I knew there was something retro about the “Guess the number” game I wrote on the PLC 5 using nothing but switches and the I/O card lights (class was slow). The real point, though, is that programmable logic controls still have lots of blinking lights. While not critical to daily operations, they can be critical for troubleshooting. And a PLC is really just a simple computer.
The lights were usually there to convey specific information. A lot of times this was useful only for troubleshooting hardware problems, but sometimes the lights ended up being used in ways that weren’t predicted.
For example, one really old disk system used to display the sector number being accessed on a row of LEDs. This is useful when troubleshooting a hardware error in the disk drive (we take for granted how reliable computers are now - they used to break down a lot back in the old days, and computer techs actually debugged boards and replaced components that failed). When everything is working correctly, though, all you would see is a bunch of flashing LEDs that were changing too fast to really be of much use to anyone.
My former boss was working on one such system. He was mostly on babysitting detail. He was waiting for the customer to report a problem with the project, and then he would go off and fix whatever they found, then the customer would go off and do more testing. While he was basically sitting there with nothing to do, he watched the pattern flashing on the LEDs and something about the pattern didn’t seem quite right. So he started digging through the code, and sure enough, he found a bug that the customer hadn’t even noticed yet.
So the guy who put the blinkenlights on there intended them for hardware diagnostics and maybe software driver development, and they ended up being used to find a software bug, which was never part of their intended use.
Here’s a video of a PDP-8 being booted. Compare this to a modern PC which automatically seeks out disks and boots itself. The operator is basically entering a “program” into the machine that tells it to boot and executing that program.
http://www.pdp8online.com/pdp8i/videos.shtml
This page describes basically what he’s doing:
http://www.retrotechnology.com/pdp11/pdp8i_boot.html
The various lights are showing current address and data values and the machine state.
Someone post a link to the marble adding machine in youtube. The state of each bit is represented by the rocker being to one side or the other which you can see but in an electronic machine the light tells you the state of that bit which you cannot see by plain sight.
Not part of the computer, but even today there are monitor panels used as test equipment for embedded software. Since there are some critical interrupts that affect the processing, those interrupts are shown on the monitor panel (and they have pin-outs so they can be used as a trigger on a logic analyzer, an oscilloscope or spectrum analyzer). These are mounted as just a long string of LEDs and probe sockets.
Additionally, there are memory displays – much of the memory is defined in the heap (this is a legacy system long overdue for a redesign, but it’s still in use and new functions are still being added) So a variable’s address will be constant (until the next rebuild). The monitor panel has probes tied to memory controller, and when it sees an address that you’ve keyed in, it latches the next thing going out on the bus, and you can see whether a variable has been read, written to or either. These are also displayed (segmented integer LEDs to display hex as well as binary LEDs), and have pin-outs as well.
Same thing for the instruction counter – in this system, the software is executed out of EEPROM, and you can probe the instruction pointer to see when an address is executed, and that’s yet another useful signal to use as a trigger in a logic analyzer.
So, in 2009, there are engineers who stare at lights, sometimes desperately hoping to see one of them blink or not blink, as a clue that the software is behaving predictably.
Needless to say, some people can make the lights do whimsical things, but we’ve never had a light defined and installed just to have a light that can blink.
These days when you have desktop computers with megabytes of internal memory it’s hard to remember how limited internal memory could be. Several posters have mentioned registers, and these registers were basically all the internal memory that a computer had, when internal memory was very expensive. So you might have a dozen or so registers, and each register might be 8 or so bits – i.e., the total internal memory on the machine might have been about 100 bits, and the status of each bit was shown on one of those blinking lights. One or special registers might have held the current instruction being executed by the machine, and the rest might have held data, usually in integer or floating-point format. So if the program had stopped running, you could read what the last instruction was (in machine format – no sissy Cobol or Fortran here!), and what data was in the other registers, in binary notation.
If you ever want to really have fun and mess with someone, I have a surplus submarine sperry univac 1616/snap II computer hanging out in the barn free to a good geek practical joker home … we got it to play a practical joke on someone but didnt manage to get around to doing it. =) Just come and get it =)
To expand on Derleth’s post – it wasn’t about accuracy…
Many early games for the IBM PC were written, somewhat foolishly, with the apparent expectation that the CPU speed was going to be a fixed constant forever and ever, kind of like pi. (That speed being about 4.77 MHz.) These games did not try to pace themselves against the passage of real time. They simply ran “as fast as possible”, and the authors would fine-tune the programs (with delay loops if needed, and perhaps by counting instruction cycles) until the pacing seemed about right. Later however, when faster CPUs came out, games written with this approach ran too fast to be playable.
So the Turbo button was there to throttle the CPU back down to 4.77 MHz – except that as noted above, it worked in reverse, with “Turbo mode on” meaning normal speed – the fast speed you paid your hard-earned money for – and “off” meaning the old compatible speed.
Had the CPU operated differently under different speeds, especially with numerical bugs at the faster speed, like you mention, I can assure you there would have been riots at computer retail stores – and I might not have survived to be here with you people today. There was certainly plenty of anger with the Intel FDIV bug, when that happened. PCs of that era, say the mid to late 80s, were often bought by businessmen who wanted their Lotus 1-2-3 spreadsheets to run fast, and without calculation errors.
The connection machines came in two forms - the CM-2 and CM-5. They are totally different machines. The CM-2 is the stack of eight cubes with lights on the front and back, and the CM-5 is the huge tall box, or boxes in a zig-zag with a vertical strip of LEDs on the front.
In the CM-2 the LEDs are part of the matrix cards - which are th cards that carry the actual CPUs and memory. There are 32 LEDs per card, and from memory the LEDS indicated activity on the communication network (a 10D torus.) The CM-2 lights did generally have some correlation to the program’s execution. The CM-2 was a SIMD machines, and the entire machine ran a single program at once. In a darkened room, a fully populated CM-2 running was an utterly awesome sight.
The CM-5 LED panels were self contained units that could run standalone. There was a multi-position switch that set a range of patterns - a couple of “look nice” patterns, and it also had positions where the pattern would freeze, for the explicit purpose of staying still for a long exposure photograph. There was one switch position where the LED panels would listen to the node cards that contained the processing nodes. The node cards also carried LED on two edges. The cabinet had a translucent side which the LEDs shone though. There were 8 LEDs per node, and the individual LEDs had a definite meaning - such as network activity. But they were controlled by software in the nodes, not directly connected to the hardware. These LEDs were also repeated via a connection cable to the front panel. You needed at least 128 nodes in a cabinet before the LED panel looked any good. So smaller configurations tended to leave the system set to “nice random pattern”.
The LEDS were a little bit useful as a diagnotic. If the scheduler crashed the LEDs would all turn to a chaser patern. Sometimes running machine diagnotics would result in a crashed node and a stuck LED corresponding to the fault. I could also often tell whose job was running by the charateristic patterns. But let’s face it. They were very expenive ornamentation. A fully populated cabinet held 256 nodes. However the designer of the cabinent decided that the LED panel was too long, so they cut off the bottom of the lowest LED pannel, and you couldn’t actually see the LEDs for the last 48 nodes. Which rather underlines the actual utility.
The claim to fame for he CM-5 is that it was the blinking lights in Jurassic Park. Four cabinets. However they were not set up correctly. They were side by side, not in the correct zig-zag configuration needed to connect them into a single machine.
When Thinking Machines fell on hard times they marketed a cluster in a box. Little more than a stack of Sparc stations on a high speed switch in a cabinet, with TMC’s data-parallel compilers. One of the engineers decided that they really needed a nice LED panel. So he went to Radio Shack and bought one of the big LED programmable display signs. This particular model allowed you to program custom characters. So he programmed in a set of random bit patterns, and then had the display scroll, blink, and generally twinkle with these charaters. It had no connection to the rest of the machine at all. It was all a bit sad really.
On the PDP-11, the front panel had lights that represented the individual bits in the command being executed. You could single step the PDP-11 through a program, and even flip the rocker switches on the front to set particular bits. In fact, that’s how you’d program and even boot up the sucker.
The lights were labeled with digits, and the lights were also grouped into groups of three. Most of the original blinking lights were showing the status of a bit in memory. If the machine crashed, there was usually a single step switch that would take you to the next address in memory. Write down the light sequence, and you’d get a data dump which might help you understand why your program crashed.
I suspect that’s the origin of the lights: Before the days of CRTs and when computers had no real operating system, but simply ran one program at a time or ran what was called a “control program”, the lights were the only real way to communicate with your computer.
In a computer lab, each device had its own set of status lights, so you saw them all around you, and I’m sure that’s where programs like Star Trek picked up the idea. Heck if a PDP-11 had 24 lights on the front panel, computers of the future must have millions! When people got the impression that powerful futuristic computers had blinkenlights, a few companies figured that would make their computers look more futuristic.
By the way, I am typing this on my MacBook which has on steady light on the front panel that tells me when I have the computer on when the lid is closed. And, I am pretty sure this MacBook is way more powerful than any of the pictures of the various computers people posted in this thread that were covered with little red LEDs. Obviously, with a good graphical display that can give you very detailed information, there is no really good reason to have blinking lights any more.
I’m a technical writer and I recently finished a manual where I had to explain troubleshooting using PLC lights. The engineers wanted to have a small LCD installed to display error codes but the customer said it was not required and that the technicians would just use the lights.
I subsequently met one of the end users and he was not happy.
Which brings us to this scene (at 1:40)
That is a common idea, but people don’t realise how astounding those beasts were. It is hard to directly compare - some things have changed much faster than others.
The usual picture of a CM-2 that people reference has the data vault sitting behind it. The large curved black thing that looks like a bar. It held 144 8 inch SCSI disk drives, to a grand total of 9 GB. It was one of the first commercially available RAID arrays. The CM-2 held up to 64k single bit processors and ran at a stately 8 MHz. It had one gigabyte of memory. But in 1988 it was pretty slick.
The CM-5s could get a lot larger. The usual pic of a CM-5 is of a 512 node machine. That held 16GB of memory, had 2048 64 bit vector processors and ran at 32 MHz. Part of the magic was that the vector units were directly connected to memory. There were no caches. So there was never an issue of the cost of cache misses. If you had a well behaved code you could load up the vector pipelines and get a 64 bit floating point result every clock cycle. And it could sustain that speed. 32 * 2048 is potentially 64 Gigaflops peak. On real codes you could somtimes get half that. The biggest CM-5 commissoned was a 1024 node machine. In principle a 4098 node machine was possible. The CM-5 also had storage in what was called the Scalable Disk Array. Essentially a very large RAID that could be built into the same cabinets and talked dircectly to the communication backplane of the machine. 24 SCSI disks per bay, 8 bays per cabinet. The potential bandwidth talking to mass storage was pretty stunning. These machines were used for data mining. When TMC finally failed the only remnant was the data mining, and Oracle bought it. Sun got most of the rest.
So no, your Mac has a fair way to go to meet a real supercomputer. Then again, the prices of those machines were pretty eye watering. A node card for a CM-5 (which held 4 nodes) cost $40k. I have a box full of them in the garage.
Something else: if your program went into an infinite loop you’d notice the regular pattern of the blinkenlights.
Seeing as how this thread has been revived, I’ll chime in with some info. Not all S/370’s had CRT consoles - some models were available with a printing console based on the Selectric typewriter mechanism, but with a wider carriage and [allegedly] engineered for higher reliability.
Even the systems with CRT consoles standard still had rotary switches and lots of incandescent lamps, and while you could do most of the same tasks with either, they were actually implemented very differently internally. I once had a 3138 (System/370 Model 138) which was having intermittent machine failures, and IBM support was escalated all the way to the top, and IBM wound up shipping the principal architect for the 3138 out to us to fix the problem. He’s twiddling the dials and pressing the “Set Address and Display” button, and one of the less-senior techs has the temerity to mention that this could be done much more easily from the CRT. The architect blasted him with “I never trusted her - she was a commie!” (referring to the person who designed the CRT’s front panel emulation).
Plus, a lot of the hardware in the computer room came from wildly different equipment generations and was cobbled together with what were frequently one-off solutions.
To give you an idea, the 370/138 system I mentioned earlier had some 3-series (370-era) peripherals - some 3422 tape drives, but also some 2422 (360-era) tape drives and a control box to attach the whole mess to the CPU. The 3-series CPU used a 2-series 2821 control unit to talk to a 1-series 1403N1 printer which was originally used on the 1400 computer family. The card reader was a 2501 from a 360, the card punch was a 1442 from a 1401, and disks were 3340-70 Data
Modules which marched to their own kettle of fish and didn’t really claim to interoperate with any of the existing product families. They got an IFA (Integral File Adapter) which wired them directly into the guts of the CPU, bypassing the conventional I/O channels.
To keep all this in some semblance of sanity, 3-digit hex numbers were used to uniquely identify how the devices were routed back to the processor (and hence to the operating system).
Common designations for a system like the one I just described would have the CRT console at 01F (highest priority), card reader at 00C, card punch at 00D, and the printer at 01E. Disks would start at 160 and work their way up, and tapes would start at 280 and go likewise.
All of this led to huge amounts of cabling under the floor - aside from the massive power needed by the CPU cabinet (60 Amp 3-phase to run a motor/generator set), each device had 4 cables around 1.5" in diameter or larger - a pair called Bus & Tag in and another for Bus & Tag out. You’d get all sorts of odd errors if you used 360-style ones on a 370, but you could scavenge the 360 ones and use them for things like connecting slave tape drives to the tape controller.
For extra credit, name the 2 (very different) systems that used these front panel operations to boot:
-
Sense 1 and 4 up, press Clock and Reset simultaneously, then release and press Run
-
100033 Program Load (if you had a top-loader, otherwise usually 100027)
Both of these are from later-generation systems where there was hardware assist for starting the operating system via simple front panel steps. On older hardware you would have to key in a group of instructions by flipping switches in the desired pattern, observing that the same pattern appeared on the lights, and proceed to the next step. If you fumble-fingered some of your input, you could actully cause a physical failure of the computer, for example by exceeding the duty cycle on some circuit drivers you could actually cause chips to fail or wires to melt.
Somewhere around here I have one of the first attempts to engineer around that problem without needing to completely redesign the computer. An extra circuit board was installed in an empty slot and wired up appropriately, and it used permanently-mounted diodes to represent 1’s and 0’s. A board maybe the size of a pie tin could handle all of the tedious steps in the process. However, if the operator noticed that a step had been skipped, the procedure would have to be re-attempted from the start.
As Microprocessor-based systems became available from the major manufacturers (Data General with the MicroNOVA; DEC with products based on the F11, T11, and J11; and so on) there was a lot less of the exposed lights & switches - they were a pain to get into and repair, while the new-style cosoles just needed a telephone cord over to a printer or a CRT and you can manage just about everything from there. Sure, the main system cabinets had a couple ACE locks controlling access to moreimportant functions, but the rest of the cabinet’s external lights were usually limited to “I’m running / I’m not running” and “Power is normal / one or more power problems exist”.
Of course, dinosaurs soldiered on bravely without making any changes until the discovered that the world had passed them by. Two such systems I worked with were a pair of Varian V-76 coupled tightly to a pair of mainframes built by TI out of many, many racks of their TI-990 minicomputers. It was quite a procedure to get a successful coldstart out of that hardware on the first half-dozen or so tries - synchronization issues would uusually force a halt and restart.
Speaking of retro, when I was at the State Fair last month, in the huckster’s pavillion was something I hadn’t seen in decades: One of those handwriting analysis booths with an impressive-looking ‘computer’ in the back that had square yards of blinkenlights on it. Took me back to my youth, it did.
Thanks for making my day! 