On Tue, May 24, 2016 at 8:38 AM, Swift Griggs <swiftgri...@gmail.com> wrote:
> > Since I'm an igmo about most machines before the mid-eighties (and still > fuzzy even on most of those), I'm curious about all these older machines > with front panel buttons and switches. What all did they do? You could > actually program them using the front panel right? Some of them > bootstrapped this way, too? What kind of "language" was used for that > (ie.. what were the basic mechanics)? Did the buttons ever change color? > Were you considered a badass if you had switch flipping all memorized down > to an art? Were they mainly multi-position toggle switches or on/off > buttons? > > They just seem to be a lot more important on older mainframes and minis. > Also, what was the main reason for the blinkenlights? Was it to show > system load or specific system states? > > Just curious. I'm learning a ton from reading these threads on older > machines, but there is so much I don't know. > > "Older machines" covers a lot of ground..... In my experience (PDP-11, PDP-8 PDP-15, Nova, IBM 709, DPS8 and others), the panel switches and lights were for primarily for bootstrapping and debugging. Typically, there was a set of data switches (0/1 toggles) that could be set to an address or data value, and a set of command switches (momentary contact) that copied the data switches to some data register or memory. For the earlier or cheaper systems, there was no 'bootstrap ROM'; so a small program that was capable of reading the first record of a paper or magnetic tape into memory and running it was needed. This program was documented in ''machine language' -- a list of binary values that needed to be placed in specific memory locations. Hypothetical example (in octal): Starting at location 0: 1456 3342 3300 3040 0070 (expressed in octal). To bootstrap the machine, you loaded a paper tape containing the program you wanted to run in the reader. Next, you hit the 'RESET' on the console; among other things, that would set the console 'next address' register and the instruction counter to 0. You then set the data switches to 001100101110 (1456 in binary), and press 'DEPOSIT'. Thus would copy the data switches to memory at the location in the 'next address' register and increment the register. You then repeated this for each data value -- toggle in the value, press deposit. When done, you pressed 'START'. The RESET had set the instruction counter to 0, so the CPU would start executing code at location 0, which contains the 1456 instruction, and your bootstrap is off and running. It reads some number of characters from the paper tape into memory, and then starts executing them. Those characters will be a more complex boot strap loader that will read them rest of the tape into memory and run it. Later or more expensive options of these machines would have a bootstrap loader in ROM. Typically, you would toggle in the the address of the ROM into the instruction counter and then boot device ID into the data toggles and then start the CPU. For the DPS8 there was a bootstrap ROM, a set of switches specifying card reader or tape boot, the device ID and a 'BOOT' button. The data switches would be examined by the operating system during boot to enable debugging (pause at certain points during boot, eg). The 709 had these massively over-engineered rocker switches, reminiscent of circuit breakers, and a reset switch which activated a electric motor in the console which physically set the switches back to 0. The PDP-15 had a 'CPU speed' knob. turning it would continuously vary the CPU clock from 1Hz to full speed. The blinking lights typically would have at least the instruction counter and the accumulator. Other registers might be displayed, as well as the instruction being executed, operand address and value, condition code bits, IO activity, interrupt status, and much more. Watching the instruction counter could reveal the CPU to stuck in a short loop; or, if halted, what instruction it was at when it halted. The console switches and lights could be used to examine memory locations as part of debugging. If the program was stuck in a loop, the console switches could be used to halt the CPU and examine where in the program it was looping and the values of the variables that controlled the loop. Some of the mainframes had hundreds and hundreds of lights, detailing the internal state of the machine; mostly of interest to field engineers. -- Charles