PiStorm Chat

[alexh]

Awesome work. Well done. We're all very interested and watching with anticipation. Anything we can do, just bang your thoughts down and maybe we can inspire you?

* Slowed down the bus cycle. RAM access is very slow because of all those de-optimisations I've employed.

PiSTorm on the Amiga has/had RAM speed problems. I have wondered what the cause was. It is hard (even for me) to understand the challenges involved in recreating an 8MHz CPU pinout using a 1.4GHz CPU and GPIO rated to 70MHz. I imagine it becomes clear when you actually try to do it.

I don't think the RPi has enough GPIO to 1:1 map all 680x0 pins so PiSTorm doesn't emulate the I/O directly so instead sends packets which are encoded/decoded in the CPLD? Maybe they move some of the timing critical HW emulation to the CPLD to avoid latency?

[Badwolf]

You're letting the side down, there, ST-RAM...

IMG_5651.jpeg (208.91 KiB) Viewed 2669 times

IMG_5652.jpeg (100.57 KiB) Viewed 2669 times

BW

[alexh]

Woohoo.

[exxos]

[Cyprian]

Awesome

[Badwolf]

I don't think the RPi has enough GPIO to 1:1 map all 680x0 pins so PiSTorm doesn't emulate the I/O directly so instead sends packets which are encoded/decoded in the CPLD? Maybe they move some of the timing critical HW emulation to the CPLD to avoid latency?

On a basic level the way it works is to muliplex the 24 bit address and (in the case of writes) the 16 bit data across a single 16 bit bus. Then there are a (very!) few control lines.

That means there are two PI->CPLD writes for every read and three for every write.

The CPLD then starts a 68k bus cycle, presenting data on the A lines and either presenting or latching data on the D lines. It then reports back when it's complete. The data latching was off for the ST. It latched a couple of ns after DTACK rather than waiting one further 8MHz cycle, as per the spec.

BW

[Icky]

Very cool @Badwolf, and I see your FrontBench scores are similar to your Stock Falcon @60Hz VGA mode: ~1650 frames - viewtopic.php?f=50&t=5131

[Badwolf]

Thanks all.

There are, however, several huge issues still.

Firstly, Bus Error is not working properly.

Now, I don't know enough about Musashi nor actual exception handling to know what's going wrong, but whilst it'll correctly report an occasional bus error and follow the exception handler, if there are a few of them in a row, chaos ensues and the core gets stuck in some kind of bus error hell loop.

This is a big problem as no 'stock' OS will boot. My custom EmuTOS image has bus error detection disabled and everything is specifically coded. Any problems that then rely on detecting hardware with bus errors will be 50/50.


Secondly, reliability. Every now and again a bus error, or other issue will appear out of the blue. Sometimes it's really frequently, sometimes it'll run for half an hour. This feels like a breakdown in the protocol and the bursty nature of the failures has the smell of a beating issue when you have two independent clocks. Probably the lowest priority issue ATM, but certainly a biggie when its turn comes around.


Thirdly, there's something amiss with sound. No music from Frontier, one of the other games I tried out crashed around the start of the music and the diagnostic cartridge fails with testing exceptions on the screen, but with a low tone stuck on the audio out. This could very well be an indirect Bus Error issue. If the YM chip were properly detected and set up maybe it would work? Not sure. Don't think it's the now infamous YM chip DTACK issue as this is being tested on an STE.


Fourthly, the ST-RAM speed. I've not got to the bottom of this yet as it's also fairly low down the food chain. I'm not 100% sure I like the state machine model used in the firmware and hacking that might improve things, but my gut feeling is that this is a time-between-bus-cycles issue rather than a bus-cycle-length issue. This manifests most obviously in Frontier where, despite the frame count looking good when I run it from AltRAM, the screen flickers like mad as the palette switching code does its thing.


Anyone who can proffer something on the Musashi code for handling bus errors please tap me up as this is the biggest hurdle to progress ATM.

BW

[Steve]

@Badwolf I ordered a Pistorm today (& a cool ribbon-cable 68k relocator) today, so I'll be able to help with testing soon.

[agranlund]

Does Musashi emulate an MMU?
68040, 30 or perhaps 20 paired with a 68851?