TFX on a PiStorm32

[gurth]

I dreamt of TFX on the A1200 as a kid.

Could some do me the honours and show me a YouTube video of it running on a A1200 + PiStorm32 please?

In no rush. This request can sit here for months / years. I want to believe it could of been a contender.

[alexh]

JOTD did some work on TFX last year

The thread is long but it becomes more relevant towards the end

https://eab.abime.net/showthread.php?t=51666

[NovaCoder]

I once got it almost playable on a real 1200


[ Show youtube player ]

[alexh]

The work from JOTD around the 2020/21 time to bring all the known executables together, debug the capabilities of each and patch the instabilities in WHDLoad

http://whdload.de/games/TFX.html

[tomcat666]

Originally Posted by gurth

Could some do me the honours and show me a YouTube video of it running on a A1200 + PiStorm32 please?

Sure thing. Unfortunetly it is one of the rare games that doesn't play very nicely with pistorm32. Not exactly sure what the problem is, could be the chip ram speed issue, depends on how the game does the display.

[ Show youtube player ]

[alexh]

Im curious to know if this is the WHDLoad version?

Which TFX executable did you use?

What is your PiStorm configuration (Emu68? Musashi?)

[tomcat666]

Originally Posted by alexh

Im curious to know if this is the WHDLoad version?
Which TFX executable did you use?
What is your PiStorm configuration (Emu68? Musashi?)

It actually runs a bit better without WHDLoad.
I have used the TFX.040 executable, it seems to work the best of them. None of the others seem to have higher framerate, some tend to load much slower, etc.
Pistorm is Emu68 on pistorm32 and rpi4 at 1.5GHz. At 2.2Ghz it doesn't seem to have any difference either. So the bottleneck is probably chip ram writes.

[alexh]

Interesting. I thought the WHDload version was supposed to patch the remaining ChipRAM writes. Leaving only the frame-buffer copy.

[tomcat666]

Originally Posted by alexh

Interesting. I thought the WHDload version was supposed to patch the remaining ChipRAM writes. Leaving only the frame-buffer copy.

Then I might be doing something wrong Is there an option for this? Readme doesnt state any chipram writes were fixed and only frame buffer copy was left:

Version 1.0 (28.12.2020) done by JOTD
- automatic executable selection depending on cpu/fpu (or manual)
- self-modifying code removed (fonts were trashed)
- CD32 joypad support for some frequently used keys (see below)
- small manual included (thanks Angus)
- source code included

There is also 1.1 beta version on the server, which doesnt have a different readme though. Will try that one next.

[alexh]

You can select between 4 versions:
- TFX (68020, no fpu, on CD, also working on 68040/68060)
- TFX.FPU (68020/030, 68881/82 fpu, on CD)
- TFX.020 (68020/030, 68881/82 fpu, newer, data in chip, download at https://is.gd/A6yk2T)
- TFX.040 (68020/030, 68881/82 fpu, wrong name, symbols, NOT the one on CD)

Only the 1997 TFX.020 has "data in chip". This is because it was assembled/linked using a tool that screwed up the addresses.

Maybe try the EXE that doesn't use FPU?

[jotd]

maybe patching the exe so most of stuff runs in fastmem would be possible now with the experience gained from other projects. At some point I thought this was not important, but it could.

The main difference with those exes is that if you don't have a 68881/2 a lot of the FPU instructions are emulated even on a 040. TFX.040 doesn't use the FPU at all...

Game binaries are a mess. Too bad we didn't get hold of the code to rebuild that properly.

[alexh]

Originally Posted by jotd

maybe patching the exe so most of stuff runs in fastmem would be possible now with the experience gained from other projects. At some point I thought this was not important, but it could.

My bad. I thought that had already been done. Can we confirm with WinUAE (which doesn't emulate chipRAM speed slowdown) that it offers improved performance?

I would be happy to ask the original author again? (I suspect he doesn't have anything or he would have replied by now.)

https://www.linkedin.com/in/steve-mo...ls/experience/

I have been meaning for a long time to try to use Ghidra to re-source Amiga binaries. Pyrdacor & Nico Bendlin used it to re-source the Ambermoon exe. MAYBE using the exe version which has the Symbols in it could result in a semi reasonable job? I understand that it is labour intensive and not at all click-n-done.

[tomcat666]

Originally Posted by jotd

The main difference with those exes is that if you don't have a 68881/2 a lot of the FPU instructions are emulated even on a 040. TFX.040 doesn't use the FPU at all...

Oh so the info here : TFX.040 (68020/030, 68881/82 fpu, wrong name, symbols, NOT the one on CD) is wrong, it says TFX.040 has 68881/82 fpu support.

So TFX.FPU would possibly be the best one to try?

Edit: tried all versions with WHDLoad latest 1.1 beta and pretty much the same fps... very bad

[jotd]

FPU = 68881/68882 only. Okay TFX.020 is the one that should run best on 68040 because it's not using any FPU.

Yes, ambitious game, too many colors on the screen, full screen update, a lot of real 3D calculations, plane physics.... Not sure DOOM is that cpu intensive.

[alexh]

PiStorm32 Lite running Emu68 should be approx 80x the speed of 040@25MHz.

It's slowly becoming widespread amongst A1200 owners as it's only €80 and widely available.

If you can patch TFX for FastRAM it should fly

[Seiya]

Originally Posted by alexh

PiStorm32 Lite running Emu68 should be approx 80x the speed of 040@25MHz.

yes, if emu68 will run standlone without A1200. I think that something in A1200 is a bottle's neck for that emulated 68040.

[jotd]

Originally Posted by alexh

PiStorm32 Lite running Emu68 should be approx 80x the speed of 040@25MHz.

It's slowly becoming widespread amongst A1200 owners as it's only €80 and widely available.

If you can patch TFX for FastRAM it should fly

code is already running in fast ram. Only data segment is in chip for some version.

[Karlos]

Originally Posted by jotd

code is already running in fast ram. Only data segment is in chip for some version.

The only stuff that should be in chip ram is the display buffer and maybe the sound effects if it's plain old 8-bit DMA sample playback.

The chip ram access speed on the PiStorm is significantly slower than pretty much any accelerator you can name, so if there's any other frequently other A1200 accessed data, e.g. trig tables, etc. it's going to be a harsh penalty.

The testing that has been done for AB3D2 shows that the chip write speed is pretty much the limiting factor, maxing out at 32fps.

[alexh]

Originally Posted by jotd

code is already running in fast ram. Only data segment is in chip for some version.

Hmmm. I wonder what it could be then? Single screen buffer in ChipRAM?

[jotd]

you explained that: chip memory is slow, no matter how fast the CPU is running.

There are 256 colors on screen (didn't check, but it's probable), fetch mode is at maximum fetch (using 64 pixel wide sprites for HUD probably), so all has been done to make the game as fast as possible.

Also this is a port from a PC game...