Raspberry Pi > Work It, Do it, Emulate it, Faster, Better, Stronger

Dfg

[h=1]Raspberry Pi is amazing.[/h]As well all know Pi is a pretty nifty piece of hardware but did you know you can use it emulate different architectures from the past. I found two articles written by the same guy about it.

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
  
• 4-32MB RAM
  
• 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
  
• 256MB RAM
  
• 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 controller

Link
[h=1]A Raspberry Pi (VAX) Cluster[/h]

In a blog post last month I looked at how a Raspberry Pi can be used to emulate a formidable IBM mainframe, and in this post I describe how a pair can be used to emulate VAX computers which can then be configured to form a VMScluster.
The MicroVAX 3900 hardware being emulated this time is a little more modern and somewhat smaller than the IBM 4381 processor, but the VAX architecture and OpenVMS operating system are no less impressive. On introduction in 1989 an entry level MicroVAX 3900 would have set you back over $120,000 and, as with IBM's VM operating system, you'd be mistaken if you thought that OpenVMS was dead and buried as it runs many mission critical workloads today.
Emulation of the VAX hardware has been made possible by a pretty amazing piece of software called SimH. In order to be able to run OpenVMS on this a licence is required, but fortunately these are available free of charge via the OpenVMS Hobbyist programme.
The SimH software is configured to emulate a MicroVAX 3900 with 64Mb of memory, 1.5Gb disk and a CD-ROM drive. An ISO file containing an image of the OpenVMS installation media is attached to the virtual CD-ROM drive and the emulator is booted. The steps to install the software are reasonably simple and the image below shows part of the installation process.

For extra authenticity the above image shows a real DEC VT420 serial terminal wired up to the UART of Raspberry Pi #1 via a 3.3v-RS232 level converter. But for the sake of clarity the screenshots that follow have been captured via a Linux laptop connected to Rasberry Pi #2 via a a USB-serial adapter, a.k.a. “FTDI cable”.

In the above screenshot we can see OpenVMS starting up and the many operator communications or “OPCOM” messages that are displayed. Once system startup has completed we can then log in and use the “show system” command to get the equivalent of a “ps -aef” on Linux. Note that OpenVMS commands are not case sensitive and can be abbreviated.

With one system up and running we now need at least one more in order to form a cluster. Here we have a second Raspberry Pi attached via a network crossover cable and each board has been configured with a static IP address. Although in actual fact we won't be using TCP/IP at all, but it's useful to have this configured to test the Ethernet connection and to copy files across if required.

Once we've tested basic network connectivity the second SimH instance can be configured pretty much the same, albeit the emulated Ethernet card must be configured with a different MAC address. Obviously, when installing OpenVMS the system is given a different node name, and when installing the networking software a different DECnet address is used. To summarise, we have:
Machine Address
Raspberry Pi #1 192.168.1.1
Raspberry Pi #2 192.168.1.2
VAX1 (running on RP #1) 1.1 (a DECnet address)
VAX2 (running on RP #2) 1.2 (a DECnet address)
With both boards having booted Linux and the configured emulators having booted OpenVMS, we can then “set host” (the DECnet equivalent of telnet) from one emulated VAX to the other.

Note that as stated previously, Raspberry Pi #2 is connected to the laptop, and the above screenshot shows logging in from VAX2 to VAX1.
Now we are happy that the emulated VAXen (the plural of VAX!) can reach each other over the network the next step is to configure them into a cluster. This is as easy as running the cluster_config script on each VAX and answering a few basic questions, including the password that nodes must use when requesting to join the cluster.

When the first configured node has restarted we then configure the clustering software on the second, and upon that node restarting the first node will display messages indicating that it has requested to join the cluster. In this case VAX2 was configured first, followed by VAX1.

Now that we have a cluster configured with two nodes we can check their status with the command “show cluster”.

Introduced in 1983, the VMScluster software was way ahead of its time and compares favourably with its much more recent contemporaries. Allowing, for example, disks to be transparently shared across the cluster and multiple nodes to write to the same file at the same time (record level locking), load balancing and distributed queueing.
By using the “show devices d” command we can see all the disks available to the cluster, prefixed with the name of the node to which they are attached and a “$” separator. The DUA0: drives are the system disks, and DUA1: to DUA3: on each node are additional unused 1.5Gb drives.

Many other OpenVMS commands can be prefixed with “/cluster” to set a cluster-wide context. E.g. “show users/cluster”.

Finally, if we shut down one of the nodes it will be removed from the cluster.

In this case all processing on the remaining node has been frozen as a precautionary measure, as it could have just been that cluster communications were lost and a “split-brain” situation is generally undesirable. Although this two node cluster could easily be configured so that either node will continue if the other is lost or shut down.
Conclusion
This exercise was really just for fun and to see how easy it would be to create a VMScluster using VAX hardware emulated via Raspberry Pi boards. But it also serves to show how the Raspberry Pi can be combined with open source software such as SimH for use in computer conservation, and to provide museums etc. with the basis of a low cost demonstrator for classic computer architectures.
— Andrew Back

Image top: two Raspberry Pi boards sat atop a MicroVAX 3500 which uses the same cabinet as the model 3900 machines being emulated.

Link

I don't have Pi to play around with but I am sure I can VM some stuff and give it a try. But boy it looks fun.

RemadE

I'm quite intrigued by this little piece of hardware, as well as the Android model coming out (which possibly works on an open source platform, which is always nice).

I found this BBC report on how schools in the UK are having pilot schemes to introduce the Pi to IT lessons. Some of the responses are pretty stupid, but they are kids. The UK definitely needs a boost in the science and tech market/job department.