PiStorm Chat

General discussions or ideas about hardware.
User avatar
alexh
Posts: 242
Joined: Tue Oct 17, 2017 4:51 pm
Location: Oxfordshire

Re: PiStorm Chat

Post 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?
Principal ASIC Engineer - SystemVerilog, VHDL
Thalion Webshrine - http://thalion.atari.org
STfm,STe,MegaSTe,Falcon060
A500+,A600,A4000/060,CD32,CDTV
Badwolf
Posts: 1316
Joined: Tue Nov 19, 2019 12:09 pm

Re: PiStorm Chat

Post by Badwolf »

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

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


BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
alexh
Posts: 242
Joined: Tue Oct 17, 2017 4:51 pm
Location: Oxfordshire

Re: PiStorm Chat

Post by alexh »

Woohoo.
Principal ASIC Engineer - SystemVerilog, VHDL
Thalion Webshrine - http://thalion.atari.org
STfm,STe,MegaSTe,Falcon060
A500+,A600,A4000/060,CD32,CDTV
User avatar
exxos
Site Admin
Site Admin
Posts: 18962
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: PiStorm Chat

Post by exxos »

:bravo:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Cyprian
Posts: 277
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: PiStorm Chat

Post by Cyprian »

Awesome
Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
Badwolf
Posts: 1316
Joined: Tue Nov 19, 2019 12:09 pm

Re: PiStorm Chat

Post 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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
Icky
Site Admin
Site Admin
Posts: 3551
Joined: Sun Sep 03, 2017 10:57 am
Location: UK

Re: PiStorm Chat

Post 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
Badwolf
Posts: 1316
Joined: Tue Nov 19, 2019 12:09 pm

Re: PiStorm Chat

Post 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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Steve
Posts: 2057
Joined: Fri Sep 15, 2017 11:49 am

Re: PiStorm Chat

Post 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.
User avatar
agranlund
Posts: 774
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: PiStorm Chat

Post by agranlund »

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

Return to “HARDWARE DISCUSSIONS”