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...
> 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:
to which I have just added all the gory details.
As to getting the contents of all of them dumped in machine-readable form -
>> on the earlier version (prints for that version are in the GT40 prints
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"
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.)
I'm making some replacement cables and paddle cards so I'm on the lookout
for these connectors on cable assemblies.
You'd think there would be piles of them around since they were used as
the interplanar connecting cables in lots of IBM products.
Does anyone have a collection of Intel Developers' Insight CD-ROMs in
physical form or as images? The only physical CD-ROMs I have are a two
disk set from February 1998. I don't know what time period these were
available. Maybe mid or late 1990s to early 2000s? They have a variety
of information on them such as datasheets and manuals that might not
always be easy to find online anywhere anymore.
As one example of something that I was recently unable to find online
anywhere is a copy of either of these, which might have been available
on some of the Intel Developers' Insight CD-ROMs:
297372 16-Mbit Flash Product Family User?s Manual
297508 FLASHBuilder Design Resource Tool
Those are mentioned in various Intel flash memory datasheets and
databooks from around the 1995 timeframe.
The February 1998 CD-ROMs contain a copy of the Intel Flash
SOFTWAREBuilder, which appears to be related to but different from the
Have one filed in somewhere with all the s-100 boards... now I have a reason to dig it out! Yes... memories of Wirt's projects!
On Wednesday, December 16, 2020 Bill Degnan via cctalk <billdegnan at gmail.com; cctalk at classiccmp.org> wrote:
Very interesting Stan.
Thank you for sharing this info
On Wed, Dec 16, 2020 at 2:43 AM Stan Sieler via cctalk <
cctalk at classiccmp.org> wrote:
> Some years back, I was asking if anyone had information about the speech
> developed for the Altair 8080 by Wirt Atmar of AICS (in New Mexico).
> No "hits".
> Most places on the web claimed the Computalker was first, given the date as
> 1976 or 1977.
> (Earlier speech synthesizes existed, but they were external boxes that one
> interfaced to,
> or were standalone (often with a large/weird keyboard).)
> Today, I stumbled over a fairly bad OCR of Byte magazine from August, 1976
> It has two articles about speech synthesizers for S-100 bus systems.
> The first is by the Computalker people, who say:
> At the time this article
> goes to press, a synthesizer
> module incorporating several
> detail refinements and im-
> provements over the circuits
> of this article is being de-
> veloped by the author and
> A detailed user's
> guide will be supplied with the
> Computalker module
> Note the future tense!
> The second is by Wirt Atmar, whose product *was already shipping*.
> Near the end of his Byte article, Wirt lists currently available products:
> At the present time, two speech synthesizers
> are both commercially available and affordable by
> the hobbyist.
> One is the Votrax produced by:
> Vocal Interface Division
> Federal Screw Works
> 500 Stephenson Dr
> Troy Ml 48084
> Price, approximately $2,000
> Interfacing: Parallel or Serial (RS-232)
> The second is the Model 1000 manufactured by:
> Ai Cybernetic Systems
> PO Box 4691
> University Park NM 88003
> Price, $425
> Wirt had told me (twenty years ago or so) that he thought his was the first
> for microcomputers (e.g., a user installed card, not an external box).
> Now, I'm sure ... but it was realllly close!
> Wirt demonstrated his product at the earlier MITS World Altair Computer
> tion, where it won first prize.
> He advertised it poorly/infrequently, since it was mostly a side business.
> And, that shows, since history doesn't remember it.
Hi all --
Making some progress with the "fire sale" PDP-11/70. Over the past month
I've rebuilt the power supplies and burned them in on the bench, and I've
gotten things cleaned up and reassembled. I'm still waiting on some new
chassis fans but my curiosity overwhelmed my caution and I decided to power
it up for a short time (like 30 seconds) just to see what happens. Good
news: no smoke or fire. Voltages look good (need a tiny bit of adjustment
yet) and AC LO and DC LO looked good everywhere I tested them. Bad news:
processor is almost entirely unresponsive; comes up with the RUN and MASTER
lights on, toggling Halt, and hitting Start causes the RUN light to go out,
but that's the only response I get from the console.
I got out the KM11 boardset and with that installed I can step through
microinstructions and it's definitely executing them, and seems to be
following the flow diagrams in the engineering drawings. Left to its own
devices, however, the processor doesn't seem to be executing
microinstructions at all, it's stuck at uAddress 200.
In the troubleshooting section of the 11/70 service docs (diagram on p.
5-16) it states:
IF LOAD ADRS DOES NOT WORK AND:
- RUN, MASTER & ALL DATA INDICATORS ARE ON
- uADRS = 200 (ZAP)
THEN MEMORY HAS LOST POWER
Which seems to adequately describe the symptoms I'm seeing, but as far as I
can tell the AC and DC LO signals are all fine. (This system has a Setasi
PEP70/Hypercache installed, so there's no separate memory chassis to worry
about.) I'm going to go back and re-check everything, but I was curious if
anyone knows whether loss of AC or DC would prevent the processor from
executing microcode -- from everything I understand it should cause a trap,
and I don't see anything in the docs about inhibiting microcode execution.
But perhaps if this happens at power-up things behave differently? And the
fact that the troubleshooting flowchart calls out these exact symptoms
would seem to indicate that this is expected. But I'm curious why the KM11
can step the processor, in this case.
I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday)
before I poke at this again, just looking for advice here on the off chance
anyone's seen this behavior before.
Thanks as always!
From: dwight <dkelvey at hotmail.com>
> If we'd thought about it we could count to 1023 on our fingers.
I used to play string bass in a symphony, and there were many times that
there would be long periods of rest, where it was important to count the
bars (measures) going by so as to come back in at the right time. To this
day (that was 40+ years ago) I can still count quite rapidly up to 31 on one
hand (either one). Higher numbers slow me down a bit...
Old bass joke: During the last movement of Beethoven's 9th symphony, there
is a very long tacit (rest) for the basses. So the bass section all went
over to the bar across the street for a drink or three. To keep the
conductor from passing by their entry, they put a rubber band around his
music. So the situation was... Bottom of the ninth, basses loaded, score