Another PiStorm Blog

Blogs & guides and tales of woo by forum members.
User avatar
Badwolf
Posts: 2280
Joined: Tue Nov 19, 2019 12:09 pm

Re: Another PiStorm Blog

Post by Badwolf »

exxos wrote: Fri May 10, 2024 12:02 pm But anyway, I do tend to agree that the PI CPU should be clocked right down to effectively something more realistic like below 20Mhz for testing and debugging. There are simply too many things which can go wrong.
It's the state machine and the PiStorm protocol that's been optmised to death, not the CPU speed, which is obviously a very hand-wavy concept as it's just a software emulator and some things will take longer than others.

My suggestion was to, for example, double the amount of time it takes to do status checks, use a full 8-S-state state machine instead of the bare minimum we have now. Try to make it stable with everyone before looking to get the ST RAM speed back up.

When I refer to speed I'm talking about hitting the four 8MHz clock cycle gate for the next ST RAM access.

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
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: Fri May 10, 2024 1:23 pm The CPU emulator is seeing "Bad status" values (0xFFFF) from the CPLD and then it determines that it has to restart the emulation from scratch,
What conditions could generate that "bad status" then ?
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 think it's the state machine that's the real problem here as it's getting majorly confused which is then causing the CPU emulation to throw the toys out of the pram. Without this I don't think that it will ever be stable.
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: Fri May 10, 2024 1:23 pm It's not time dependent, so it's not a warming issue.

The CPU emulator is seeing "Bad status" values (0xFFFF) from the CPLD and then it determines that it has to restart the emulation from scratch, which resets the machine. The amount of these errors changes with each OS, with 2.06 being the version which triggers this the least. 1.04 doesn't get to the desktop before the emulation resets and EmuTOS can get to the desktop but then will soon cause a reset.
I'm fairly confident these are Pi<-->PiStorm protocol issues. That's where I believe all the timing tweaks are having an effect. Last time I looked these status returns are single clock cycle synchronous. That's asking a lot at the best of times.

I did some work where I 'checksummed' these status calls. I think only four of the 16 bits are used, or somethign like that, so I inverted them and repeated them. The software side could then detect erroneous calls and redo them. It worked for me. We moved away from that in the end and other changes supplanted that, but deep down I think that's where most of the problems come from.

I don't think it's the 68k state machine that's the problem as it doesn't overlap with the status return and the status return should never ever be FFFF => https://github.com/gotaproblem/pistorm- ... 240.v#L137 (there should always be at least twelve bits set to zero).

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 number and timing of the "Bad status" messages seem to be similar after every restart of the emulation, suggesting a possible determinism to them. There's a definite sweet spot on the GPIO clock too.

Anyway, with none of the main developers being able to work on this due to other life issues I'm not sure we'll see much if any progress in the foreseeable future.

With the status returns, I wonder if there's a pin free on the GPIO to use as an acknowledge signal. Then again that would mean that the CPLD would possibly miss bus stuff if it waits and I guess there's no latch which could be used.
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: Fri May 10, 2024 1:41 pm The number and timing of the "Bad status" messages seem to be similar after every restart of the emulation, suggesting a possible determinism to them. There's a definite sweet spot on the GPIO clock too.

Anyway, with none of the main developers being able to work on this due to other life issues I'm not sure we'll see much if any progress in the foreseeable future.

With the status returns, I wonder if there's a pin free on the GPIO to use as an acknowledge signal. Then again that would mean that the CPLD would possibly miss bus stuff if it waits and I guess there's no latch which could be used.
The GPIO clock being the key thing to me. I think we're just trying to go too fast with the protocol and tweaking this to 'work' on each particular board/interface/cpld combination.

Compare the current speed hyper-optimised version of ps_read_status_reg()

https://github.com/gotaproblem/pistorm- ... col.c#L621

with the original, intentionally slow and loopy one:

https://github.com/dh219/pistorm/blob/w ... col.c#L293


I suppose you could try just dropping the old function code into the new source and building away?

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 »

I may just do that when I get home. Thanks.
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: Fri May 10, 2024 1:55 pm I may just do that when I get home. Thanks.
NB. I'm not sure that the new protocol still has the same 'transaction in progress' definitions for this so it may fall flat on its face, but I'll be interested to know how you go.

The other easy thing you could try would be to look for those 12 zeros and if you don't get them re-run the status call.

Something like

Code: Select all

inline
uint16_t ps_read_status_reg () 
{
  static uint32_t l;

do {

  while ( gpio [13] & 1 );

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

  while ( gpio [13] & 1 );

  l = gpio [13];

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

  return (l >> 8);
}
This is effectively an extremely dumbed down version of my status check without any hardware-side changes.

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 »

I may try that first. After all if those zeros aren't zero there's no point returning the value.
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 »

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.

If I loop on anything in that central part being not 0xffff I get a lot of crashes. If I only accept 0x0000 then the system is more stable than it was. e.g. I can get to the TOS 1.04 desktop, but if I try to open a folder then the machine reboots. EmuTOS will get to the desktop and not fall over immediately.

P.S. I can get Frontbench to run under EmuTOS (after a couple of tries) now. Only running out of ST-RAM using the 68000, crashes every time with the 68020.
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”