Another PiStorm Blog

Blogs & guides and tales of woo by forum members.
User avatar
exxos
Site Admin
Site Admin
Posts: 24063
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Another PiStorm Blog

Post by exxos »

stephen_usher wrote: Sun May 12, 2024 12:01 pm There's a new Github branch of the code now: https://github.com/gotaproblem/pistorm- ... ee/may2024
Cool.

Might not get time this week to do anything again though. A lot going on in and out of Atari world.
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
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

I know what you mean. I've put this on the back burner this week as I'm finishing the preparations for the Portables exhibition event in Cambridge next weekend.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
Badwolf
Posts: 2280
Joined: Tue Nov 19, 2019 12:09 pm

Re: Another PiStorm Blog

Post by Badwolf »

stephen_usher wrote: Sat May 11, 2024 2:20 pm OK, implemented that change, though 0x1FFD is not correct, I'm using 0xFF00 as anything else fails to go get out of the loop.

The value of l is usually 0xd9xxxx6c or 0xd9xxxx7c. The xxxx values are usually 0x0000 but often 0xffff and sometimes other values such as 0x4001, 0x4081, 0x7fef or 0x5bef.
Hmm, I must be misremembering what gpio[13] returns as it looks like l is 32 bits and shifted right 8 at the end to get the status.

I was assuming I was masking the 16 bits being passed from the verilog.

My mask probably needs to apply to the shifted, truncated result rather than the native 32 bit l, in that case.

So perhaps something more like

Code: Select all

inline
uint16_t ps_read_status_reg () 
{
  static uint32_t l;
  static uint16_t status;

do {

  while ( gpio [13] & 1 );

  gpio [7] = 0x4C; //(REG_STATUS << PIN_A0) | (1 << PIN_RD);

  while ( gpio [13] & 1 );

  l = gpio [13];
  status = ( l >> 8 );

  gpio [10] = TXN_END;
  
}while ( (status & 0x1FFD) != 0 );

  return status;
}
?

But I'd still prefer to use the 'original' status getting code for starters.

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
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

The latest emulator code just checks for an invalid status, prints an error message and then ignores the status as a workaround.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

Some new firmware and emulator binaries turned up on Friday but due to other commitments I've only had a chance to test them today.

Well, on a positive note I can get to the TOS 1.04 desktop... But the emulation crashes as soon as I double click on a drive icon.

The new firmware doesn't seem to map local ROM images, so it's booting from the on-board ROMs. I also had to decrease the GPIO clock even further down to 68MHz. Any more or less than that made it totally unstable.

It feels to me that the first thing that needs sorting out is the communication between the CPLD and the Raspberry Pi. Unless this is rock solid you're trying to fight on multiple fronts and the project won't get anywhere.

I also wonder if the CPLD part fitted by the board manufacturer is genuine and not a rebadged slower part.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

Spent some more time with the PiStorm.

Back to relatively stock firmware and the May edition of the software.

I still can't get the GPIO clock above 70MHz stably, and even with that there's the odd glitch.

Seeing as I was having issues with WiFi wit the large CPU heatsink fitted I cut it down my half so it no-longer overhangs the WiFi module. That fixed the networking issue but also improved slightly the attainable maximum GPIO clock. However, I noted crashes of the virtual CPU seemed to correlate with bursts of WiFi traffic to/from the Pi. Putting a little aluminium foil over the GPIO connector between it and the WiFi module increased reliability a bit suggesting that RF from the WiFi module is having an effect upon the GPIO pins, possibly a harmonic of the 2.4GHz carrier or just induction.

I also re-implemented the test for a valid status register return into gpio/ps_protocol.c. Gone are the 'bad status' messages form the main emulation and the system is more stable. The TOS 1.04 now doesn't crash immediately if you click (once) upon a desktop icon but instead just fails to recognise further mouse (or ctrl-Ins) presses or mouse-over on the menus. GEM is probably triggering one of the CPU stati that the PiStorm isn't currently emulating.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
Steve
Posts: 2655
Joined: Fri Sep 15, 2017 11:49 am

Re: Another PiStorm Blog

Post by Steve »

That's very odd (the WiFi stuff) I haven't noticed anything like this. My WiFi is on & sharing the Atari hard disk over samba. So I can write to my Atari in real time and access the files inside the machine straight away, not experienced any crash when accessing the WiFi before.
User avatar
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

The main maintainer says that he has the PiStorm stable on his STe as well with a clock at around 90MHz. With the heatsink out of the way I can get the memory tests working at that speed but not the emulation, far too many random memory read errors.

I've no idea why the Exxos sourced PiStorm would be more sensitive than anyone else's. Then again another person in Germany on the Discord seems to be having similar issues with stability.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
stephen_usher
Posts: 5802
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Another PiStorm Blog

Post by stephen_usher »

I've been doing some experimentation today and here are the results:

Set-up:
Pi4 running at 1.8GHz. Exxos PiStorm. STFM with my relocator/CPU switcher/ROM switcher and decode.
EmuTOS 1.0 256K.

PiStorm configuration:
GPIO clock: 68MHz
Emulation: 68000/ST
Mapped ROMs/RAM: None.

Started with loopcycles at 1 and doubled each test.

Test software: YAART and then Fronbench if YAART stable.

Loopcount 1 - 16: Random corruption when running YAART. EmuTOS catching errors and returning to desktop.
Loopcount 32: System generally stable. Can run YAART without issue. Frontbench loads sometimes other times gives corruption. YAART errors out if Pi asked to do anything other in addition to the emulation.
Loopcount 64: As 32 but Frontbench loads every time and runs stably. Less sensitive to system usage.

By a loopcount of 256 the system is rock solid.

TOS 1.04 will boot to the desktop but as soon as any icon is clicked upon (once) the system locks or resets with two bombs. If I reject more CPU stati from the PiStorm then I can get TOS to stay alive but then no clicks are registered by GEM. Seems like the highlighting of an icon causes a CPU state that the PiStorm CPLD isn't yet emulating, or the CPU emulator doesn't know how to process.

On my system any GPIO clock slower than 68MHz and faster then 70MHz causes the system to be unstable. Bursts of WiFi traffic can also cause instability. Shielding the GPIO connector from the WiFi module can limit this slightly.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
Post Reply

Return to “MEMBER BLOGS”