PiStorm Chat

[PhilC]

@PhilC Somewhere along the lines, the program that flashes the pistorm changed (or a part of it changed) People have hit this snag numerous times in Discord and have managed to work around it. But sorry I don't remember off the top of my head the details. There is an #atari channel in the official Pistorm discord if you feel like joining (it's probably the only place to find support)

I don't currently have discord on my phone. I deleted it as I found it difficult and annoying to use.

I'll park it for now till it's a little more further along.

[Steve]

I just log-in on my web browser, don't use an app.. but yeah that's where all the development & support happens.

[Darklord]

I...haven't seen much activity there in months.

(looks like October 27th, 2025 was the last post)

[ijor]

I'm not familiar with the PiStorm at all, but there are many things here that don't make much sense to me.

In first place, why use an obsolete MAX II CPLD??? The only reason you usually use a very old CPLD is because it is 5V tolerant. But this one is not. So I don't understand what is the point. You could use a faster and much more powerful MAX 10 for about the same price. Don't know, may I be I miss something.

Some quotes from the other thread, that I thought better to follow up here.

It was suggested to me that Musashi was not the best route for PiStrom on my Amigas, and I can't imagine it would be any better on the ST PiStorm.
Bare metal is definitely the way to go but in all honesty if there is no bare metal option for the ST it might be a bit of a bust.

Not sure I agree with that approach. As I see it, the whole point of using an RPI is to have all the power of full Linux. Ethernet, Wifi, Bluetooth, full Internet, Storage, HDMI ... You name it, everything is built-in.

Not using bare metal would obviously imply a "small" performance hit. But there are methods to make it almost as fast. Granted, I'm not an RPI expert, so I can't say I have tested this.

With some ST chipsets it's sort of working some of the time but a lot of the arbitration states are not fully implemented or not implemented at all. It seems to be hitting timing latency issues.

The PiStorm only really works well on the Amiga because the CPU doesn't have to worry about bus arbitration as all the peripherals are hidden behind the custom chips, and it's the bus arbitration which is the hard and time critical bit.

I can only assume you are using the term "bus arbitration" in an "unusual" sense. Because otherwise this doesn't make much sense to me. Bus arbitration, in an 68K context, means DMA as used by Blitter, or when accessing the floppy or hard disk. I don't think this is very complicated, and certainly it is not time critical. E.g., nothing will happen if the CPU grants the bus a few cycles later. It might break a couple of Blitter demos that require cycle accuracy. But the CPU emulator is not cycle exact anyway, so this is a non-issue.

Again, I'm not familiar with the PiStorm at all, so I might be missing some important details.

[peters]

I gather that the Amiga emu68 pistorm is many many times faster than the musashi one. Like 50-100 times faster.

Musashi is the easier route but ran into issues on the ST. Some people got it working on the STE.

[rubber_jonnie]

It was suggested to me that Musashi was not the best route for PiStrom on my Amigas, and I can't imagine it would be any better on the ST PiStorm.
Bare metal is definitely the way to go but in all honesty if there is no bare metal option for the ST it might be a bit of a bust.

Not sure I agree with that approach. As I see it, the whole point of using an RPI is to have all the power of full Linux. Ethernet, Wifi, Bluetooth, full Internet, Storage, HDMI ... You name it, everything is built-in.

The idea of PiStorm, at least as I see it, is not to turn an Amiga into a Linux machine, but to use an RPi to emulate a CPU, FPU, disks, add RAM and Wifi etc so that you end up with a boosted Amiga.

My understanding of Musashi is that it's a Linux base inside which all of the above runs, so it is very much more difficult to run and requires a lot of configuration plus has the overhead of the Linux system on the Pi doing any translations between the Amiga and the Pi, all of which means more effort for the Pi which affects performance.

On the other hand, EMU68 is a bare metal system that just appears as all of the above, just as though you'd plugged in a real accelerator, but with a significant amount of the Linux overhead removed between it and the Amiga with no configuration required. My A500 with PiStorm, Emu68 and Caffeine OS just reports like this:

IMG20260105143609.jpg (365.27 KiB) Viewed 111 times

All I did was write the SD card and install it in the Pi.

And it runs brilliantly and includes a whole heap of software in the image, Caffeine OS included. You write the image plug it and go, but with Musashi you have to build the image, configure the CPU etc etc and then make any other changes you need and then it might work.

I've PiStormed my A1200 and A500 with Emu68 over the last few months and it is super easy. I'll take that anyday.

[peters]

I don't think anyone has tried emu68 in an ST, I doubt it would work.

Thats the feeling I'm getting.

[Steve]

I don't think anyone has tried emu68 in an ST, I doubt it would work.

Thats the feeling I'm getting.

Not just a feeling, a guarantee. Emu68 doesn't handle all the 68K signals that Atari and Mac require.

[Steve]

In first place, why use an obsolete MAX II CPLD??? The only reason you usually use a very old CPLD is because it is 5V tolerant. But this one is not. So I don't understand what is the point. You could use a faster and much more powerful MAX 10 for about the same price. Don't know, may I be I miss something.

The PiStorm started out a few years ago, so the original versions CPLD has become rather old now. But later models of PiStorm already updated this, for instance the Pistorm32-lite uses a Efinix Trion T8Q144 FPGA. There are also other variants and newer developments since.

Not sure I agree with that approach. As I see it, the whole point of using an RPI is to have all the power of full Linux. Ethernet, Wifi, Bluetooth, full Internet, Storage, HDMI ... You name it, everything is built-in. Not using bare metal would obviously imply a "small" performance hit. But there are methods to make it almost as fast. Granted, I'm not an RPI expert, so I can't say I have tested this.

Perhaps it's just the inefficiency of the Musashi emulator, but emu68 is significantly faster and more accurate. Sure, using Linux has the added advantage that it's fairly straight-forward to pass-through devices like Ethernet, Wifi etc transparently, but Emu68 already has functionality built in for retargetable graphics, ethernet and wifi. Because Emu68 is bare-metal these extra devices appear to the Amiga/Atari as 68K peripherals/devices much like a real device would be presented, which is preferable. Another advantage of Emu68 is almost instantaneous startup time (so the 'CPU' comes online straight away with starting the computer) Where Musashi has to wait for the Linux OS to start, which takes away from the authentic feeling. Also Musashi is no longer developed, Emu68 is actively developed.

I can only assume you are using the term "bus arbitration" in an "unusual" sense. Because otherwise this doesn't make much sense to me. Bus arbitration, in an 68K context, means DMA as used by Blitter, or when accessing the floppy or hard disk. I don't think this is very complicated, and certainly it is not time critical. E.g., nothing will happen if the CPU grants the bus a few cycles later. It might break a couple of Blitter demos that require cycle accuracy. But the CPU emulator is not cycle exact anyway, so this is a non-issue. Again, I'm not familiar with the PiStorm at all, so I might be missing some important details.

Arbitration/error handling: For the Atari ST (and Amiga CDTV), compatibility isn't there yet because essential signals like bus arbitration, bus error, and processor state pins are not yet correctly driven. Perhaps you're the perfect kind of person for Michael (lead developer of Emu68) to have a conversation with around these kinds of topics.

[Darklord]

I would love to see more of the Atari guru crowd get involved with the PiSTorm scene.

They've been asking for more help over in the Discord channel for a very long time.

Just not enough dedicated, talented people working on it at the moment. The ones
who have been are brilliant but they just need more help.

I think they were looking specifically for someone with a good knowledge of verilog
programming (IIRC).