My Raspberry Pi Thinks It's a Mainframe!
As the Raspberry Pi started to ship the Sinclair ZX Spectrum turned 30 years old, and comparisons were being made between the two and their role in providing access to affordable computer hardware. Given the phenomenal advances in computing since the birth of the ZX Spectrum, I thought it might be fun to compare the Raspberry Pi with a computer that was closer to the state of the art at around that time, and to see if the Raspberry Pi could fill its shoes...
Introduced not long after the ZX Spectrum, the IBM 4381 processor was the workhorse of mainframe computer installations that could fill a data centre and support many thousands of users. Managing to do this with what may now seem to us like trivial resources:
2-2.7 MIPS CPU
Optional maths co-processor
Up to 4x I/O channels running at 3MB/second
Even when compared with the pocked-sized Raspberry Pi, which manages to pack:
965 MIPS CPU
FPU + 24GFLOP GPU
60MB/second I/O (USB2)
Actually, this comparison is more than a little unfair, in that metrics such as MIPS ratings are not that useful when comparing dissimilar architectures. And mainframes are pretty special, with things like “assist” processors that free up the main CPU from having to do certain tasks, and terminals that manage presentation and enable efficient use of mainframe resources. But still, this does serve as a powerful indication of fundamental technological progress that has been made.
Could a Raspberry Pi replace the IBM 4381? Well, it turns out that just as it's possible to use a Pi to emulate a ZX Spectrum, one can be used to emulate a somewhat larger mainframe computer. This has been made possible by a piece of open source software called Hercules, and next we'll cover the experience of running this under Debian Linux on a Raspberry Pi.
First we install the hercules package from the Debian repository, and then create a configuration file which tells it to emulate a model 4381 machine with 16MB RAM and terminals and storage etc. attached. Hercules is then executed from the command line, and we run up an IBM 3270 terminal emulator from another machine on the network, providing it with the IP address of our Raspberry Pi and the port number specified in the Hercules configuration.
On connecting, Hercules prints out a few details to the remote 3270 screen.
Then if we go to back to the Raspberry Pi (connected to over its UART via a PC running minicom) we see that Hercules reports that a terminal has attached.
A computer without software wouldn't be much use, and so Hercules was configured with virtual disk drives containing a very old public domain release of a mainframe operating system that still finds much use today, VM. As the name suggests this provides virtual machines (mainframes!), in which it's possible to run applications, some other mainframe operating system, or should you wish to utterly confuse yourself, another copy of VM with a third copy of VM running inside that.
Shortly after our 3270 terminal attaches to Hercules the VM system starts to boot, or “IPL” to use the IBM parlance. With VM reporting that it has 16MB of memory available, of which 460K is being used for the operating system nucleus (kernel).
After a short period of time start-up completes and VM provides the status of attached card punches and printers. Which are, of course, virtual and represented by files under the Linux filesystem.
If we go back to the Hercules instance running on the Raspberry Pi we can hit ESC to toggle the view to a screen which displays a virtual hardware console. With register contents displayed in the left-hand side of the screen, and details of the peripherals on the right-hand side.
Now that the system has completed start-up we can go to our 3270 terminal and log on to VM as an administrator, by using the command “logon maint”. After entering the password for the maint account we can then use “q dasd” to show details of the configured storage (DASD = direct access storage device).
Finally, when we are finished we tell VM to shut down before exiting the Hercules emulator.
So, a Raspberry Pi can be used to emulate a mainframe which would have filled a large computer room, and to run the same software which it would have run. Of course, the only reason you would do this is for fun, learning or perhaps as part of computer conservation efforts, e.g. in providing continued access to old computer software and/or data. A modern mainframe would massively outperform a Raspberry Pi and offer many benefits beyond simple processing power.
Having configured a mainframe on a Raspberry Pi, it was time to try out a Raspberry Pi on a mainframe! The image below shows the Pi sat on top (centre) of the CPU from an IBM 4381, which was recovered from a scrapped processor cabinet many years ago.
The 21 blue modules are ZIF socketed ceramic IC packages with heatsinks, and apparently each contain a 6x6 array of chips that each dissipate up to 3.6W! The six brown multi-way connectors to the left carry signal lines and the busbars up either side supply the required power of up to ~2.7kW. The whole assembly is analogous to the processor chip in a modern PC and was located inside a cabinet roughly the size of a wardrobe, along with a PSU, powerful fan supplying forced air cooling and support electronics. The 4381 cabinet being just one of many in a mainframe installation, with others containing things such as disk drives and communications controllers.
Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.
May 15, 2012 07:21
CommentsAdd a comment
November 2, 2015 12:08
Fantastic Ive worked on many mainframes 409 4331 Sytem 34/6/38 As/400 etc - Love to see them emulate AS/400as that was the last and longest contracts for me
Keep up the good work
November 25, 2014 19:18
@qubex I love that you have Hercules up and running on a Parallella board! I wonder if it could be extended to use the Epiphany cores as special I/O processors... Now that would be something.
It's funny you should ask about interfacing a real IBM terminal, as I've long wanted to do this and I believe it is possible using a 3174 controller, which can be picked up on eBay for not that much. However, you'd need to check as to which one to use, although in terms of media interfaces it would obviously need to have twinax (I imagine they all have this) and 10BaseT or similar. Then IIRC you would need a certain boot disk for the controller, that will allow you to "reverse TN3270" from the terminal and into Hercules over IP. I actually picked up two 3174s for this reason, but I'm not certain they are the correct version and haven't looked into boot floppies yet.
Of course, whenever I see all those 3270 emulation cards on eBay I can't help but wonder how hard it would be to write a Linux driver that did pretty much the same thing, albeit with Hercules on the same box and then the terminal direct attached. However, regardless of how difficult or simple that would be, it's definitely beyond me!
November 25, 2014 11:19
I am pursuing a project very much like this one, or rather: I am using a Parallela embedded system to emulate a later, more powerful IBM mainframe. But much of the underlying logic is identical. I have a Linux distro running on the board and there’s Hercules running inside that, happy and snug and somewhat stupefied at the inordinate processing power available to it.
There is, however, a complication, or rather, a very satisfying (though perhaps somewhat confounding) addendum, which is this: I am in possession of a working, 1978-era IBM 5221 terminal with keyboard.
Now, I know that this specific terminal uses the 5220 protocol used for the IBM S/38 (and later AS/400) and not the 3200 protocol that the S/390 and successors use natively. However, it provides the opportunity for significant realism, nostalgia, and general geek cred.
My question is this: does anybody have experience interfacing a modern system with a legacy TWINAX-sporting terminal? In my mind’s eye I am imagining some kind of screen parser and poller, and then some kind of standard box that converts between 5220 over TWINAX and x- or z-modem over RS-232; and then some kind of USB-to-RS232 converter. Alternatively some gadget that provided conversion between telnet over Ethernet and 5220 over TWINAX would be equally suitable.
In short, I’m fishing for ideas… and perhaps ready-made solutions to what, I imagine, was, back in the day at least, a fairly standard problem.
April 1, 2014 13:58
Like others, I'm confident that you could achieve what you want with a Raspberry Pi or similar driving a monitor. However, I think an actual physical console driven by the GPIO of such a board and with switches and incandescent lamps, or even just LEDs, would be far more interesting. And in fact this is something I've wondered about before, not with that system specifically, but in general with SimH — which can simulate a Honeywell 316, among other things — and Hercules.
Wouldn't it be fantastic if you could hook up a clone of a classic console to a small computer running Linux, and interact with the original O/S running on simulated/emulated hardware. Not just for enthusiasts and those who used to work with the actual machines many years ago, but for museums and perhaps universities also.
April 1, 2014 10:10
Robs, I agree with Boss that the lights should be doable. The actual indicators from that era were incandescent. The thermal lag of incandescent bulbs, along with the relatively slow response of the human eye, limits the effective flicker / update rate of the display. Updating the display 30 to 60 times per second should be very adequate. Each 30th/second update could output for each bit an analog brightness level corresponding to the activity on the corresponding bit over that time interval. (16 brightness levels would likely be very sufficient.)
Given that memory cycle time was one or two microseconds on the Honeywell 200 Series, you should have enough processing speed in a Raspberry Pi or modern PC to maintain a 16 bit counter for each address and data bit on the control panel, incremented once for each emulated cycle during which the corresponding bit is a "1". (2**16 > 1Mcycle * 1/30 sec) At the 30th of a second interval, divide the current value of each of the counters by the number of actual emulated memory cycles (which might be as low as one cycle if single stepping) to get the fraction of full brightness for the corresponding address or data bit indicator for that 30th of a second interval. Update the display (hardware or graphic) accordingly, and reset the counters to zero in prep for the next 1/30th second interval.
March 31, 2014 19:36
Hi robs, I can't prove you wrong, but I don't think that should be too difficult for someone who works with graphics as the inputs that determine the lights flickering are relatively low frequency. But I can't do it!
I did make a real-time system that used DirectX to be the synchronisation source for my whole program. It was all synced to 50Hz frame rate which read the asynchronous A/Ds, did the calculations, updated the display frame counters, updated the display etc., all in the available time slot. This was on an old PC, WinXP and DirectX6 or 7 from memory, so again I think a 'good' programmer could do something along the lines you want these days.
Your post stirred some great memories. In the early 70's the Technical College I attended installed the old Town Hall computer for use by the students. Can't recall the make/model but it had some great features, the 'engineers' panel was great, with its clunky push buttons, large side on rotary pots and a loud speaker to listen to bus faults or program errors. You could also raise and lower the logic supply voltages to identify 'future' errors that may cause problems soon at normal voltages!
The best day was when a student used the speaker on one of the data lines and wrote a program to play the tune 'Daisy Daisy' (our version of HAL from 2001....), it coincided with the college Principal showing the Mayor what we were doing with his old computer! The Principal went 'ballistic' but the Mayor was delighted and saw it as creative and the most interesting thing he had ever seen done on it!
March 31, 2014 17:59
That's interesting but doesn't solve my problem. Look at the home page of my website www.honeypi.org.uk which has nothing at all to do with the Raspberry Pi as it happens. In the first paragraph I mention the possibility of emulating a Honeywell 200 mainframe from 50 years ago, long before the machines that you mention were around, on a PC, but the problem is emulating the control panel visually. The lights on the panel were connected to the main memory address and data buses, so they flickered in time with every memory cycle. It's incredibly easy to emulate the internal processes of this antique computer, but I suspect that even a modern PC with directfb software would have a hard time displaying a realistic dynamic image of the control panel on its screen while running the emulator at the speed of the original computer. Of course I'd love it if someone could prove me wrong. If anyone wants to try I can provide the graphics for the control panel as used on my website to create the pictures. Personally I'd rather try to build the real computer than attempt that though.
November 1, 2013 08:59
Great job, it is nice to see that hercules can run on anything, including the Raspberry Pi! Next step parallel sysplex ;-)