TFX on a PiStorm32

[tomcat666]

Originally Posted by Seiya

But does emu68 working in jit?

Emu68 is JIT yes. Unfortunetly it means that emulators like DOSBOX don't work well in it just because of it aparently.

[Seiya]

not for that. i asket to know how it works emu68. in WinUAE you can choose to enable or disable Jit.
So emu68k works like Amithlon where UAE working always in JIT.

emu68k emulate a so fast 680x0 processor that with few games there are problems of performance due to a bottlenek

[Angus]

Rats! Foiled again! ;-)

[van_dammesque]

[ Show youtube player ]

[tomcat666]

Originally Posted by van_dammesque

[ Show youtube player ]

Well, we are now upto the theoretical 7.0 Mb/s on the pistorm32... so pretty much there when it goes to chip ram writes:



He should update the video...

[alexh]

Originally Posted by Seiya

not for that. i asket to know how it works emu68. in WinUAE you can choose to enable or disable Jit.So emu68k works like Amithlon where UAE working always in JIT.

PiStorm can run emu68k JIT or Mushashi interpreter

Originally Posted by Seiya

emu68k emulate a so fast 680x0 processor that with few games there are problems of performance due to a bottlenek

No. The problems are in the code of the game and nothing to do with the CPU they are running on

The fact TFX doesn't get any faster with a Much Much faster CPU can only be due to the way the game was written. It either artificially limits the speed OR uses hardware in a way that the CPU spends most of its time waiting for something.

[Karlos]

It's clear that tfx is crippled by something that isn't the CPU. It's slow on PiStorm, slow on UAE with cycle accurate memory access and fast on UAE with all the stops pulled out.

It's definitely some crappy memory / chipset access loop somewhere hogging it all.

[Galahad/FLT]

Originally Posted by Karlos

It's clear that tfx is crippled by something that isn't the CPU. It's slow on PiStorm, slow on UAE with cycle accurate memory access and fast on UAE with all the stops pulled out.

It's definitely some crappy memory / chipset access loop somewhere hogging it all.

Surely you should be able to activate the HEATMAP option in WinUAE which will physically point to what the problem is?

[UberFreak]

Originally Posted by tomcat666

Well, we are now upto the theoretical 7.0 Mb/s on the pistorm32... so pretty much there when it goes to chip ram writes:



He should update the video...

These results are for the beta releases that many of the testers on pistorm32-dev Discord have issues with, which is why it was not added to the official releases yet.
I had issues with these betas and reverted back to the latest nightly.

[Karlos]

Originally Posted by Galahad/FLT

Surely you should be able to activate the HEATMAP option in WinUAE which will physically point to what the problem is?

Maybe someone can try

[paraj]

With the WinUAE DMA debugger it sure appears to be doing something slow. For each displayed frame it has a bunch of frames with quite a bit of CPU access to chip mem, then 1.5 with basically nothing and then a burst of blitter activity (seems to be a large copy D=A using the BLTSIZV/H).

So it's likely something that could be fixed, and at least it's quick to get into demo mode to show the issue. First point of action would be someone (not me) doing some basic reverse engineering of the code to figure out what it's actually doing.

EDIT: It seems to be doing essentially doing "putpixel" with bset/bclr into chipram thousands of times per second...

[Karlos]

Originally Posted by paraj

EDIT: It seems to be doing essentially doing "putpixel" with bset/bclr into chipram thousands of times per second...

Oblique line drawing?

If I was just prototyping something and had to put up with planar graphics I sure as hell wouldn't be rolling my own code until absolutely necessary during an optimisation cycle.

[jotd]

so we're talking about TFX or Tornado ?

bset/bclr from chip could be replaced by fastmem backbuffer and then copy screen to chip in the end: when copper interrupt or vblank is triggered, in the non-displayed buffer (surely the game uses double buffering)

[Karlos]

Originally Posted by jotd

so we're talking about TFX or Tornado ?

bset/bclr from chip could be replaced by fastmem backbuffer and then copy screen to chip in the end: when copper interrupt or vblank is triggered, in the non-displayed buffer (surely the game uses double buffering)

What if the chip memory is being drawn to by the blitter ? Your fast nem buffer transfer would clobber it.

[jotd]

true. Some rare games (Red Zone) don't use the blitter but most 3D games use it.

[alexh]

This is a very late 3D game. Designed for accelerated Amiga's. I'm not saying it doesn't use the blitter but they knew it would be slower than the CPU. Especially with 020+ binaries

[Angus]

Would a comparison of how the AGA and ECS versions perform on UAE offer any more indication of what is going on?

[paraj]

Sorry, yes, that was for Tornado (not sure how I got them mixed up).

TFX uses the blitter a bit, but not too much. It also plots directly in planar mode using the CPU but is clearly optimized to reduce the number of chip accesses (always doing longword accesses). This is OK, but I think it would be faster if it just operated on a fast ram buffer and copied that to chip mem (maybe only parts that have been changed).

TFX.040 includes quite a number of symbols, so it's not too hard to figure out what is going on.

[jotd]

Originally Posted by paraj

Sorry, yes, that was for Tornado (not sure how I got them mixed up).

it's Angus fault

[Angus]

Always! ;-)