Pistorm32 showcase thread

[tomcat666]

Hi everyone.

Since Pistorm32 has been receiving some bug fixing love from our Paraj I thought it would be nice to have a thread where you can see some of the results of late night bug fixing sessions which have been a blast!

First one is the fully working Andromeda-Nexus 7 demo. The demo is known to be a pain in the a** even for many slower accelerators. But with the current fixes the demo runs perfectly on the pistorm32 with CM4 at 2.2Ghz, bringing the amiga to the whopping 2500 MIPS. Thanks to the findings by Paraj and optimisations done by Michal we can now enjoy it as it was intended:

[ Show youtube player ]

You will notice that this is not the newest FAST memory version of the whdload slave. It is the old slave that runs fully from the chip ram, to showcase that the chip ram issue on pistorm is being dealt with Also the chip ram version of the slave has no artefacts on the gouruad effect. The demo runs with absolutely no speed-related options set, at full speed and with full CACHE's turned ON!

[Kin Hell]

Hi TC...

This is good news.

Does this mean there has always been a timing issue & by slowing up the Chip Ram Speed.... it fixes it?

Or will there be some new code allowing WHDLoad's faster slave to run quicker still?

Only asking as the Chip Ram speed thing has always been an issue with EMU68.

[tomcat666]

Originally Posted by Kin Hell

Does this mean there has always been a timing issue & by slowing up the Chip Ram Speed.... it fixes it?

Not with Nexus7, for nexus 7 the slowdowns were in some 020+ specific instructions that do bulk memory operations.

Originally Posted by Kin Hell

Or will there be some new code allowing WHDLoad's faster slave to run quicker still?

Don't think it will make much difference, since all the effects are already running at the fastest possible speed considering they all use chip memory - graphics (the fast slave only uses fast memory for the code). I think this is basically it when it comes to Nexus 7

Originally Posted by Kin Hell

Only asking as the Chip Ram speed thing has always been an issue with EMU68.

It has, but it seems it has been exaggerated or the issue was/is somewhere else in the Emu68 JIT code.
There are still some ECS Demo routines which exhibit slowdowns, which need to be taken under microscope - similar to what has been done with the AGA slow downs - currently I don't think we have a case anymore.

[wiz12]

It is great to see the progress made in the last few months but with the Nexus 7 demo, is it just me or is there still graphic glitches on the bouncing ball scene at 1:35?

[Dunny]

Originally Posted by wiz12

It is great to see the progress made in the last few months but with the Nexus 7 demo, is it just me or is there still graphic glitches on the bouncing ball scene at 1:35?

Those may be conversion from RGB to HDMI at fault. I get them over my SCART connection into an HDMI box.

[tomcat666]

Originally Posted by wiz12

It is great to see the progress made in the last few months but with the Nexus 7 demo, is it just me or is there still graphic glitches on the bouncing ball scene at 1:35?

Those are artefacts because of cheap RGB to HDMi and HDMI to USB adapters that are used to get the rgb video into the PC They don't come up on rgb screen.

[tomcat666]

And we have one of the greatest 64k intros on Amiga ever created finally running on pistorm32. It is Dolphin's Dream by Push. This is a FPU-heavy demo which enabled Paraj to find quite a few bugs in the Emu68 fpu implementation which Michal quickly fixed.
The demo runs in 33 fps on pistorm32 with 2.2Ghz CM4, which is possibly the fastest we have seen this demo run on a real Amiga ever:

[ Show youtube player ]

[derSammler]

Originally Posted by tomcat666

It has, but it seems it has been exaggerated or the issue was/is somewhere else in the Emu68 JIT code.

Neither. They know and even give an example themselves that shows the issue: Jim Power. That game is completely unplayable due to the slowness of chipram access. But they improve it constantly.

For most games running thru WHDLoad, however, the issue is not noticeable.

[tomcat666]

Originally Posted by derSammler

Neither. They know and even give an example themselves that shows the issue: Jim Power. That game is completely unplayable due to the slowness of chipram access. But they improve it constantly.

Actually it is not a chipram speed issue. Paraj debugged it and even created a slave that almost works. It is a SMC issue, self modifying code was partially fixed, but in some parts not, so his slave is not yet working fully on Emu68. The game works perfectly fine in musashi and both Musashi and Emu68 use the same firmware on pistorm32 and have the same chipram access.

[btp]

Really happy to see so much progress being made!
Kudos to Michal who is dedicated in improving EMU68 and all other people that help him and support his efforts.

