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
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
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 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...
I've recently picked up a new Applesauce floppy disk controller and have been playing with attaching various different drive types and imaging different Apple II, Atari, TI and other floppy disks with it. So far I've mostly imaged unprotected disks and run them in various emulators just fine. I've since added a sync sensor to one of my older Disk II drives and started to make some flux images of protected disks. These too seem to run fine in the emulators I've tried. The documentation on the device is limited at the moment, particularly the software, and while it is slowly being updated I was wondering if anyone else here had any experience with the setup. Any hints, suggestions, best practices, "do this to get the best copy", etc, to pass along would be appreciated. For example I read you can try to recover borderline disks by having it do multiple passes of the bad sectors. I see how this is done on the Fast Image option and has helped a couple of times but don't see any way to do
something similar via the Flux Image option. Does it not work/matter with those? Also I see sometimes it reports a file as bad if I do one image type but if I do the other it comes back as okay. So I tend to play with both when I can. There is a lot of options and functions in the Flux Image option that I just really don't know how it works or what to do with it so far that any info would be great. I know it can image non-Apple II disks as well and I've done a few. It works great on Apple II protected disks but wonder how to deal with protected disks from other systems? Or is that more an issue of other emulators and such not having something like the .woz format being used with the Apple II? I bought this for my Apple II collection and it was a nice surprise to learn it could work with other systems too, just looking for more info about them as well. So far I really love the device and it has been worth the long wait for new units to come back into production again. Especially as it
is a new design that allows for attaching PC floppy drives now as well. I've noticed the doc on the site being updated, just hope that they can find time to update more, particularly in regards to the client software. Best, David Williams www.trailingedge.com (http://www.trailingedge.com)
Another thing Prolok did was produce a small 3 disk set of sample disks
with the Prolok protection. Somewhere around here I still have a set of
As I recall, a program was included on each disk to copy the program to
be copy protected to the special disk.
I received a note today from a fellow in London who has 2 9-track tapes
that he'd like read. Brands are CDC and BASF, so media shedding should
not be a problem. Dates are '92 and '93, so likely 1600 or 6259. The
tape seal on one (the other has no seal) is IBM-style, which may be the
system that produced the tapes.
Any takers? Let me know if so, I'll put you in contact and you can take
things from there.
All the best,
> From: Ed Cross
> I'm currently restoring a PDP-11/70 system and need the following
> boards to complete the CPU: FP11-C
>From your mention of the FP11-C, I gather your -11/70 has a KB11-C (later)
CPU, not the KB11-B CPU of the earlier PDP-11/70's (prior to 1976 - the
difference between the two was whether they took the optional FP11-B or FP11-C
Not that it makes a big difference in your case; the 4 cache cards are the
same in both.
There used to be a seller on eBait (on the mid-East Coast - Baltimore, IIRC)
who was selling -11/70 CPU cards (I bought a whole spare set from him) but
alas he seems to have gone away (or sold them all; a quick search, both on
eBait, and in my email, didn't turm him up; I can institute a deeper search
if need be).
>From the blog of someone who got a KB11-A working, you'll really need KM11
cards; dunno if Guy Steele still has those clones he was selling.
There are definitely some versions of Unix which will run fine on -11/70's
without the FP11 (e.g. V6). The system binary is different for the
with/without versions, though: in the assembler code which saves the state of
one process before switching to another, there is code like:
which will probably get an illegal instruction trap in kernel mode on a
machine with no FP11, and is therefore conditionally assembled (depending on
if the particular machine the system is being built for has an FP11). Perhaps
the later BSD versions look for the FP11 on startup, and adjust their
behaviour appropriately, but I'm not familiar with them.
V6 as distributed contains system binary for an -11/40, which will run on
_any_ -11 UNIX will run on, and can be used to build appropriate system
(Diversion: I've never found out whether the KB11-B and KB11-C of the -11/70
used/could use the same backplane or not. By examining the prints for the
boards of the FP11-B and FP11-C, and seeing on which pins they exchanged
signals, and what signals they exchanged with the rest of the CPU, and on
which pins, it should be possible to work it out. Ditto for the M8133 ROM and
ROM Control of the KB11-B, replaced with the M8123 in the KB11-C.)
(Interesting factoid: the M8123 is the only card shared between any variant
of the -11/45 and -11/70: both the KB11-C and KB11-D use it. Of course, I
think we're still missing a wirelist for the -11/70 backplane, of any
variant; and the ECO history. There appears to have been at least one poorly
documented upgrade; see here:
Hey all --
I picked up a TC01 in trade (for a TC08) a couple of weeks back and this
past weekend I got it hooked up and powered up with my PDP-8/I + TU55
transport. I've been debugging it and have solved a couple of issues but
the current one has me stumped and I'm looking for advice, hoping I
overlooked something obvious.
At this point the PDP-8/I can talk to the TC01 and use it to control the
TU55 without issue. I've mostly been using MAINDEC-08-D3BB to exercise the
and issuing FWD/BACK commands via the "Basic Motion" routine the tape runs
>from one end of the tape to the other, stopping at the endzones correctly.
The tape comes up to speed properly, the COUNTER register increments, and
in general the various status lights on the panel do what I expect them to
The root symptom I'm seeing now is that DECtape operations (like SEARCH)
don't complete, and I've traced this back to the MK BLK MK signal not
getting asserted. This signal is generated by a large AND gate (see p. 112
This gate ANDs together a pile of signals from the WINDOW register and the
counter, looking for a specific bit pattern on the mark tracks; this AND
gate is never satisfied because the WINDOW register's MSB (W1) is stuck
low. On the scope it's a completely flat line, no glitches or anything
Despite my best efforts I cannot figure out why this is. Here's what I've
looked at and what I've discovered thus far:
1) The inputs to the W1 flip-flop (pins U (clock) and V (data) look to be
correct -- U is identical to the TP1 signal being passed to all the other
flip-flops in the chain, and V is identical to the data coming out of W2 --
levels all look fine.
2) The outputs of W1 (pins T and S) are not being pulled up or down by
anything external. I've gone so far as to completely disconnect T and S
>from the backplane (with some tape over the card fingers) and the outputs
are still a flat line.
3) The output of pin T goes to -3V when 0->WINDOW is de-asserted (when tape
is in motion), returns to 0V when 0->WINDOW is asserted after the tape
stops. (S is the inverse of this, as expected.) (As an aside, the
schematic drawing suggests that 0->WINDOW ought to be a pulse given the
arrow symbol; this does not appear to be the case. Other flip flops in the
chain seem to behave properly, regardless...)
4) The backplane connection to the R203 flip-chip that the W1 flip-flop is
on is fine. I've beeped this out and there's no significant resistance
between the backplane pins and the connection to the card in the slot.
5) W1 is not affected by the state of the two other flip flops on the R203
(also tested by disconnecting all pins other than power/gnd and pins
R/S/T/U/V with tape).
6) Swapping in a different, working R203 shows no change in behavior.
6) Sometimes, randomly, W1 starts working. Last night I noticed that the
solder side of R203 was rubbing against the top of the "flip chip" packages
on the R107 next to it and even though those shouldn't be conductive, I
stuck a piece of cardstock between the two. W1 started working! I tested
things for about a half hour in this state (interrupts were still not
occurring, much to my annoyance) and this morning I powered it up and it
was still working. Pulled the cardstock out and W1 stopped working; this
would seem to causation. Put the cardstock back in... still won't work.
Backplane connections all test out fine (see (4) above). Put the R203 on
an extender (to completely avoid interference with neighboring cards) and
still no go. Possibly the insertion of the cardstock flexed the board or
the connection with the backplane slot ever so slightly to make things work
but if so I've been unable to replicate it.
All of this still sounds like a bad connection somewhere (backplane, cold
solder joint, broken trace) but the evidence seems to be against it
(checked, double-checked, triple-checked backplane, swapped R203s around,
Anyone have suggestions? I'm going to start looking at things on the board
itself (which is going to be a pain given how things are currently arranged
in the chassis) but curious if I've missed anything here...