Anybody have a partial list of places that still have PDP-10 systems
in place? I'd really like to actually SEE a PDP-10 in person some
time... are there any in the San Francisco area still?
Thanks

John

John wrote:

There aren't any running PDP-10 systems in the SF area that are on
public display, and it's not clear that there are any running ones in
the area at all, other than a few XKL boxes that might get fired up
on rare occasions.

If you just want to see a non-running hunk of iron, there are several,
including a KL10 CPU from Tymnet in "Visible Storage" at the Computer
History Museum in Mountain View.

Didn't I see one or two at the Computer History Museum in Mountain View?
Non-operational, of course, and without peripherals.

gmt@cs.arizona.edu (Gregg Townsend) writes:

The closest they have to a complete CPU is a KL10 from a 1090 from
MCI Tymnet. They don't have the memory or peripherals. The machine
originally used an Ampex semiconductor memory box and a System Concepts
SA10 channel (bus/tag) interface. Joe Smith could probably give more
details of that machine if anyone wanted to know.

None of the museum's other PDP-10 CPUs are anywhere close to complete [*].
They only have the console bay of a KA10, and the front end processor
(PDP-11/40) bay of a 2060 (KL10). I suspect that in the mid-1980s,
before the collection moved to the west coast, it was not considered
worthwhile to save an entire PDP-10 CPU, as they certainly could have
done so had they so desired.

Eric

[*] They do have an XKL machine that is apparently complete and working,
but I'd call that a PDP-10 clone rather than a PDP-10. No disrespect
intended to the fine folks at XKL, but part of my personal definition of
a PDP-whatever computer is that it was made by DEC.

Eric Smith brouhaha.com> writes:

So the Harris and Intersil chips used by DEC in late hardware do not qualify as
PDP-8's?

MAXC, the Foonly systems, the Systems Concepts systems, and the XKL Toad-1 are
all PDP-10's. It's an instruction set architecture, not a manufacturer.

I wrote:

Rich Alderson wrote:

They do when they're part of a PDP-8 made by DEC, of which there were none.
The VT78 and DECmate were not marketed as PDP-8 systems.

Other than that, they're almost but not completely PDP-8 compatible.

I disagree. DEC defined a PDP-10 as a piece of hardware that a customer
purchased from them, and wouldn't have taken kindly to anyone else selling
a computer as a "PDP-10". As far as I can recall, none of the clone makers
claimed that their machines actually were PDP-10s, but merely that they were
compatible.

Eric Smith wrote:
(snip)

Unlike IBM, which tried to make the S/360 and S/370 architecture
as similar as possible across the line it seems to me that the different
PDP-10 models were significantly different. Between the KA-10, KI-10
and KL-10 there were many differences. If I remember it right,
even at the user level, the KA-10 used a different format for
double precision floating point. For S/360, IBM designed the extended
precision (quad precision) floating point format to be relatively
easy to emulate in software such that the same format could be used
on all models.

Were there clones that would directly run systems designed for
the KA-10, KI-10, or KL-10, without modification?

-- glen

glen herrmannsfeldt ugcs.caltech.edu> writes:

KA-10 floating point was available on the KL-10 processor; I don't have a KI-10
processor manual to verify whether it was available there.

glen herrmannsfeldt wrote:

Rich Alderson wrote:

I think Glen is referring to the DFN, UFA, FADL, FSBL, FMPL, and FDVL
instructions. Those existed on the KA10 and KI10, but were not present
on the KS10 and usually not on the KL10 because the limited microcode
storage was better used for other purposes.

These are doucmented in the DECsystem-10 DECSYSTEM-20 Processor Reference
Manual, Fifth Edition (AA-H391A-TK) with June 1982 update (AA-H391A-T1)
on pages 2-28.6 through 2-32. Presumably they were covered in all earlier
editions of the Processor Reference Manual, but I haven't checked.

On Mon, 3 Mar 2008, Eric Smith posted:

However, the TOPS-20 monitor implemented these as MUUOs. The same with
the G-float instructions that didn't get into the microcode. However,
G-float was KL-only. Consequently even an XKL or KLH10 based system
implements them (actually, AFAICT KLH10 systems implement them in
microcode).

Very few KL or KS systems that did not properly execute a DFN, UFA, FxxL
instruction. Perhaps the ITS systems did not, but I doubt that given how
very much KA-biased ITS was.