Another PiStorm Blog

[exxos]

Looking at the verilog file it seems that they're not fully emulating the bus cycle, making a few assumptions. With Gembench showing 101% ST RAM memory speed I have a suspicion that the bus timing is not right as the maximum speed should be determined by the MMU as that's controlling the bus cycle.

I think @Badwolf did a load of tweaks to fix the STram speed issue a while back ?

I wonder what the TF536 RAM speed is with caches off ? It's hard to imagine what's going on at those speeds. It might be normal.

But the problem with the setup as I see it... Is DTACK basically follows /AS meaning it will have to have some sort of wait states without , I assume, using the 8mhz clock as a reference. It's would mean DTACK is being read marginally to fast. But there isn't time for the CPU to do another bus cycle as it's locked out by shifter access anyway.

I have seen RAM speeds running to fast during my booster work though. Think I've seen 103% at some point. So it's entirely possible it's doing ST bus cycles to fast.

EDIT
viewtopic.php?p=1584#p1584

So 101% ram speed might be normal. :shrug:

But on my sec booster up to 75mhz it's still 100% .

Maybe try nembench and see what that makes of it all. Also try ram tests and see if they pass. Have to rule things out to see what's tripping up.

[stephen_usher]

YARTT runs for a while and then the CPU emulation resets itself, which a real processor wouldn't do. You get large numbers of "Bad status" where the state machine in the PiStorm CPLD has got into an incorrect state, again probably to do with the bus cycle not being correct.

You'll need to decrease the GPIO clock rate if using a Pi4 as it can't drive the GPIO as quickly as the Pi3 and is really limited to 80MHz at full voltage change according to what I've read. Frequencies above this decrease the amplitude and regularity of the output with 120MHz being about the limit. The system seems very sensitive to this and the loopcount or whatever it's called in the config file. If this loop-thingy is too small then you get more "Bad status" messages. On my machine I had to have it above 600 to get to the desktop under TOS2.06.

[exxos]

Have you scooped it out to see what it is actually doing ?

[stephen_usher]

I'd have to set up a logic analyser somehow.

[Badwolf]

Looking at the verilog file it seems that they're not fully emulating the bus cycle, making a few assumptions. With Gembench showing 101% ST RAM memory speed I have a suspicion that the bus timing is not right as the maximum speed should be determined by the MMU as that's controlling the bus cycle.

I think @Badwolf did a load of tweaks to fix the STram speed issue a while back ?

I pared the state machine down to the minimum needed to talk to the ST -- which was actually more than the Amiga, it seems Amiga asserts DTACK only when the data is ready but the ST asserts it up to half a cycle early knowing there's a minimum time before the 68k latches.

I couldn't make ST RAM speeds run at 100%, however, as the emulator wasn't ready for the next cycle in time (actually I could with writes by ignoring bus errors and continuing execution, proving it was the emulator not being ready in time, but that was just a proof of concept. Reads need to respond to what comes back so do actually have to block until the data or bus error is available).

Since then @dad664npc really went to town on the emulator side to speed that up enough that it could get there. And using a RPi 4 really helps on that front.

He also has changed the firmware considerably since my initial adaptations so I probably wouldn't recognise it any more.

If I had to hazard a guess as to where the problems lie, I would think it's probably not the state machine, but the support calls. Things like interrupt indication, the actual multiplexing and status polling. The latter running synchronously in one clock cycle which can be as short as 5ns.

If I had the time -- which I don't -- I think I'd go back to basics and slow the protocol down looking for stability knowing we now have the backend performance we need at the end of the day.

Regarding the 100%+ ST-RAM speeds, this is normally caused by the accelerator running the instructions faster for reasons of simple clock rate, cache or alt RAM & is a phenomenon seen with most accelerators I've built or worked on. Benchmarking stuff is hard.

BW

[exxos]

I'd have to set up a logic analyser somehow.

I'd just scope some out and see what it's doing.

[exxos]

I pared the state machine down to the minimum needed to talk to the ST -- which was actually more than the Amiga, it seems Amiga asserts DTACK only when the data is ready but the ST asserts it up to half a cycle early knowing there's a minimum time before the 68k latches.

