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.
> 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
Does anyone know the size/threading of these? I've been searching high and
low and haven't been able to find any approximate or otherwise specs (they
use captive clips, so close is OK) - i've found the PSU mounting screw
sizes and sourced those though.
--
Gary G. Sparkes Jr.
KB3HAG
CHM doesn't seem to have much early DSP stuff in the collection
Does anyone have any of the TMS32010/20/30 or C1x/2x/3x hw/sw kicking around?
Other than the docs I've scanned there doesn't seem to be much on the web either.
> From: Toby Thain
> To get closer I'd need better images of the panels.
Hi, I borrowed a DEC inlay from someone (a KA10 CPU bay) and scanned a chunk
of it (as much as I could fit into my A4 scanner :-) at 200 dpi:
http://ana-3.lcs.mit.edu/~jnc/tech/jpg/KACPUPanel.jpg
I have a TC08 inlay, but it's currently being used in my QSIC display (until
we can get the RKV11-F/RPV11-D inlay done :-), and I didn't want to yank it
out. As far as I can tell, it's the same font on the two of them.
> the closest I know of off the top of my head is Akzidenz Grotesk.
The Akzidenz Grotesk Medium is indeed very, very close (other than the zero).
Do you happen to know if that font available for use in non-commercial
settings?
Thanks!
Noel
Manx lists MP-01394-00 as the Field Maintenance Print Set for the DEC
Professional 350. I can't find this online and I was wondering if anyone has
a scan of it by any chance?
Thanks
Rob
About 20 years ago I rescued a fully working Sun SPARCstation LX with CDROM
and QIC-150 tape drive - all 3 in lunchbox format - plus monitor when we
moved office and management decided they no longer wanted/needed it.
Shortly after I have installed an early version of NetBSD (1.3.3) from the
CDROM drive. I played with it for a few days and then stored the entire
system in a museum grade glass display cabinet. This is indoors with
minimal dust and benign temperatures between 18 degrees C to about 28
degrees C (typical room temperatures here in Perth in Western Australia
unless you run the air conditioner).
Now retired I took the stack of "lunch-boxes" and the CRT monitor out of
the display cabinet and powered it up. After 20 years no smoke came out but
the system didn't boot but reported trouble with the NVRAM setting. I still
could start NetBSD using a "boot disk" command. I googled the problem and
bought and installed a replacement TIMEKEEPER chip (M48T08-100). After
defaulting the settings and setting the MAC address and machine ID it was
happy and booted from disk without intervention. In NetBSD I then set the
date and time and all was good.
Then I decided to upgrade to the latest version of the SPARC version of
NetBSD 9.0. I downloaded and burned the ISO image to CD. Dropped it into a
CD caddy and inserted it into the CDROM drive (SUN Model 411 - really a
Sony CDU-8012 3.1e). I did a "probe-scsi-all" and it found both the hard
drive and the CDROM (target 6 unit 0).
Now comes the problem - if it try to run from it via "boot cdrom" it
doesn't even access the CDROM drive - the LED doesn't turn on unlike when
you do the "probe-scsi-all".
The "cdrom" alias is really: "/iommu/sbus/espdma at 4,8400000/esp at 4
,8800000/sd at 6,0:d".
The "disk" alias is really: "/iommu/sbus/espdma at 4,8400000/esp at 4,8800000/sd at 3,0"
The "@3" versus the "@6" are the SCSI IDs of the disk drive versus the
CDROM. I don't know what the trailing bits mean. I tried cdrom aliases from
"sd at 6,0:0" to "sd at 6,0:f" and all report:
Can't read disk label
Can't open disk label package
Can't open boot device
The LED doesn't blink even once unless I remove and re-insert the caddy
with the CDROM media or if I do a "probe-scsi" or "probe-scsi-all".
I tried original Sun Solaris 2.4 installation media with the exact same
result/symptoms.
I also tried to access the CDROM from NetBSD using "cat /dev/cd0a" but the
drive's LED didn't blink and I got an obscure error message.
The Boot ROM revision is reported as 2.9. The system was bought about 1985
or 1986 and has seen very little use.
I searched google without success. Maybe I used the wrong search terms or
the equipment is just getting too old and FAQs have disappeared.
What would cause the CDROM boot problem?
There is a chance that the actual Sony drive died. I partially disassembled
it hoping to find dust stuck on the LASER optics but it was nice and clean.
The positioning and ejection mechanisms work just fine. The whole system
was working before I put it into my relatively dust proof glass display
cabinet.
Thanks and best regards
Tom Hunter
Today I was working on a very nice 1995 vintage SPARCstation LX with CDROM
and QIC-150 tape drive (3 lunchbox type units). I was trying to install a
newer version of NetBSD on it than was already installed. The stack of 3
units was stored in a museum grade glass display cabinet. Sadly all 3 units
have a small degree of yellowing but more importantly the plastic cases
have become very brittle and bits just break off with minimal mechanical
strain.
Is there any process to reverse the brittleness which could be used to
preserve the cases?
Thanks
Tom Hunter
I have been working on a project for some time to connect a IBM3270
compatible Alfaskop terminal with its IBM 3274 compatible cluster
controller to the Hercules mainframe emulator.
Yesterday I eventually succeeded. I was able to login to TSO on my Hercules
system that ran MVS 3.8j.
Here are a couple quick video clips:
https://youtu.be/H1Sxt7xjn4Yhttps://youtu.be/CFfB3yCN9OI
To achieve this I created a small piece of hardware I called SyncDongle,
essentially it's just a few level converters, connectors and a STM32F103
blue pill.
On the hardware I run a small piece of firmware, BSCBridge. It bridges
between the sync serial BSC used by the Alfaskop cluster controller and the
BSC variant that the 2703 emulation inside Hercules is using.
More information here: https://github.com/MattisLind/alfaskop_emu
and here http://www.datormuseum.se/peripherals/terminals/alfaskop
There are good chances that the SyncDongle/BSCBridge combo could work with
a 3274 or 3174 controller as well but I haven't tested since I don't have
one. But no guarantees given, though. If someone has a spare 3174-51R,
-61R, -81R or -91R I would be very interested in it.
Actually there is a good chance that it could work with general BSC use.
Maybe for NJE between Hercules and a real IBM machine? Or 2780/3780 RJE
terminals? Or other third party 3270 terminals using BSC.
The BSCBridge firmware only supports non transparent mode at this point, it
works fine with Alfaskop since it does not support anything else. Maybe a
showstopper for 3174 with 3279 terminals? SHouldn't be that difficult to
add transparent mode if needed.
/Mattis