The Emu and the Storm

For my previous post regarding the PiStorm I used the standard firmware, which is based on the Raspberry Pi's Linux distribution. The downside of this is that the Linux kernel takes processing power from the PiStorm's 680x0 emulator software and also adds a varying amount of latency to the signals placed on the Amiga's data and address buses.

Not using the Linux distribution at all means that the emulation software will get full control over the timing of the signals on the Raspberry Pi's GPIO pins and will also get 100% of the processing time of all CPU cores. It of course also means that the Linux kernel is no longer present to perform all the other tasks (like networking and file access) that came with it.

For Michal Schulz the possible gains in speed were interesting enough to create a bare-metal version of the PiStorm firmware, known as 'Emu68'. In this post I will have a look at this firmware and compare it with the "standard" PiStorm firmware as well as with my trusty A1200 and its GVP 68030/50 accelerator.

The hardware

For this test I use the same Amiga 500, PiStorm, LazarusStorm and Raspberry Pi Zero 2W as I used for my PiStorm post. Having the PiStorm external thanks to the LazarusStorm makes trying out new firmware really easy - as easy as swapping the uSD card of the Raspberry Pi! Please check out the PiStorm post for more information on the hardware used.

The software

Michal has created a step-by-step guide on how to setup the uSD card for the Raspberry Pi. The uSD card gets two partitions, one for the Pi to boot from and one for the Amiga to use as its hard drive. The boot partition will contain a file named "cmdline.txt" which is used to configure the Emu68 firmware. More information on the contents of this file and its possible options can be found on the Configuring Emu68 page.

At the time of writing the Emu68 software is still in beta. I have been using the 'Nightly' build from the 5th of September 2022 for everything described in this post.

The CPU

The emulated CPU in this case is a 68040. This also includes emulation of the FPU. The MMU (Memory Management Unit) of the 68040 is not emulated, which is not a problem for the Amiga's operating system as most of the stock Amiga systems had no MMU.

Below is a screenshot from SysInfo showing information on the Amiga 500/Emu68 system. With the Emu68 firmware the system is considerably faster than with the PiStorm firmware. Actually, Emu68 is considerably faster than any Amiga I have used before.

I do like the "Virtual Amiga?" comment, which of course is not far of the mark. The CPU in this Amiga 500 is indeed emulated, even if the rest of the system is not. One speed did decrease, the Chip RAM speed, which is 0.96 for Emu68, but 1.00 for the standard PiStorm firmware. This is not something I expect to notice using the system.

The following table will show some speed results using the same version of SysInfo on a couple of different systems. The Amiga 1200 has a GVP A1230 accelerator featuring a 68030 CPU and a 68882 FPU, both running at 50 MHz.

	Dhrystones	Mips / MFlops	Chip speed vs A600
A500 (no fast RAM)	538	0.56 / N/A	1.02
A1200+A1230/50	7158	7.7 / 1.37	1.98
PiStorm (A500)	16267	16.99 / 7.62	1.00
Emu68 (A500)	605292	631.84 / 583.32	0.96

Later on in this post I will report on some more speed comparisons.

Fast RAM

The Emu68 software will use some of the RAM of the Raspberry Pi but whatever is left will be made available to the Amiga as fast RAM. With the Raspberry Pi Zero 2 the Workbench reports roughly 356MB of free fast ram.

Kickstart ROM

The Amiga's Kickstart ROM can be mapped into fast RAM. Accessing the physical ROM inside the Amiga will be very slow for the emulated CPU compared to accessing a mapped ROM image in fast RAM. Fast RAM is the Pi's own RAM and therefore the Pi can access it at its full native speed. The Kickstart image that is loaded into RAM needs to be provided as a file on the boot partition on the uSD card. Unlike the standard PiStorm firmware, this does not need to be a byte-swapped file. The same file as you may be using for WinUAE emulation will work fine with Emu68. If the file does not exist then Emu68 will fall back on to the physical ROM that is installed in the Amiga. I've once again opted for the KS3.1 image I made from my 1200 a couple of years ago.

Hard disk

