Slow AGA playback performance

[Pixelsmack]

I am seeing very slow AGA animation playback ob Amiga A1200. When compared to same Amiga with 68060 accelerator. Considering how fast the PiStorm32 is, this seems weird. I know others ave shown certain AGA games and even non AGA games running slow. This maybe similar issue?

Here are links to the two test files I was using. They are extreme examples but the idea was to push the hardware. Either real 68060 or devices like PiStorms.

HAM6 ANIM: https://drive.google.com/file/d/1RP-bD8ktdwqTNmUBqyE6z1aS05qCAhJ9/view?usp=share_link

HAM8 ANIM: https://drive.google.com/file/d/1RWZ4pzAwK7EIeeuaI8MJYQgJKRSbSyna/view?usp=share_link

[macphreak4evr]

most aga games shadow or have strange artifact issues. . i have done a video showing these too coming out in a few days

[Pixelsmack]

Here are the two software programs I used in WB3.2.2 to play/test these files

clarissa: https://drive.google.com/file/d/1F2OvnzePMJfmSAosi1TYwCJwA70tMvSd/view?usp=share_link

MainActor: https://drive.google.com/file/d/1nvv3M9ytHEvx3anFXnwNprRXUhYjS07i/view?usp=share_link

Unpack both to your drive and run.

[michalsc]

Thanks for reporting. Once I will manage to find out whether it is Emu68 or PiStorm32 related I will move it to corresponding project.

[danielktdoranie]

I just want to confirm I had the same experience with these files running a PiStorm32 with Raspberry Pi 3 Model A+ and CaffeineOS version 919

[michalsc]

Issue has been moved to gateware.

[michalsc]

The issue is partially identified and covers both FPGA firmware and Emu68. In short words - in FPGA we add one or two unneeded wait states when setting up control lines, also, the clock generated from A1200 14.28MHz is less than optimal and will be fixed too.

On emu68 side there is no read or write buffer. Therefore all transfers to CHIP occur at the bit width given by the opcode:

As you may see on the sampled data above the HAM8 animation (same applies to HAM6 version), RLE-compressed, iswritten to CHIP memory byte by byte. Had Emu68 a write buffer, these could be combined to 32bit writes and had more chance to utilise the memory bandwidth.

[Pixelsmack]

Great to see this! If you need anymore examples/testing let me know. Thanks!

[michalsc]

For clearance, updated diagram with 68020 states shown. You might notice that we are slightly out of sync. You may also see there that Pistorm protocol occupies small amout of time compared to CHIP transfer itself. The short period between "PS proto" and "S0" is the time where we are syncing to bus clock cycle - the same happens on accelerators working with any other clock than 14.28MHz

[michalsc]

Please give following firmware a try:
PS32-lite.hex.bin.gz

To use it you must put it as it is (in .gz format!) on your boot partition. Then, modify your initramfs line from e.g.

initramfs kick.rom

to

initramfs PS32-lite.hex.bin.gz,kick.rom

This version of firmware reports write completion earlier, so that in case of subsequent writes the Emu68 can start pushing new data slightly before the previous transfer completed. This allows faster bulk writes to chip memory. Also, the timing is slightly improved.

Another thing which yoiu might be interested in, will show how the performance can increase when write buffer in Emu68 is ready. Please use e.g. MainActor to convert any of the animations you linked from ANIM7 to ANIM8. MainActor will store the animation compressed using LONG words, instead of bytes, so that, during playback, the data will be pushed to Amiga bus in 32 bit packets, instead of 8 bit packets (effectively giving a boost ratio of more than 4x).

For my local test with above linked firmware and ANIM8 format, the hi-res ham8 played at something around 15 fps

[michalsc]

New PiStorm32-lite Emu68 image:
Emu68-pistorm32lite.zip

[Pixelsmack]

This is promising. It’s good to know of optimized settings to use going forward. Obviously converting all prior ANIMS one may encounter for smooth playback is not practical. Still, progress is always welcome!

[Pixelsmack]

I'm not a techie at all. I am not sure I understand of the two files you've posted, what exactly to do with them. I did read the procedure for the hex.bin file. Then later I see you've posted that image. Understand, I am a child with this stuff. I don't really understand what I need to do. I generally wait for, "run this updater" Heh. So, I apologize if I am slow to act. I'm hoping others much smarter than me are looking at this too. Thank you for your work and time.

[Pixelsmack]

Okay I put on my big boy pants and got the PiStorm updated with the files you sent. I had ZERO luck getting MainActor to convert the file as you asked. It kept corrupting the palette. HOWEVER. I used Art Department Pro and used its easy CONVERT ANIM option. This made a successful ANIM8 format file from the ANIM5. I also set to LONG word. I can confirm, when playing back in MainActors player, not only is HAM8 mode working it's around 10-12fps. Which is a big improvement over the 1-2fps I was getting before the update. Still not as fast as the 68060 A4000, but MUCH closer.