So, I looked at the early editions of the "pdp11 peripherals hanbook", which
have good, detailed discussions of UNIBUS operations (at the back; chapter 5,
"UNIBUS Theory and Operation", in the 1976 edition), but in contrast to the
level of detail given for master/slave operations, and bus requests and
interrupts, the level of detail on power up/down is very low, especially
compared to that in the later "pdp11 bus hanbook" (which, as mentioned, does
not seem to be online yet, alas). So, I have transcribed that section, and
posted it:
https://gunkies.org/wiki/UNIBUS_Initialization
I have yet to scan and post the associated timing diagrams (which are useful,
but not critical); the desktop that runs my scanner is down at the moment,
alas. (If anyone who has a copy would like to volunteer to scan them, that
would be great.)
Noel
>From here:
https://setiathome.berkeley.edu/forum_thread.php?id=85870&postid=2096776#20…
They are bog standard Sun Enterprise systems, drive removed and destroyed
for privacy reason. They are only interesting for what they've done. By
university rules, our group can essentially "permanent loan" them to a
non-profit, but any sale or transfer of ownership is up to
University Excess and Salvage.
A bit of history disappearing, which is nothing new in this group.
On Fri, Apr 1, 2022 at 10:26 PM Marc Howard via cctech <
cctech at classiccmp.org> wrote:
> We need to onshore Nixie production now! ;-)
>
Gentle plug for https://www.daliborfarny.com/.
I have three AlphaServer 2100 systems in storage in the UK
(Oxfordshire). The storage, however, is due to be demolished (soon, but
no fixed date).
I won't have room to store these three systems, so if anyone would be
interested in offering them a home, then please get in touch!
I can probably get some pictures in the next day or two.
These systems were SMP Alphas and could sport as many as 4 CPUs. I'm not
sure of the configuration of these systems but I can probably find that
out soon.
They have not been run since ~2003 so they may be in need of some TLC.
OTOH they are not rusted to death so you have a chance of getting them
back to life.
Just so you know what you might be dealing with these systems are about:
700mm H x 430mm W x 810mm L.
I can't find the weight in any of my references right now but they are
very heavy. Three people can move them up a slight slope with some
effort but you would not successfully lift it into a car (assuming that
it would fit). I'm planning to dismantle them to move them (i.e. remove
PSU/PSUs etc. until they are light enough to move). A tail-lift would
probably be the sane way to go (and is, indeed, how they got to their
current location.
I'm hoping that someone can step forward and offer one or more of these
machines a new home. Please contact me off-list (once you're sure you
understand what you are getting into :-)).
Antonio
--
Antonio Carlini
antonio at acarlini.com
This may be of interest to some list members, particularly those who have an
interest in the BBC computer or just like Twilight Zone type stories.
Apart from being extremely interested in classic computers I also like the
old stories that surround these old machines. A while ago I stumbled across
a story about a BBC computer (this is the short version) that had been lent
out from a school l think (as they did in those days due to the cost of
machines back then) and this BBC, despite apparently not being connected to
anything, started displaying messages from the past (a previous land owner)
and someone in the future. As I said this is the short version of the story
- it's also referred to as the Dodleston Messages or even the Dodleston
Files if anyone wants to Google it. One of the claims was that this BBC
proved the existence of time travel - WOW, a big claim.
So the story eventually found its way into a book, The Vertical Plane by Ken
Webster (1989). I believe the book gets its title from the way scientists
describe time.
So being interested in the stories I started my world-wide hunt for a copy.
That was tough. A new copy unobtainable, an electronic copy not to my liking
- I like the real thing, used copies were monumentally expensive (apparently
the first edition was highly collectable). So I resigned myself to maybe one
day I would stumble across a copy in a used book shop or an Op Shop (aka
Thrift Shop) or a second hand shop. I visit these regularly because its
amazing what pops up in them.
Much to my surprise in February this year a Second Edition of The Vertical
Plane was published and of course obtained for me by my local bookshop.
My take - a good yarn - yes, do I believe the story - no.
Please note, I have no connection with the editor or the publisher.
Kevin Parker
Hello.
I have an HP 9000/217 (9817) machine that I'd like to install HP-UX 5.1 onto. In order to do this, I need to find the boot disk containing the correct kernel, which has the part number "A98680B", and is described as "Multi-user kernel for S200". Alternatively, I could run just the single-user version of HP-UX 5.1, which has the part number of "A98670B". The disk images for HP-UX 5.1 on bitsavers.org and hpmuseum.net do not have this disk.
I found these numbers in the HP-UX administrator manual. Page 370 lists the kernel disks and their contents.
http://bitsavers.org/pdf/hp/9000_hpux/1985/97033-90049_HP-UX_System_Adminis…
If anyone can point me in the right direction, it'd be greatly appreciated!
Thanks.
> From: "Rob Jarratt"
> I did plug the connector back in, so that DCLO and
> LTC are connected, I just removed the ACLO pin.
Ah, OK, good. Pulling the pins from those Mate-n-Loc shells without the right
tool is tricky; glad you did it, because as Brent Hilpert pointed out, having
a working DCLO is important, to reset everything to a known state on power-on.
> I didn't look for replacements last night. Is there a modern
> equivalent?
Not that I know of. Even if you found something with the same pin-out,
supposedly DEC selected ones that were 'good enough'. I've never had an issue
with NOS ones that I bought from vendors, though.
> I may have found a source of NOS.
Great; get several, they're a useful chip to have around; the QBUS uses them,
as well as the UNIBUS.
If the same place has DS8640's (the receiver), save on shipping (and ordering
delays) and get a couple of those too. I say that because depending on what
else you had plugged into the UNIBUS post ACLO failure, the -15V may have
damaged them too.
The M9312 (not sure if you had one of those, but the -11/24 manual says it's
common in them) uses ACLO (via a DS8640). The KY24 seems not to (as far as I
can tell from a quick look - negative results from a quick print scan aren't
100.00% reliable, whereas positive ones are), oddly enough. In EUB memory
(not sure which you have), the MS11-L and MS11M MS11-P don't seem to, whereas
the MS11-P _drives_ ACLO (through an 8881) - probably to prevent CPU startup
until the ECC is cleared). Etc, etc.
> I always marvel at how neatly those wires are done, I wish I knew how
> to do such a neat job.
The same way the old joke says one gets to Carnegie Hall, I expect! :-)
(I wonder what the UK equivalent of the Carnegie is - the Royal Albert,
probably?)
Noel
> The 'unused' gate in E52 is the one that the added wires from the ACLO
> ECO went to; I wonder if it was damaged by the -15V, somehow?
So, I checked, and the wire that goes from the plated-through hole next to the
etch cut on E70p1 winds up at E52p4 (the bus line on that transceiver),
thereby connecting the latter directly to UNIBUS ACLO (on pin BF1). So that's
almost certainly what caused other gate(s) in E52 to fail.
I think I have managed to trace where all the other two wires to that 'new'
gate in E52 went to/from, to see exactly what the ECO is. Given that E52 is a
transceiver, it was likely substituted for E70 so that the KDF11-U could also
_drive_ BUS ACLO.
I discovered that E52p5 (the new transceiver's input) is connected to E73p13
(an DS8640 quad NOR used as a bus reciver); that's in the upper left corner of
K2. It's BUS PB L NOR BUS PA H - i.e. a parity error has been detected in
memory - so it apparently then power-fails the system!
The incoming BUF ACLO (E52p6) goes to a PTH next to E70p8. On the bottom,
there's a trace from that PTH that goes to E66p13 - which is the inverter
shown on K2 which converts BUF ACLO H to POWER OK H. So that probably the
answer to my plaint about E70p1 being left floating: perhaps theres an etch
cut somewhere that disconnected E66p13 from E70p2, so the former can now be
driven by E52p6. I can't see one, but there's a trace from that latter PTH
that dives under E70, and I can't see it well, but it looks like it goes to
E70p2. It would be interesting to know what they did about the E70p2 -> E66p13
connection.
Noel
> does [disabling the MCLK counter via DCLO, asserted by the two
> E126 monostable chain from ACLO] happen just on power-down, or on
> power-up too? I'd need to understand how that two monostable chain
> works in both cases, which I currently don't. (I only understand
> monostables when pulses trigger them, not edges, which is a big part of
> why I don't completely understand it.)
So this was bugging me, so I hauled out my TI TTL databook and looked up the
LS123.
According to that, the 123 is triggered by the rising edge on the B
(non-inverted) input, when the A (inverted) input is low (which it will be
here; it's tied to ground). (Also by the falling edge on A when B is high,
which we can ignore.)
So I think that chain is probably triggered only on power-down, which will
produce a rising edge on P FAIL. (Power-up will produce only a falling edge
on P FAIL, once power is up and good.)
(Note that the second monostable is triggered, also on B, by the -Q output of
the first; i.e. by the 'falling' edge of the first's pulse. But see also at
the bottom, below.)
So that should happen (if I have correctly understood this, which is not
certain, I'm just a software person :-) is that some time after P FAIL goes
high - a delay set by the first 123 - the second 123 produces a pulse (of a
width set by its RC pair) - which via E52 produces an assertion pulse on DCLO.
WTF? (Not that we care in this machine's case, since i) it only happens on
power-down, and ii) it's just a pulse, so it's affect on MCLK will be very
transient; it can't cause it to stay off. My curiousity has been piqued, is
all. :-) The TM does not, after a _thorough_ search (although there are a few
mentions of power u/down, but not this), explin why, alas. (The TM for some
_other_ -11 CPU, one which contains a similar circuit might, but I'm not
_that_ curious! :-)
My _guess_ is that the intent is to reset all devices to a good idle state,
_before_ power actually goes out. (Don't ask me why it just doesn't use
INIT, though!)
The potential fly in the ointment of complete understanding is that a 123 can
_also_ produce a pulse on a rising edge at the clear input - and there is
some circuitry driving the clear input on the second 123. (The clear input on
the _first_ 123 seems to be left hanging in space - odd!) It seems to be set
off by the mysterious DGP03 signal, generated by the microcode - but the GP
table on pg. 4-21 of the TM doesn't contain an entry for '3'? Unless it has a
typo - there are two '5' entries. In which case it could be 'Toggle the HALT
flip-flop (K6)' (which I don't see on K6, unless it's E78) but yah, pulsing
DCLO will probably clear it, wherever it is!
This machine is making my head hurt.
Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if not,
then we'll have to work out why not.
Noel