AlphaServer 4100: Photo Tour – DEC StorageWorks BA-356 Storage Shelf

What a mouthful of a name. What the bloody hell does all that mean? The Unit is a Digital Equipment Corporation (DEC) StorageWorks (name of the product line) Storage Shelf. Basically it’s a SCSI box. The model number (BA-356) is one of the last in the BA-35x line of storage units built using DEC’s Storage building Blocks (SBB) units. Each BA35x contains:

  • At lease 1 (optionally 2) Power Supply
  • 1 Interface module. There were many different types
  • Various SCSI drives including:
    • Hard Disk SBBs (single width)
    • TZ-series SCSI tape drives (3-units wide)
    • Dual 5.25″ bay unit with RRD5x series CD-ROM or Tape Drive
  • Dual rear-mounted air blower units

The BA-356 is very easy to service. As you can see in my previous post wit ha video describing how to strip down a Hard Drive SBB, the SBBs are also easy to service. Below are some photos taken as I stripped and inspected one of the two units that came in the AS4100.

IMG_3703IMG_3701IMG_3704IMG_3705 - Version 2IMG_3706 - Version 2IMG_3707 - Version 2
IMG_3725IMG_3720IMG_3722IMG_3723IMG_3726IMG_3727 - Version 2
Posted in Blog | Leave a comment

AlphaServer 4100: Progress (hopefully)

Well I finally get back to the AS4100 and removed the PSUs. I took the opportunity to inspect the second PSU that didn’t go pop while I was in the mood. The PSUs are very easy to open, 2 Torx-10 security head screws and the 2 halves slid apart with next to no effort. 2 large cables connect the pair of circuit boards. The 6-pin plug at the back edge is easy to remove, the 4-pin in the middle is a swine as one of the press-in latches is part obscured by a transformer body.

PSU 1 (that went pop) is very clean and looks in good order inside. There is no staining or signs of damage to the boards and no blown components. As I suspected when the PSU didn’t shut down in spite of the nasty smell, the cap that blew was a main filter capacitor. In fact, it was inside the filtered mains input socket, so the mess was very much contained. Even better news is that we had a replacement filtered mains input socket on stock that fitted right in it’s place. A little soldering (thanks, Dad!) and the new filter is in place and the PSU back together.

PSU 2 is also very clean and looks in good order inside. There wasn’t much to see, again nothing looked out of place and there was no dirt or contamination. I did discover one interesting thing – the Mains input filtered socket had already been replaced! So I guess that happened to the previous owner too. Makes me fell a whole lot better!

As Mark Wickens advised in a comment on my previous post, it’s not uncommon for mains filters to blow. Dad concurred on seeing the filter socket and the evidence of the blown filter cap.

Next step is to re-install the PSUs in the system drawer and power them up and see if both get OKAY LEDs on the power management board.

If they are both okay in spite of my poking around in them I then need to turn my attention to diagnosing the remaining blank LCD and not starting up issue. That’ll all have to wait for the weekend I think.

Posted in Blog | Tagged , , , | 3 Comments

Raspberry Pi VAXcluster: Foundations Part 2 – Compiling SimH

Assuming you have installed all the packages you need from part 1, we will proceed to get the source code for SimH and compile the VAX Simulator.

Downloading SimH

The SimH sources are available from I find the easiest way to do this is by grabbing the URL from the SimH website and using wget to suck down the file. If your Raspberry Pi Linux distro has a GUI system loaded you can download it using a browser, of course. Mine generally don’t have such facilities. Here’s how to get it if you don’t have browser access (and you installed wget):

I find it easiest to work from a remote machine via the ssh secure shell. My distro installs are usually very minimal so The link changes per version, so be sure to visit that page and get the latest source code link. Once you have the link (it should look like or similar), copy it and paste it into the following command in a terminal (assuming you are already in your home folder):


Wget will now download the file.

