Exxos's PiStorm blog

[Steve]

I don't think I'm the right person to be doing that, because although I can install this stuff, flash firmwares. I don't *understand* it. All I can tell you is the first, and only version that ever worked for me was June 25th. Anything before that didn't work (Cryptodad tweaked it until it worked for my H5, on June 25th). I think I tried upgrading to a newer version later, but that also broke it. So I stuck at June 25th commit for my particular system. I'm not saying that newer versions since won't work, I just haven't tried them. Reason being: The only 'updates' since then have been <Random X person comes in with particular Atari setup> and then Crypto tweaks the code to get it working for them, but in the process tweaking to that specific Atari doesn't necessarily mean that the code still works for the last Atari it previously worked with. Then fast forward another <Random X> amount of people, the repo has been tweaked so many times for many different configurations. It's not like my particular setup is going to benefit from any of these changes, if that makes sense. There haven't been any particular H5 configuration specific improvements.

Cryptodad would be the person who can tell you whether things were stable or not in the early days & whether instability was introduced by speeding the ram access up or not.

[exxos]

@dad664npc maybe you can shed some light on all this ?

[Steve]

By the way, I looked back in Discord to see what my Gembench results were, here they are:

(running at 800x600x64k via et4000 HDMI output)

With NVDI:

with_nvdi.jpg (180.64 KiB) Viewed 1540 times

Without NVDI:

no_nvdi.jpg (178.45 KiB) Viewed 1540 times

[exxos]

By the way, I looked back in Discord to see what my Gembench results were, here they are:

Such tests need to be done with a stock 68000 as different cpus have caches and are more efficient with some instructions. Also stock medium res as well.

Problem is as well as we don't know ( or I don't ) how good the bus emulation is on the 030 etc Things need to be as basic and as close to stock as possible to debug.

It would make life a lot easier if the CPU could run at 8mhz or 16mhz but I'm guessing that's not possible ?

[stephen_usher]

The "loop-thingy" setting in the config file is supposed to set the speed but it seems to be a wet finger in the air type affair and depends upon the speed of the Pi CPU,

[Badwolf]

The "loop-thingy" setting in the config file is supposed to set the speed but it seems to be a wet finger in the air type affair and depends upon the speed of the Pi CPU,

I think it's just how many cycles will you let the emulated 68k run wild before checking if there were an interrupt.

Smaller = more accurate response, but slower.

BW

[stephen_usher]

The "loop-thingy" setting in the config file is supposed to set the speed but it seems to be a wet finger in the air type affair and depends upon the speed of the Pi CPU,

I think it's just how many cycles will you let the emulated 68k run wild before checking if there were an interrupt.

Smaller = more accurate response, but slower.

BW

I see... but the lower the number the less stable the current emulation seems to be. Unless I had it above 600 I'd never get to the desktop. But that may be because it's reading erroneous status more often and crashing.

[Badwolf]

I see... but the lower the number the less stable the current emulation seems to be. Unless I had it above 600 I'd never get to the desktop. But that may be because it's reading erroneous status more often and crashing.

That'd be my guess. It's Russian roulette and loopcounts is how long you wait between trigger pulls?

BW

[exxos]

Just to wrap up this thread.. I sold my pistorm stuff to @rubber_jonnie.

So locking this thread.