24 May
2016
24 May
'16
9:23 a.m.
On Tue, May 24, 2016 at 8:38 AM, Swift Griggs <swiftgriggs at 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