Unfortunately life took over in the last few months and I haven’t been able to keep up with the speed of changes of PiStorm to relay them to you in a weekly format. I have, however, been playing with Emu68 on PiStorm over Christmas. It is a project that has come a long way so I figured I should explain what it is and what is new in it.
PiStorm is a combination of hardware and software. The stock software is based on the Musashi 68000 emulator with a bunch of enhancements to add RTG graphics, virtual SCSI support, etc… Then one day along came the Emu68 project which could replace Musashi on PiStorm.
Emu68 is the brainchild of Michal Schulz and works a little differently. A table of differences is below:
| Musashi | Emu68 | |
|---|---|---|
| Emulator Type | Interpretation | Just-In-Time (JIT) |
| OS Layer | Linux | Bare Metal |
| Speed | Fast | Lightning |
| Features | RTG, virtual SCSI (file based), networking, file transfer, Fast RAM, ROM files, CLI and GUI dynamic configuration | RTG, virtual SCSI (partition based), Fast RAM, ROM files |
Key things here are the first two. An interpreter based emulator will look at the 68000 instruction, figure out what the equivalent native instructions are, usually using large look-up tables, and will execute those. A JIT based will compile in real-time the 68000 code into native code to be executed, caching the compilation units as needed. In general JIT based emulators are typically a lot faster.
Emu68 is relatively simple to install as it doesn’t use an operating system, it instead is a “bare metal” application that runs directly on the Pi. This gives it full control of the Pi and also helps improve the performance. Instructions on how to set up Emu68 for PiStorm can be found here. This geared towards Windows users, but the equivalent in macOS and Linux is not too difficult to do.
There are also instructions available to enable to new RTG graphics. I recommend using Aminet’s P96 software for this as the Individual Computers version was not working for me with Emu68 and Amiga OS 3.2.1.
Just how fast is it? The first screenshot is Emu68 (release builds, debug builds are roughly 1/4 speed), the second is Musashi.
Emu68 defaults to 68040 and my Musashi setup is using 68020, but this doesn’t really matter as both will emulate at the fastest speed possible. It only makes a difference for the additional instructions of the CPU.
Also, below is ADoom running using the Amiga’s own OCS graphics hardware, for comparison I’d expect about 9FPS peak from Musashi:
There are still bugs in Emu68 and if you are looking for cycle accuracy, you probably won’t get that from a JIT based emulator. It is also more difficult to add features that interface to hardware because bare metal drivers need to be written for the hardware. The virtual SCSI and RTG graphics are relatively new, and networking is likely a long way off.
But this is an incredibly fast CPU emulator and now the default in my PiStorm system. If you want a fast cheap CPU accelerator for your Amiga whilst retaining the original hardware, this may be what you are looking for.
Four months ago, Emu68 wouldn’t even boot Kickstart properly on PiStorm. There has been incredible progress by Michal and a group of volunteers since then to make it possible for this to be a daily-driver CPU. I am a Patreon of this project and I have donated an RGBtoHDMI board to Michal to help his efforts. Every little contribution helps this project, whether it be financial, testing, bug reporting, etc… So anyone with a PiStorm can help.
My hardware test setup for this blog post can be seen below, an Amiga 500 Plus with a PiStorm and a prototype RGBtoHDMI, left monitor is RTG and right monitor is Amiga’s RGB.
I recently acquired an Amiga 1200 motherboard in a spares/repairs condition for about £100 recently.…
Whilst I do like working with STM32 development boards, some basic information I need can…
When I last left this blog series, the first of Stoo Cambridge's A4000s had gone…
At the beginning of November, I started working for wolfSSL. Now that I'm a week…
In my previous post, I had the Amiga 4000 known as Jools mostly repaired, there…
In my last post, I created a list of things I needed to repair on…
View Comments
Hi and thanks for the intro to PiStorm! Your links to Michal's instructions return an 404 error. Has the URL changed, or was it taken down completely?
Thanks for pointing that out. It seems the links have changed since I wrote this post. I have updated them accordingly.
Thanks for updating the links! I'm thinking of seting a new Pistorm SD with Emu68 since i already have the "default" one working. My only concern was having to flash the CPLD again if necessary. But i was told i don't have to.
It is very rare that you need to flash the CPLD. Both Emu68 and the stock PiStorm software rely on the same firmware. The production firmware hasn't been updated in a long time. The experimental one occasionally changes but is known to be incompatible with some hardware. We don't anticipate a major firmware change until proto 4, which will likely be after PiStorm 32 is released (so we are talking probably months away).
Thanks a lot for this blog, I don’t know how anyone can do all this on top of a full-time job. Even sporadic updates are really helpful for us following the project in our spare time. I’m sure this is covered elsewhere but I’m curious whether there are plans to update the CPLD firmware for bus arbitration as I’m guessing this would improve compatibility with peripherals in big box Amigas – I’m selfishly thinking of the onboard SCSI on my Phoenix board here.
Thanks 🙂
There are definitely plans for this, I was working on it a while back but life got in the way. It would need a few weeks of someone's time to develop it and will likely come after the PiStorm32 has been released.
Emu68 feels slightly over-ambitious, as opposed to wedging in a JIT 68k emulator as a switchable CPU (Musashi vs. UAE-JIT engine, for example). The benefit of wedging a JIT engine on there is that writing driver shims / interop between the host OS (Linux) and the guest OS (Amiga) is much easier than developing everything from scratch into Emu68?
Another odd benefit of above approach is the ability to run things from host OS side and “mirror” them into the guest OS, like running Chrome or bash shell directly from the RPI side but navigating/interacting with them via the Amiga Desktop…
Are you aware of an effort to replace Musashi with a different CPU emulation engine, as opposed to going the Emu68k route?
Cheers,
Brian
I believe there is a current dual-boot method of Musashi on Linux and Emu68 on bare metal. But I don't know the details of this, I just switch the SD card when I need to switch.
There was a small attempt at switching to something else well over a year ago (I think qemu?). But there wasn't much interest in it.
didn't mean dual-booting between Musashi and Emu68. Meant more having a switchable 68k engine - Musashi+UAEJIT for example. No Emu68 in my equation, due to the other points I mentioned.
But if everything is kinda migrating to Emu68, maybe the above Musashi path is going to slowly get deprecated
Yes, I know. I'm not saying it isn't possible, just that no one has wanted to put in the effort to implement it.
Emu68 didn't start out as a PiStorm project, it was a pet project to begin with so that the author could learn bare metal Pi and JITs. It just happened to be a really good fit for PiStorm so gravitated towards it over time.
You are more than welcome to develop a switchable engine. We encourage new developers to join in.
is there a way to delete the unintended duplicate post?
Thought I'd chime in to say working alright on a Pi 3A+, though they didn't load Workbench etc to the SD, so can't get RTG going just yet.. And it isn't happy with the Pi 4B of course, though i did get nearly 7Kmips lol also chiming in to say its actually booting my CF card fine through a FastIDE adapter w/Kickstart 3.1 ROMs and drivers installed, was also able to play Alien Breed 1/2 at a ridiculous frame rate for an Amiga. Almost like running WinUAE but on the Pi but on a real Amiga.. Gotta love FPGAs and assembly code! Back when i was writing it and started with PCs, it was over 4x faster than the same job in C, nice to hear its gone up!
Things have improved in the 18 months since I wrote this post, and it sounds like you are using an Amiga 1200? The PiStorm32-Lite didn't exist back then, things are even faster still :)