I don't think the ST has any DTACK control at all. I think basically just follows /AS. Unless the shifter cycle is happening in which case DTACK will be delayed a few clocks. I don't even know what file the state machine is in ? Though I would assume that checking DTACK is low 2x 8mhz clocks after /AS goes low is probably about the way to go.

If I had to hazard a guess as to where the problems lie, I would think it's probably not the state machine, but the support calls. Things like interrupt indication, the actual multiplexing and status polling. The latter running synchronously in one clock cycle which can be as short as 5ns.

Doesn't sound good in particular is the ST bus glitches all over the place to start with.

If I had the time -- which I don't -- I think I'd go back to basics and slow the protocol down looking for stability knowing we now have the backend performance we need at the end of the day.

Aside from lack of time I have no idea about the programming so cannot really help much in that respect unfortunately. Though I think starting with the diagnostic cartridge and just verifying basic stuff like memory test is stable and testing things out individually before letting it loose in TOS. I should be able to do that in a couple of weeks when I have my H5 back on my desk. But other than a bit of the usual shooting in the dark as to what the problem is, I'm not sure what else I can really do this project.

Regarding the 100%+ ST-RAM speeds, this is normally caused by the accelerator running the instructions faster for reasons of simple clock rate, cache or alt RAM & is a phenomenon seen with most accelerators I've built or worked on. Benchmarking stuff is hard.

Yep. The GB6 CPU routines are all coded in assembly, so it should not be affected by faster ROM calls for example. But the thing is, there is a couple of lines of basic code normally for routine "setup" which could potentially be affected by a faster CPU clock. This is basically why I prefer just to run all tests in STRAM, so we have a better foundation as to what we are referencing against.

My SEC booster is probably the only comparison running at 64MHz - 75MHz. viewtopic.php?f=42&t=2703

But that was bottlenecked by effectively at 32MHz because of a physical ROM access. Useless trivia, is the next generation of sec booster has a lot of SRAM on board with the attempt to copy ROM to SRAM to solve that problem. But I haven't really had time or motivation to work on the project of late anyway.

Looks at this benchmark viewtopic.php?p=114683#p114683 its hard to think what the actual pi CPU speed is. I mean if my SEC benchmark wasn't bottled necked on the ROM, the score could be a bit higher. I'd assume the PI CPU would effectively be around 100MHz. But anyway, really matter at this point anyway what the top speed is. But that in itself cause headaches. When I got around 50MHz other parts of the system started basically screwing up one by one which needed fixes doing in the code.

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.

[stephen_usher]

This is where the state machine lives, in the Verilog file: https://github.com/gotaproblem/pistorm- ... evEPM240.v

[exxos]

This is where the state machine lives, in the Verilog file: https://github.com/gotaproblem/pistorm- ... evEPM240.v

Thanks. At a glance I don't really see anything wrong. Looks like it is counting 8MHz cycles, so that's fine.

I cannot really say for sure eitherway, but my initial reaction is that the 101% RAM score is just a side-effect of the CPU running at like 100MHz along with ROM.

If you are saying RAM becomes unstable over time, it suggests something is warming up and going out of whack.

I wonder if the wake up states play a part in all this as well. DTACK from the MMU can arrive at different times depending on wakeup states. But as the PI state machine is looking at 8mhz clocks and states, it shouldn't matter I think.

But there are problems with DTACK effectively staying low all the time, in particular during YM access. That's why I ended up with a SND_CS jumper on the H5 because DTACK stays low right into the next bus cycle which can screw up is the state machine expects DTACK to go high at any point (needs to be found and checked in the PI code) . It could possibly explain why frontier is unstable because of YM access..

EDIT:
I can only see DTACK in the same file. It only seems to check its low. So I guess that be fine anyway.

EDIT2:
I also wonder if it should check the DTACK later than S4. While S4 is likely correct per 68K spec.. I am sure there was something about not checking until S7 for latching data at some point.. May or may not matter.. but on the ST . who the hell knows..

[stephen_usher]

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.