Page 5 of 25

Re: PiStorm Chat

Posted: Wed Jul 06, 2022 8:44 am
by 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?
Badwolf wrote: Tue Jul 05, 2022 11:10 pm * 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?

Re: PiStorm Chat

Posted: Thu Jul 07, 2022 11:00 pm
by Badwolf
You're letting the side down, there, ST-RAM...

IMG_5651.jpeg
IMG_5651.jpeg (208.91 KiB) Viewed 1920 times
IMG_5652.jpeg
IMG_5652.jpeg (100.57 KiB) Viewed 1920 times


BW

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 12:48 am
by alexh
Woohoo.

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 1:13 am
by exxos
:bravo:

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 8:51 am
by Cyprian
Awesome

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 10:44 am
by Badwolf
alexh wrote: Wed Jul 06, 2022 8:44 am 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

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 11:07 am
by 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

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 11:39 am
by 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

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 6:03 pm
by Steve
@Badwolf I ordered a Pistorm today (& a cool ribbon-cable 68k relocator) today, so I'll be able to help with testing soon.

Re: PiStorm Chat

Posted: Fri Jul 08, 2022 6:11 pm
by agranlund
Does Musashi emulate an MMU?
68040, 30 or perhaps 20 paired with a 68851?
:)