Page 6 of 10
Re: Another PiStorm Blog
Posted: 10 May 2024 13:27
by Badwolf
exxos wrote: 10 May 2024 12:02
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
Re: Another PiStorm Blog
Posted: 10 May 2024 13:28
by exxos
stephen_usher wrote: 10 May 2024 13:23
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 ?
Re: Another PiStorm Blog
Posted: 10 May 2024 13:30
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.
Re: Another PiStorm Blog
Posted: 10 May 2024 13:36
by Badwolf
stephen_usher wrote: 10 May 2024 13:23
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
Re: Another PiStorm Blog
Posted: 10 May 2024 13:41
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.
Re: Another PiStorm Blog
Posted: 10 May 2024 13:52
by Badwolf
stephen_usher wrote: 10 May 2024 13:41
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
Re: Another PiStorm Blog
Posted: 10 May 2024 13:55
by stephen_usher
I may just do that when I get home. Thanks.
Re: Another PiStorm Blog
Posted: 10 May 2024 14:05
by Badwolf
stephen_usher wrote: 10 May 2024 13:55
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
Re: Another PiStorm Blog
Posted: 10 May 2024 14:08
by stephen_usher
I may try that first. After all if those zeros aren't zero there's no point returning the value.
Re: Another PiStorm Blog
Posted: 11 May 2024 14:20
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.