Saving to: `'

39% [==============>                        ] 1,224,703   84.9K/s  eta 26s

To access the sources we need to unpack the Zip file now we downloaded.

Create a directory and move the zip file into the directory before you unzip it or you will fill your home folder (or the folder you downloaded it to) with source code files.

Once you have moved the SimH source file zip to a new folder, enter that folder and run:


Now you have source code, it’s time to compile. Doing this in a Raspberry Pi can be a little time consuming, so be operated to go grab some coffee.

SimH does not require pre-configuration (there is no ‘./configure’) like many source bundles, but you can specify a few options, such as the Simiulator you want to compile (compiling all of them is unnecessary and takes forever) so just run:

make vax

As previously mentioned, the make process will take quite a while.

Note 1: There are some other options, such as USE_INT64=1 and USE_ADDR64=1 which you can add to the compile-time options (add them after the above commands). These allow SimH to access files larger than 2GB. I don’t know if they work on 32-bit microprocessors (the ARM11 is 32-bit) and also I do not recommend using large files on the Raspberry Pi as it can take a long tome to copy them or make backups. Also, space tend to be limited on SD cards and VMS really only needs about 400MB or less to install into, even if you add most of the layered products on the CD.

Note 2: As of version 3.9-0, the USE_NETWORK=1 compile-time option is not required to create a network enabled binary. Binaries compiled without this option will use libpcap for networking support dynamically if it is present at a known path location at compile time, or disable networking if it is not found. USE_NETWORK=1 can still be passed but the resulting binary will fail to run if libpcap is not present.

Once SimH has finished compiling you will find the compiled binary executable in the BIN directory created inside the folder where you ran make from (e.g. /home/fred/simh/BIN). You will also need the ka655x.bin file in the VAX directory to run the simulator (more on that later).

Posted in Blog | Tagged , , , | Leave a comment

Rasberry Pi VAXcluster: The Foundations Part 1 – Preparing Raspberry Pi for SimH

What you need to get started:

  • A Raspberry Pi board
  • A suitable SDHC with a Linux operating system (or ‘distro’ as they are known) image installed for Raspberry Pi. You will need a decent slab of free space for most VAX simulations, 1+GB ideally, so maybe 1.5GB free on your card.
  • About 2 hours

Note: If you are short on space on your SD card can use external USB storage to store things like disk, tape and cdrom images too. It means re-mountiung the USB storage when you power on the Raspberry Pi to use SimH, however. Although this can be configured automatically in some Linux distros you will have to investigate that idea separately and I won’t cover it here.

I’m going to assume you already have a usable basic Linux environment bootable on your Raspberry Pi and are comfortable with working at the command terminal. You will also need access to root
user prvileges either by loggiong in as ‘root’ (which is bad practice), using ‘su -‘ to swithc to root, or using sudo (see below).

To compile and run SimH, and make it more usable, you will need to have the following pre-installed:

  • wget – Quickest way to directly download the source from the SimH website .
    (Debian package: wget)
  • Build tools (gcc, gmake etc.) – SimH needs to be compiled from source on Linux. Large Raspberry Pi distros usually have these installed, the minimal ones don’t. It’s always worth checking.
    (Debian package: build-essentials)
  • unzip – to unzip the source, most distros have it installed but some ‘minimal’ ones do not so make sure you have it.
    (Debian package: unzip)
  • libpcap – for networking support. You will need the library itself and the development headers for the networking to be enabled at compile time.
    (Debian packages: libpcap0.8 and libpcap-dev)
  • telnet – to communicate with the simulated VAX
    (Debian package: telnet)
  • GNU screen – allows you to start then detach your SimH simulator console to resume later (more cool ‘screen’ tips in a future post!)
    (Debian package: telnet)
  • sudo (optional) – allows for smoother running of simh as ‘root’ from non-root accounts. You will need to run SimH as root to get network access via libpcap (there is no other way, sorry!). Alternatively you can use;
    su -c "[command] [params]"

    but you will have to type quotes around complex commands and enter your root password every time you run SimH.
    (Debian package: sudo)

  • OpenSSH (server) – allows you to access the command terminal of your Raspberry Pi remotely using , for example, a Terminal app in Linux or Mac OS X, or the PuTTY terminal emulator in Windows. A lot of Debian distros, even the minimal distros already have this installed. You can check it’s running using the command:
    ps ax | grep sshd

    You should get 2 results, one will be the command you just ran and the other should look like:

      789 ?        Ss     0:00 /usr/sbin/sshd

    (Debian package: openssh-server)

With all these installed you will have good platform to compile and run SimH on Raspberry Pi.

Posted in Blog | Tagged , , , | Leave a comment

AlphaServer 4100: Where next?

Right. I’ve stopped moping about the 4100, I’m going to kick ass and take names and see if I can cure it’s ills. With the machine down to 1 PSU potentially, it’ll only run with 2 CPUs. That means pulling two out, even though non seem to be suspect according to the diagnostic lights it hasn’t got the guts to run all 4 on one PSU. Dad (electronics wizard extraordinaire) has agreed to take a look at the PSU that went pop. If we can’t fix it then a refurb is gonna cost close to £100, so we need to prove the machine first. Here’s hoping the second PSU holds up!

I have 2 sets of diagnostic procedure from the Service Manual and User Guides to look through to see if I can narrow the fault down. More later…

Posted in Blog | Tagged , , , | 2 Comments

How To: Disassembly of a StorageWorks BA-356 SBB Drive Caddy

The good news is… I did mange to get this out yesterday, which is a video showing how to dismantle a StorageWorks BA-356 drive caddy. Just in case you never worked it out…

The video is also available via the How To Guides section.

Posted in Blog | Tagged , , | 2 Comments

AlphaServer 4100: Never Assume…

Today I re-assembled the AlphaServer 4100 I picked up from a friend yesterday (we knocked it down into parts to transport it). It had been stored in a garage in less than stellar conditions and although a thorough inspection of the system drawer revealed nothing of concern. What I *should* have done next was strip and check the power supplies for faulty components, small creatures and other crap. What I actually did was power it on.

The result? Well nothing went immediately bad, the LCD panel came up, it went through some diagnostics, ended up sat at a screen with a name on and stopped (I assumed it was some kind of custom string like the system name, node name etc.). I let it sit for a few minutes and then powered it down. On powering the second time the system went through another diagnostic as far as the CPU test and hung after testing CPU 3 (the 4th and last). I decided diagnosis of this error would require a terminal and hooked up a VT510 to the console port. On powering it on the third time (and subsequent times) the OCP (Operator Control Panel) LCD that displays diagnostics remained blank and nothing happened. Nothing I did, including removing all the PCI cards, reseating the RAM and CPU boards, checking the PSU connectors and removing the mains to let it cool down/discharge worked.

Then came the kicker. While crouched behind the system with it powered down, reading the diagnostic LEDs, a loud pop and a cloud of that all-too-familiar magic blue smoke erupted from the front. I ran round and yanked the power. Upon investigating it looks like a capacitor has gone pop in the mains input side either inside or right next to the mains plug. I had assumed the PSUs looked fine. I was wrong, clearly. Seem you just never know…

Posted in Blog | Tagged , , , , | Leave a comment

Raspberry Pi VAX Cluster: Cutting out the fluff?

Well money matters have not worked out as planned so my grand plan for a Raspberry Pi VAX cluster is being rethought.

This exercise has been good for making it better bang-for-the-buck and also cutting out some of the crap I won’t have the time to do.

I am okay with paying for another Raspberry Pi (because, well, they hardly cost anything) but right now I am having to rethink. A lot of the hardware planned will not make the RetroChallenge project. I still have an Intel Atom board, will have 2 Raspberry Pi Boards and have the USB powered hub for power and connectivity to the Pis. I have a nice-looking Mini-ITX case that may well become the new enclosure. The internal LAN with routing will no longer be included because I have a lot of learn and do and won’t be able to afford the switch to mount inside for that. Also the Atom board I have that I will have to use for the project only has one ethernet port The finished item will just have an exposed LAN port for each board (3 in total) that you can plumb in to a switch.

The current Plan is revised now to:

  • A Storage, Database and File Server (Intel)
  • A DEC Notes Server (Raspberry Pi)
  • A workstation node (non-voting) (Raspberry Pi)

I also have something else retro and nice in the pipeline but I can’t talk about it right now until I can confirm if it’s is viable.

Posted in Blog | Tagged , , , | Leave a comment

Rasberry Pi VAXcluster: Detailed Plan Part 1 – Initial Structure Planning

So I wrote my original RetroChallenge 2012 Summer Challenge proposal over a week ago and I’ve had a lot of time to think about the project since then. I have decided to modify my plan slightly, I think it’s an improvement and will make the cluster a truly innovative piece of hardware and software integration.

Proposed Structure

  • The revised design will consist of 1x Intel Atom Mini-ITX motherboard (running NetBSD) plus 3 Raspberry Pi boards contained in a 1Ux500mm server chassis (that’s about a 500mm square footprint).
  • SATA or MiniPCIe/SATA storage will be used on the Atom Motherboard to optimise I/O performance from the simulated storage devices.
  • The TCP/IP networking will be setup thus:
    • The Atom motherboard will (hopefully) have 2 Ethernet Ports. One will be wired into the internal network and one exposed to the outside world.
    • The internal TCP/IP network will exist on it’s own subnet (I plan on using the as it’s not commonly used)
    • The network will be bridged in NetBSD on the Atom motherboard to allow DECnet packets to flow between the interfaces, effectively allowing DECnet traffic in and out of the cluster freely.
    • The out-facing LAN interface on the Atom motherboard will be intended top be configured to the subnet of the user’s network, thus giving the entire cluster effectively 1 IP address.
    • Terminal access to each Raspberry Pi SimH simulation will be provided via the Atom NetBSD OS.
  • I plan on having the following nodes:
    • Atom ITX board: VAX 3900 simulation with 8 RA92 (1.5GB) disk images. Responsible foe user records, user storage (each users default directory), also possibly FTP, FAL, LAT, MOP and DECnet file services to the outside world, web server (possibly allowing remote Notes access).
    • Raspberry Pi 1: VAX 3900 simulation DEC Notes server (I love DEC Notes).
    • Raspberry Pi 2: VAX 3900 simulation Disk-based Workstation
    • Raspberry Pi 3: VAX 3900 simulation Diskless Workstation (possibly booted using a MOP image?)
  • Each VAX simulation will run as a background process using GNU ‘screen’ to manage the session and allow it to be picked up and dropped without disrupting simulator functionality and will start with the host machine on boot.
Posted in Blog | Tagged , , , | 1 Comment

Rasberry Pi VAXcluster: Retrochallenge 2012 Entry


I have long been interested in recreating older platforms on new hardware. During the last year I have really fallen very much for Digital Equipment Corporation’s line of machines and operating systems. In particular RSX-11M (PDP-11) and VMS (VAX and Alpha). One thing that has taken particular interest recently is the idea of simulating big old machines on little new hardware.

At DEC Legacy 2011 I exhibited my first DEC emulation project, a Intel Atom D410MO-based small form-factor computer using only solid state storage and a single 12V power supply. This system was able to simulate a MicroVAX 3900 system, using the SimH computer history simulator, with ease, giving a useful and functional OpenVMS 7.3 working environment that consumed less than 15 Watts of power at peak CPU usage as well as accurately and fully emulating the original DEC VAX hardware.

Also in the last year gathering momentum and production of the RaspberryPi Foundation’s first Model B low-cost, low-power ARM project board has become a reality. Having taken delivery of on Raspberry Pi I have been able to assess the board and it’s features.


At some stage along the way the idea for a project hit me. One of (Open)VMS’s greatest strengths is it is one for the best (and still to this day) systems available for creating clusters of computers that interoperate and share resources seamlessly. VMS clusters have traditionally use high-powered hardware (VAX, Alpha and latterly Itanium) to create these clusters, consuming vast amounts of power and resources but creating a powerful computing environment. I, however, want to take a different approach. Knowing now that RaspberryPi makes a feasible and useful platform for running VMS, via SimH, I propose the following:

  • A cluster containing 3 or more simulated VAX systems running OpenVMS 7.3 linked together as follows:
    • A file/storage server (possibly using USB attached SSD or hard drive storage)
    • A DECnotes server (because Notes rules)
    • A database server
    • A ‘workstation’ with several programming languages, word processing and Mail
  • Physically the cluster will consist of a powered USB hub, Ethernet switch, a RaspberryPi board for each ‘VAX’ and necessary power supplies.
  • Cluster interconnection will be achieved via ethernet.

Challenges in this project include:

  • Creating a standard base-setup Debian Linux image to start out for each ‘VAX’
  • Continued learning on topics of OpenVMS and VAX systems
  • Learning how to build and interconnect OpenVMS clusters
  • Creating a physical package for the RaspberryPi boards to live in (optional task)

All information will be published via:

Posted in Blog | Tagged , , , | Leave a comment