test-drb May 2021

test-drb@ccmp.vtda.org

128 participants
102 discussions

by a.carlini＠ntlworld.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

2 years, 3 months

H7821 power supply in MicroVAX 3100, SCSI disk enclosures and others

by cctalk＠beyondthepale.ie

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.

2 years, 5 months

Mounting ULTRIX CDROMs on Linux

by a.carlini＠ntlworld.com

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

2 years, 11 months

Writings on AI from 17 years ago....

by cz＠alembic.crystel.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

2 years, 11 months

In search of RLX blade software

by camiel.vanderhoeven＠vmssoftware.com

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.

2 years, 11 months

PDP-11/05 microcode dump?

by jnc＠mercury.lcs.mit.edu

> 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

3 years

Sovier/Russian 132-pin PGA Ceramic IC Packaging

by pbirkel＠gmail.com

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

3 years

DEC Computer Lab for sale

by wdonzelli＠gmail.com

Over on the Discord, I have posted a DEC Computer Lab H-500 for sale. Needs cosmetic help, but will be priced accordingly. Offers? Off list... -- Will

3 years

H960 documentation

by jnc＠mercury.lcs.mit.edu

So, I have images of two different pieces of DEC documentation for the H960 series of racks/cabinets (the H950 is the bare rack; the H960 is the rack complete with various appurtenances such as side panel, stabilizer feet, etc). I had a request for them, so I've put them online. They are: http://ana-3.lcs.mit.edu/~jnc/tech/H960/DEC_cabinets1.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DEC_cabinets2.jpg The entry in the Direct Sales Catalog which covers them; includes illustrated breakdowns, and the DEC part numbers for everything. http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual1.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual2.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual3.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual4.jpg http://ana-3.lcs.mit.edu/~jnc/tech/H960/DECRackManual5.jpg The Assembly Guide; it shows in detail how all the bits go together (includes all the captive nuts, bolts, etc). Noel

3 years, 1 month

MA8807A ic datasheet wanted

by ard.p850ug1＠gmail.com

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

3 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb May 2021