When the system has been setup using the step-by-step guide Emu68 will provide two SCSI hard disk devices to the Amiga. Device 0 will give read-only access to the complete uSD card, where device 1 will give full access to the 2nd partition only. For most users device 1 access is all they need as it can be used by HDToolBox (the AmigaOS disk partition tool) to create partitions and filesystems that the Amiga can use.

Booting from this emulated SCSI hard disk is fast. This did not surprise me since the Pi is simply accessing a partition on its own uSD card. Booting is really done in the blink of an eye! I did have a couple of instances where the Amiga seemed to hang before booting, but each time this happened I could fix this by issuing a reset via the keyboard.

RTG

Just like the standard PiStorm firmware, the Emu68 emulates the presence of an RTG compatible graphical card and uses the display output of the Raspberry Pi as the output of this emulated RTG card.

Network

There is unfortunately currently no network access available with the Emu68 firmware. Since there is no underlying Linux system everything needs to be part of the emulator software itself. Michal has been working on getting WiFi functionality implemented, but it is not a small job and he has hit a couple of snags, mainly related to poor or unavailable information on the inner workings of the different WiFi chipsets used by the various Raspberry Pi boards.

At the time writing Michal is showing off PiStorm32 development progress on his Patreon page and YouTube channel. This likely means that the Emu68 WiFi development has been put on hold for the moment. Personally I'm rather keen on having a PiStorm solution for my 1200 (which is what the PiStorm32 is) so I'm not at all disappointed if PiStorm32 takes a higher priority than WiFi..

Using the Emu68

While using the Emu68 system another benefit of not using an underlying Linux system came to light; no need to boot or shutdown the Linux system. Since Emu68 is running natively (bare-metal) on the Raspberry Pi a few files is all the Pi needs to read to be ready to boot the Amiga. And when it is time to switch off the Amiga you can do just that - no need to wait for the Raspberry Pi's OS to shutdown safely. Of course it is important to not power off the Amiga too quick after a write to its emulated hard drive, but this is true for any Amiga with a hard drive, including the ones with an internal 'spinning rust' based storage medium.

Since there is no network and the Amiga 500 lacks the handy PCMCIA port of the 1200 I've mainly been using floppies for file transfer and installation of Workbench 3.0. For these situations I also have a floppy with the Amiga Explorer program and a fast serial port device so I can also transfer larger files that don't easily fit on a floppy disk with my PC over a serial null modem cable.

Even though the Emu68 project is still in beta, I have not found any great compatibility issues while using it. Of course I've only used it for a couple of weeks, but nothing I've used so far has given me any problems. But this may be depending on your actual use case. Speaking of which, I've done a couple of additional tests to see how fast Emu68 is compared to other systems. This I've done with a benchmark program (AIBB) and with a fractal image generator (MandelSquare) of which the results follow in the next two sections...

AIBB

The "Amiga Intuition Based Benchmarks" program, or AIBB for short, can run a number of benchmarks and create a "module" of the results. These modules can be saved to disk so that at a later date they can be used within the program for comparison. For comparison the program provides four module slots and for the slots that are not used the program will use built-in modules of stock Amiga systems.

AIBB provides a variety of benchmarks. Some of them test the graphical speed of the system by drawing lines (LineTest) or ellipses (EllipseTest). Others test the speed of raytracing (BeachBall and FTrace) or of the system overall (like InstTest, Flops and Memtest). The program aims to create a comprehensive set of benchmarks that each tries to mimic a real-world use case.

For my tests I used the PiStorm firmware to create a module and saved it to a floppy. Then I switched over to the Emu68 firmware and did exactly the same thing. On the 1200 I then ran the AIBB benchmarks and used the PiStorm and Emu68 modules for comparison. I left two of the module slots empty so that AIBB's default modules for the A600-NF (no fast RAM) and the A4000-40 (25MHz 68040) were used as well. The results of the Amiga 1200 benchmarks are shown in the column named "You".

