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
The recent discussion on BSC protocol prompted me to dig out my Microvax 3100
with DSH32 synchronous serial interface. It had been idle in storage for
several years and it wouldn't power up, only giving a brief flash on the
diagnostic LEDs and a quick twitch of the fans. There was a slight smell, like
the stale air that comes out of a deflating tyre.
I took out the H7821 power supply and found that five identical brown 1800uF 25V
electrolytic capacitors on the output side had leaked.
The SCSI disk enclosure where the machine's system disk lives required several
power cycles to get it to run at all and it died as soon as the disk tried to
spin up. It turned out to also contain a H7821 power supply which had a
similar issue with the same five brown capacitors, although not as extensive
as in the main unit.
I found a second disk enclosure which had seen little use and grabbed the power
supply out of that to put in the MicroVAX. It worked well enough to test with
but there was a ring of goo around the bottom of one of the brown capacitors
which was worst affected in the other units. Time to order a batch of
replacement capacitors and figure out what else has been damaged. While it is
not the worst I have seen, access to these power supplies for repairs is quite
difficult and it is really difficult to debug them safely while they are
running with the cover off :-(
If anyone has anything with H7821 power supplies in them, I suggest checking
on these capacitors. If anything with these power supplies is in storage, I
suggest ensuring it is stored the normal way up as this should limit the
ability of the goo to escape and spread around the power supply.
And there I was thought I was being safe enough by removing the nicad battery
packs some years ago...
Regards,
Peter Coghlan.
I'm running Linux Mint (an ubuntu derivative) and I want to mount ULTRIX
CDROM discs to see what I can see.
(I'm eventually going to image these, but I presume that will "just
work" with dd or ddrescue).
They are supposed to be UFS format (according to the net) and that
usually means you have to tell mount exactly which option to use (as not
all UFS implementations are compatible).
I've tried (all the options I can find) and failed:
$ sudo mount -t ufs? -o ufstype=44bsd /dev/sr1 /tmp/mount
mount: /tmp/mount: wrong fs type, bad option, bad superblock on
/dev/sr1, missing codepage or helper program, or other error.
The CDROM would appear to be readable 9and I've tried a few anyway):
$ sudo file -s /dev/sr1
/dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on
/UPS_MOUNT_TAR_SOURCE, last written at Wed Sep 28 16:27:45 1994, clean
flag 30, number of blocks 243648, number of data blocks 233295, number
of cylinder groups 38, block size 8192, fragment size 1024, minimum
percentage of free blocks 10, rotational delay 0ms, disk rotational
speed 60rps, TIME optimization
A later Digital Unix CDROM behaves the same way with mount and reports
this with file:
$ sudo file -s /dev/sr1
/dev/sr1: Unix Fast File system [v1] (little-endian), last mounted on
/kits/tmp/gendisk17665/mnt, last written at Wed Nov 20 13:38:02 1996,
clean flag 3, number of blocks 151168, number of data blocks 150383,
number of cylinder groups 24, block size 8192, fragment size 1024,
minimum percentage of free blocks 0, rotational delay 0ms, disk
rotational speed 60rps, SPACE optimization
I also have a few OSF/1 CDROMs, which I assume are also the same format.
Any ideas? I can't be the first person to try to do this ...
Antonio
--
Antonio Carlini
antonio at acarlini.com
I was looking through some old journal entries and found this:
AI is lonely...
She has been sitting quietly in my house for the past 8 years. She runs,
but is old now and tired. Most of the time she sits in her room and
waits patiently. Waits for the users who ran jobs in the middle of the
night. Waits for PFTMG to run the daily feed. Waits for someone to Alt-U
in and begin to hack...
Waits for the TU77 MASSBUS interfact to be repaired
Waits for RP07 drives that will never be repaired
Waits to once again run the ITS tapes that sit quietly nearby.
She's lonely. And although I have been looking after her for a long
time, she needs help.
Is anyone still interested? No, she will not be trashed. But perhaps the
knight that guards her is getting old and needs someone else to share
the load. Someone who won't just sell her on Ebay or break her apart or
dump her off a loading dock.
I worked too hard to save her from that. Twice. I owe her a lot; she
rescued me way back when, yaknow. In a way she contributed greatly in
making me the hacker I am today.
But in the day and age where one can run a full ITS on a palm pilot is
there any room for MIT-AI?
And so the knight returns to quietly guard the last remaining ITS...
CZ
The funny part is someone replied "Donate it to a museum" and I wrote:
"*nod* Unfortunately, after the Boston Computer Museum debacle, I'm a
bit wary of museums. Other problem is it would just get stuck in a back
room and eventually tossed like it almost did at Digex."
Sometimes I wonder if I did fail. Anyone know if the LCM will be open
this summer? I'm going to be in Seattle for a day in August, wouldn't
mind stopping by and seeing how it was doing....
CZ
I?ve been given a couple of RLX blade server chassis loaded with blades (one with Transmeta Crusoe cpu?s, and one with Pentium III cpu?s). I hope you?ll allow me to count these as ?vintage? because of their interesting origin: the Pentium III loaded chassis was part of a 768 node computer cluster at the Sanger Institute in the UK, and was used in the last stretch of the DNA sequencing computations for the Human Genome Project.
I?d like to build a compute cluster out of these, but I don?t have the rpm?s they supplied to customize Linux for their blades. Ideally, I?d hope to find a copy of their ?Control Tower? blade management software, and their customized Linux installation images, but just the bare rpm?s would do for now. From the RLX platform guide, I?d hope to find:
kernel-*rlx*.i386.rpm
kernel-headers-*rlx*.i386.rpm
devfsd-*rlx*.i386.rpm
ucd-snmp-*rlx*.i386.rpm
net-snmp-*rlx*.i386.rpm
ucd-snmp-utils-*rlx*.i386.rpm
net-snmp-utils-*rlx*.i386.rpm
bootctl-*rlx*.i386.rpm
atftp-*rlx*.i386.rpm
lm_sensors-*-*rlx*.i386.rpm
lm_sensors-drivers-*-*rlx*.i386.rpm
lm_sensors-devel-*-*rlx*.i386.rpm
base-utils-*rlx*.i386.rpm
runctl-*rlx*.noarch.rpm
networkcfg-*rlx*.noarch.rpm
mgmtmode-*rlx*.noarch.rpm
namedcfg-*rlx*.noarch.rpm
dhcpdcfg-*rlx*.noarch.rpm
lilo-*rlx*.i386.rpm
grub-*rlx*.i386.rpm
rlx-clientpm-*rlx*.i386.rpm
This e-mail (including any attachments) may contain privileged, confidential, proprietary, private, copyrighted, or other legally protected information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient (even if the e-mail address above is yours), please notify us by return e-mail immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.
> From: Mattis Lind
> Thanks Noel for sorting this out.
Eh, de nada. But thank you.
>> I wonder if the ucode in the two versions is identical? The uROM chip
>> numbers should give it, (if they are the same on both versions, albeit
>> in different locations on the board), but I have yet to check. Does
>> anyone happen to know?
OK, so the situation here is pretty complicated. To start with / make things
worse, that CPU uses lots of PROMs. Lots and lots and lots and lots of PROMs.
For the data paths board (M7260), both major versions appear to contain the
same PROMs (going by the DEC part numbers), but the chip location (Exx)
numbers are all different.
For the control board (M7261), the C, E ('early' version) and F ('late'
version) etch revisions each contain mostly the same PROMs, but apparently
with slight differences between the sets of PROMs in each (as reflected in
different DEC part numbers). For details see:
http://gunkies.org/wiki/PDP-11/05#Control_PROMs
to which I have just added all the gory details.
As to getting the contents of all of them dumped in machine-readable form -
oi vey!
>> on the earlier version (prints for that version are in the GT40 prints
>> online
It turns out that I have hard-copy prints for the "C" etch revision of the
M7261, which do not yet appear to be online; the GT40 prints have the "E"
etch revision.
I will scan the pages for that revision of the board, and put them up 'soon'.
(I'm not doing the whole print set, it's about 1" thick, and most of them are
for other things anyway, like MM11-L memory, etc.)
Noel
In item https://www.ebay.com/itm/265045229011 I am curious as to whether the
gold islands on the top-side are functional test-points giving electrical
access to the underside pins? Was there a clip designed to attach to the
top-side of these chips for use in circuit analysis? Was this design unique
to Russian manufacture (I don't recall ever seeing this design previously)?
paul
OK, this is mildly off-topic... I am working on a piece of
telecom-related test gear and there's one IC I can't find data on.
It's a 40 pin DIL package made by GEC (the UK company), marked
MA8807A. I thought at first it was a ULA, but I can find refeences to
a 8bit * 8bit -> 16 bit multiplier with that number, so I guess that's
it. But I can't find a datasheet or even a pinout.
It may have appeared under the Plessey brand too, but I am not certain
of that I've been along my bookshelves, looked in the obvious books on
bitsavers etc and found nothing.
Does anyone have any data on this chip?
-tony