[tomcat666]

With the help of Paraj we got some really tricky AGA demos to run. This was not a bug on the Emu68 side but actual bugs in the demos that prevented them to run on certain configurations. So the whdload slaves he created can help others to get these demos to run:

Nature-Quattro Stage One:
[ Show youtube player ]

Ghostown & Haujobb-Last Train to Danzig:
[ Show youtube player ]

Embassy-Delta:
[ Show youtube player ]

Embassy-Myster & Tremor:
[ Show youtube player ]

You can download all the whdload slaves here:
https://drive.google.com/drive/folde...K9ZXtoXyTZIch_

[Lustmord13]

Originally Posted by tomcat666

With the help of Paraj we got some really tricky AGA demos to run. This was not a bug on the Emu68 side but actual bugs in the demos that prevented them to run on certain configurations. So the whdload slaves he created can help others to get these demos to run:

Nature-Quattro Stage One:
[ Show youtube player ]

Ghostown & Haujobb-Last Train to Danzig:
[ Show youtube player ]

Embassy-Delta:
[ Show youtube player ]

Embassy-Myster & Tremor:
[ Show youtube player ]

You can download all the whdload slaves here:
https://drive.google.com/drive/folde...K9ZXtoXyTZIch_

Question for a noob, what is the procedure to replace the slave?

[tomcat666]

Originally Posted by Lustmord13

Question for a noob, what is the procedure to replace the slave?

There were no whdload slaves for these demos before.
You will need to create a new directory and put the slave there.
Create a sub-directory called "data" and put the original demo in this data dir.
Then just run Whdload file.slave

[wiz12]

Will these fixed demos get an official release on the WHDLoad website?

[Lustmord13]

Originally Posted by tomcat666

There were no whdload slaves for these demos before.
You will need to create a new directory and put the slave there.
Create a sub-directory called "data" and put the original demo in this data dir.
Then just run Whdload file.slave

OK thank you

[tomcat666]

Originally Posted by wiz12

Will these fixed demos get an official release on the WHDLoad website?

Currently Paraj has no plan for the official release. The slaves weren not thoroughly tested and can still contain bugs here and there... use them at your own risk

[tomcat666]

Another fix by Paraj... this time MadWizards-Amsterdam Blessings demo. Another demo with bugs that prevented it running on pistorm32. Because the demo needs AHI installed when the end credits start you will also need to add the installation of that into the data folder if you want to hear the music there.

[ Show youtube player ]

[Karlos]

Paraj certainly is busy!

[paraj]

Like Tomcat wrote I'm not planning on making real releases for these. The demos in question work most of the time on my 060 w/o whdload, so I imagine it's the same for other people. They're only fixed enough to get running on pistorm, which is 1) fast 2) doesn't have a MMU. Some of them still do out of bound reads (and sometimes writes), especially if they get out of sync.
It would also require making documentation, installer, debugging further and handling support, none of which I feel too inclined to do for such a niche case.

All of the slaves are basically wb3.1 slave w/ fpu enabled + a few minor fixes. Source is included if anyone feels inclined to take this further, and I'll also happily provide diassemblies. If there's a big demand I may reconsider.

Special shout-out to Last Train to Danzig where it looks like C2P routine was incbin'ed with fixed memory addresses for 3 variables!

[tomcat666]

After some more incredible fixing done by the pistorm team with help from Paraj we now have 100% compatibility for 1010 games (WHDload and HD loaded) with zero problems/glitches. Also the majority of AGA demos run without any glitches and now even the OCS/ECS part of the demo scene is finally catching up. The compatibility is really great considering this is an accelerator that runs a JIT core at 2500 MIPS (2.2Ghz CM4). To showcase this I have made a video of 12 OCS/ECS demos, some are classics from back in the day and some are made recently. There are still some glitches here and there in some effects, but overall we can enjoy them on pistorm now.
When the demo starts with WHDLoad you can see the Emu68 and WHDLoad options that are used to run the demo on the bottom of the screen.
Last demo is run from floppy disk and we turn off caches in the early startup menu.

[ Show youtube player ]

Demos:

Kefrens - Desert Dream
Anarchy - 3D Demo 2
Binary - Made in Croatia
Crionics - Hardwired
Spaceballs - State of the Art
Sanity - Arte
Andromeda - D.O.S.
The Electronic Knights - Hologon
Lemon - Rink a Dink Redux
Scoopex - Mental Hangover
Spaceballs - 9 Fingers
Batman Group - Batman Rises