Below are the results of the "BeachBall" test (left) and the FTrace test (right). Both these benchmarks test the system's performance when raytracing graphics. The Beachball test does this by actually reytracing a beach ball, where the FTrace test performs a loop of the type of calculations required for raytracing. In both cases the faster the system performs the benchmark, the more suitable the system is for raytracing.

On most benchmarks Emu68 outperforms the other systems by a large margin, similar to the results shown in the above screenshots. However, this is not always the case as the screenshot of the TGTest (below on the left) shows. The TGTest draws text to graphics memory, which in the case of the A500 is 16 bits wide. The A4000 has 32 bits memory, which is why that system runs this benchmark faster than the PiStorm and Emu68. The A1200 also has 32 bits memory but is running Kickstart 3.2 and not 3.0/3.1 like the other systems. When I replace the 3.2 ROM in my A1200 with the original 3.0 ROM the 1200 is on par with the A4000-40 for this benchmark.

The below right image shows the result of the MemTest benchmark, which copies blocks of data around in memory. This gives a good indication of the base potential of a system - if the CPU can't access memory very fast then it won't be able to read its instructions very fast and as a result the whole system will feel sluggish. Unsurprisingly Emu68 trumps everything else, by a considerable margin.

MandelSquare

I've always had an interest in the pretty pictures generated with fractals. It started for me with a slow running BASIC program that calculated images from the Mandelbrot set on the Commodore 64. MandelSquare is a similar program for the Amiga, but using a much more efficient algorithm. MandelSquare requires an FPU to be installed, so won't run on most stock Amiga systems like the stock 500.

For my tests I enabled "Precise calculations" and then selected the required number of colours. As the last step I selected the display mode as "Highres Laced", which then immediately started the calculation of the first image. This ensured that the same image was always calculated for each setup. At the end of the image calculation MandelSquare will helpfully show how long it took to calculate that image.

I've generated a number of images with different colour depths and noted the amount of time it took for each image in the table below. The number of colours has a fairly linear impact on the time it takes to calculate an image. I did not run the 16384 colours image calculation on the A1200 or the PiStorm, but expect they would have taken about 34 minutes and 12 minutes respectively.

	4096	8192	16384
A1200+A1230/50	8:39	17:04
PiStorm (A500)	3:05	6:05
Emu68 (A500)	0:04	0:08	0:15

Of course I can't help myself and just had to include two images. The one on the left is the image that I used for each of the timed runs, the one on the right was created by using MandelSquare to zoom in and recalculate the image from the new position.

Conclusions

When I compare the Emu68 firmware with the standard PiStorm firmware then I see the following improvements:

• Emu68 is considerably faster than the standard PiStorm.
• No Linux distro running on the Pi, which means no time lost for booting or safely shutting down and no need to keep the Linux system patched and updated.
• More memory available for fast RAM. Although this is a slightly moot point since the normal PiStorm firmware already provides a humongous amount of RAM.

However, there are also things that are available on the PiStorm firmware and that I do miss on the Emu68 firmware:

• No network access for the Amiga.
• No other method for easy transfer of large files like a shared folder.
• The Amiga hard disk image is not accessible as single file for backup.

Initially I thought that not having network support was not a big issue, since I rarely use the network on my 1200. But then I realised that I do quite often use a CF card to transfer files between the PC and the 1200, something I can't do on the 500. In any case, while using the Emu68 system I realised why Michal Shultz has been working on WiFi support. It will add a lot of functionality and quality of use to the Emu68 system as a whole.

On the PiStorm firmware it is possible to stop the emulation and copy/swap the files that make up the Amiga's hard disk images. This way it is simple to make a quick backup copy of the hard disk image which can be used to roll back unwanted changes. The only way to do this with Emu68 is to create a backup of the complete uSD card.

Now that I have seen the raw speed that Emu68 gives to an Amiga I really hope that the PiStorm32 board that Claude Schwarz is working on will be available for purchase rather soon (fed up with this component shortage!) so that I can use it on my Amiga 1200. For the 1200 Emu68 won't need any WiFi support as long as the PCMCIA port of the 1200 works. That allows the use of a PCMCIA network card, or a CF card for old fashioned file transfer.

These are interesting times for old Amiga hackers like me..