Front panel switches - what did they do?

Paul Anderson useddec at gmail.com
Tue May 24 14:06:29 CDT 2016


I used to have a notebook of toggle in programs for the PDP8s and PDP11s,
but it seems to be lost forever.

Not being a software person it takes me hours to write and debug the
simplest routines. Is there a site with a list of toggle in maintenance
programs?

On Tue, May 24, 2016 at 11:23 AM, Charles Anthony <
charles.unix.pro at gmail.com> wrote:

> 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
>


More information about the cctech mailing list