28 Feb
2008
28 Feb
'08
1:19 p.m.
Front panels for modern day computers/microprocessors are somewhat
problematic.
The cache(s) maintained internally allow for local instruction execution
without
making references to the external memory buses, and the prefetch
mechanisms internal could
also indicate memory activity even if no instruction or data item were
actually
fetched! Status information is not as directly available, and if it were
it would probably not reflect
status in "real time" that is occurring at the same time of viewing on
the panel.
Nevertheless, memory bus activity could be monitored, and what limited
status information
is available could be produced. The point though is the information
displayed, say on minicomputer panels,
is not readily available now due to higher levels of integration on the
chip itself.
On the note of the CDC 6600 machines, et al., There was a peripheral
processor
which was used to boot the mainframe, and it had many rows of toggle
switches, in groups of 18 or 36
if I remember right, which either contained the boot code or controlled
the boot. The peripheral
processor was a computer in its own right by any standards.
Hope this helps.
--Geoff
Message: 1
Date: Thu, 28 Feb 2008 09:33:28 -0800
From: "John Floren" <slawmaster at gmail.com>
Subject: front panel display for a modern PC
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
I'd really like to have something like one of the old
mainframe/minicomputer control panels for my PC, but I'm just not sure
how to implement it. Anybody here tried something like that? Ideally,
you could power it on, see registers, toggle stuff into memory, have
lights for interrupts, that kind of thing. Yeah, I know, as soon as I
bring up an operating system, the ability to toggle things into memory
would be rather dangerous, but I just can't resist the charm of the
idea :)
So... doable? Impossible? Improbable?
John
28 Feb
28 Feb
1:39 p.m.
On Thu, 28 Feb 2008, Geoffrey Bunza wrote:
On the note of the CDC 6600 machines, et al., There
was a peripheral
processor which was used to boot the mainframe, and it had many rows of
toggle switches, in groups of 18 or 36 if I remember right, which either
contained the boot code or controlled the boot. The peripheral processor
was a computer in its own right by any standards.
Here's a picture of the Dead Start Program panel:
http://sturgeon.css.psu.edu/~mloewen/CDC6600-7.jpg
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
1:53 p.m.
On Thu, Feb 28, 2008 at 10:39 AM, Mike Loewen
<mloewen at cpumagic.scol.pa.us> wrote:
On Thu, 28 Feb 2008, Geoffrey Bunza wrote:
It's... beautiful!
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
On the note of the CDC 6600 machines, et al.,
There was a peripheral
processor which was used to boot the mainframe, and it had many rows of
toggle switches, in groups of 18 or 36 if I remember right, which either
contained the boot code or controlled the boot. The peripheral processor
was a computer in its own right by any standards.
Here's a picture of the Dead Start Program panel:
http://sturgeon.css.psu.edu/~mloewen/CDC6600-7.jpg
3:31 p.m.
John Floren wrote:
On Thu, Feb 28, 2008 at 10:39 AM, Mike Loewen
<mloewen at cpumagic.scol.pa.us> wrote:
You, sir, have a gift for understatement.
Peace... Sridhar
On Thu, 28 Feb 2008, Geoffrey Bunza wrote:
It's... beautiful! On the note of the CDC 6600 machines, et al.,
There was a peripheral
processor which was used to boot the mainframe, and it had many rows of
toggle switches, in groups of 18 or 36 if I remember right, which either
contained the boot code or controlled the boot. The peripheral processor
was a computer in its own right by any standards.
Here's a picture of the Dead Start Program panel:
http://sturgeon.css.psu.edu/~mloewen/CDC6600-7.jpg
4:36 p.m.
John Floren wrote:
Y'know, that reminded me of the toggle switch panel at the end of the Bombe:
http://upload.wikimedia.org/wikipedia/commons/5/5c/Bombe-rebuild.jpg
cheers
Jules
Here's
a picture of the Dead Start Program panel:
http://sturgeon.css.psu.edu/~mloewen/CDC6600-7.jpg
It's... beautiful! 
9:50 p.m.
On Thursday 28 February 2008 13:39, Mike Loewen wrote:
On Thu, 28 Feb 2008, Geoffrey Bunza wrote:
New desktop wallpaper! :-)
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On the note of the CDC 6600 machines, et al.,
There was a peripheral
processor which was used to boot the mainframe, and it had many rows of
toggle switches, in groups of 18 or 36 if I remember right, which either
contained the boot code or controlled the boot. The peripheral processor
was a computer in its own right by any standards.
Here's a picture of the Dead Start Program panel:
http://sturgeon.css.psu.edu/~mloewen/CDC6600-7.jpg 
4:12 p.m.
On 28 Feb 2008 at 10:19, Geoffrey Bunza wrote:
On the note of the CDC 6600 machines, et al., There
was a peripheral
processor which was used to boot the mainframe, and it had many rows of
toggle switches, in groups of 18 or 36 if I remember right, which
either contained the boot code or controlled the boot. The peripheral
processor was a computer in its own right by any standards.
Well, actually a tenth of a computer. The basic cycle time of the
mainframe was 100 nsec. There were 10 PPUs in a standard
configuration, with a cycle time of 1 usec. In other words, each PPU
was little more than 4K of 12 bit core, a P-counter and an 18-bit
accumulator (that's over-simplifying things a bit, but it'll give you
the idea). The "guts" (instruction decode and execution) was time-
sliced around the 10 PPUs. This was sometimes referred to as the
PPU's slot "in the barrel". All I/O channels were accessible from
any PPU and any PPU could access central memory. So, if a driver or
bit of hardware malfunctioned, the PPU might hang, but the system
could keep on running. Similarly, if a PPU was hung on an empty
channel, it was often possible to break it loose from the operator's
console.
The deadstart panel itself was a 12x12 matrix of switches (12 words
of 12 bits). There were some other switches controlling diagnostic
mode, and control of various options (e.g. CEJ/MEJ); many systems had
a key-operated switch which could disable the deadstart panel to keep
rogue programmers from sneaking time on the system. :)
Deadstart was quite simple. Each PPU had its P-counter forced to
0000 and a block input instruction from the channel corresponding to
the position of the PPU in the barrel. (i.e., 0-9). The contents of
the deadstart panel switches were output to channel 0 after an
initial word of zero and the channel disconnected. PPU 0 then began
executing at location 1 and could then proceed to read the remainder
of the OS bootstrap and transmit resident programs to each of the
other PPUs. No blinkenlights and no ROM involved at all--either the
system started or you had blank screens staring back at you. Time to
get out the scope...
10 is a magic number for the 6600. Memory is interleaved 10-way,
there are 10 PPUs, 10 characters per CPU word, 10 functional units...
Later implementations of the architecture dropped the idea of the
barrel and provided a complete processor for each PPU.
Cheers,
Chuck
5993
days inactive
5994
days old
6 comments
7 participants
participants (7)
-
cclist＠sydex.com -
geoffb＠vigilan.com -
jules.richardson99＠gmail.com -
mloewen＠cpumagic.scol.pa.us -
ploopster＠gmail.com -
rtellason＠verizon.net -
slawmaster＠gmail.com