It has been a busy week this week with the biggest news being around a flightless bird!? Let’s get to it…
Hyperion OS Bugs
There have been a couple of bugs in Amiga OS 3.1.4 and 3.2 users should be aware of that have tripped up users (including me) a few times. These bugs are not unique to PiStorm, but they appear to have been more visible on PiStorm.
Kickstart 3.2 Black Screen
With Kickstart 3.2, if you have no floppy drives connected to the Amiga and no hard drive images the Amiga will boot to a black screen instead of an “insert disk” one. This can be confusing if you are testing your Amiga without the floppy drive. You will still be able to get into the boot menu by holding down the mouse buttons at power on.
Workbench Format Bug
On both Amiga OS 3.1.4 and 3.2, when trying to format a hard drive partition using Workbench’s built-in format tool / menu option it will likely crash the Amiga with a PiStorm. We don’t know exactly why but we do know that the trigger is having the default 128MB of Zorro III RAM. If you turn off the Zorro III RAM and turn on the 8MB Zorro II option, it seems to work.
Chip Speed Fast Path Compile Option
The small speed boost _Bnu added to the Chip RAM access, which I mentioned last week, is now a compile-time option which is disabled by default. To enable it now you need to do:
make clean && make ACFLAGS=-DCHIP_FASTPATH
Emu Coming To PiStorm
I’m not talking about Rod Hull’s bird (for UK readers). I’m talking about the Emu68 project. Michal Schulz is the developer of Emu68, a JIT based 68K emulator.
For those of you not familiar with a JIT (Just In-Time) emulator, here is a simple description of the difference. A regular emulator, such as the Musashi we use today, looks up each 68K instruction in a table and the runs a native routine to do the same function. A JIT emulator actually compiles in real-time the 68K code being executed into native ARM code. The upshot of this is that is generally much faster than a regular emulator, it can even be faster by an order of magnitude. But it needs to run on the Pi’s bare-metal instead of a Linux OS. The speed can also vary, whilst it is always likely faster, it is much faster the second time some code is executed.
It is extremely early days right now but Michal has been working on making Emu68 work with PiStorm. So far he has managed to get it to boot to DiagROM which is a fantastic start. It gets some of the way through a regular Kickstart boot sequence, but not all the way. At the moment he needs more hardware to test on, only having an Amiga 500 motherboard with the black & white composite output. So, several members of the community, including me, are donating some hardware to him.
To set expectations, I don’t expect this to replace Musashi soon. Features such as PiSCSI rely on the underlying Linux OS to function, which we don’t have with Emu68. That is not to say it is impossible, there are ideas on how to get the best of both worlds. But, the best chance of seeing this happening is to wander to Emu68 Patron page and sponsor it. You can also follow the progress in the “emu68” channel on the PiStorm Discord.
RTG DPMS Support
A few people have asked for the possibility to have RTG turn off its HDMI output when the regular Amiga RGB output is in use. So, earlier in the week I added the ability to do this. With the latest wip-crap if you add the following option, the HDMI RTG output will use DPMS (Display Power Management Signaling) to go to sleep when switching, and wake up when back in use:
This option is disabled by default as the developers actually need the monitor on during this phase for other things. With this option you will still see a blue “sleeping” screen when rebooting the Amiga, but other times you would normally see that screen the RTG is effectively completely turned off. In theory this should help some people with auto-switching HDMI boxes that are using an RGBtoHDMI and have a priority HDMI port.
GPIO Extension Cables
Occasionally we will get new users buying GPIO extension cables from Pi suppliers, or worse, trying to use IDE cables, to relocate the Pi for the PiStorm. This is normally fine for the low-bandwidth stuff the Pi is usually used for, but the PiStorm is sending data at 200MHz down the GPIO, this causes all sorts of timing issues, noise, reflections, etc.
The advice from the developers is to not try to do this at all, it might work for very short runs, but even then you can run into issues and it is definitely not supported. It is better to relocate the whole PiStorm, the CPU socket runs at a much lower speed with higher voltages and has more tolerance for such things.
Configuration File Management
When users run a
git pull to get the latest changes for PiStorm, they often hit a conflict because they have changed
default.cfg. In wip-crap this file has changed to
amiga.cfg for two reasons:
- PiStorm will eventually be multi-platform, with plans to support the Atari ST and 68K Apple Mac for example.
- If you do use
default.cfgthere will be no conflicts.
We actually recommend you keep your config files, ROM files and HDF files outside of the PiStorm directory on the Pi. For example my Pi’s home directory has “pistorm” for the software and then I created a directory next to it called “amigadata” for the configuration files, ROM files and my HDF files. Then for my main configuration file I run:
sudo ./emulator --config-file /home/pi/amigadata/linuxjedi.cfg
I also have configuration files in there to run DiagROM, boot OS 3.9, etc. This way I can pull the latest changes without configuration file conflicts.
The configuration file takes absolute paths for the ROM and HDF files so you can point to
/home/pi/amigadata/ (or whatever you choose to use) for them. You can even edit the systemd startup file, if you use it, to run the emulator with the
--config-file option as above (sudo won’t be needed inside that file).
Simo has created a video of surfing the ’99 net on a PiStorm: