Tfx Aga?

[sokolovic]

It makes me wonder, how many floppies does the reviewed Amiga version had back in 1995 ? The PC version is 8 floppies, probably the Amiga version had much more.

[tolkien]

Originally Posted by jotd

are you using the "auto" config in whdload? Strange. works on 060 with the nofpu exe ("TFX") on my setup, fails on FPU (for the moment hehe)

I have tried right now to be sure. I use "auto" and other options with no success.
Im using aos 3.1.4, latest whdload (beta?), and 68060.library from phase5.

Normal Exe works :/

[jotd]

I have zoned a beta preview with 040 fpu support and the executables I'm using and which work

This beta isn't working on 060 yet. I hope it will soon.

[Angus]

Roger that, zone targeting on standby. :-)

[jotd]

Damn, 040 FPSP isn't the same as 060 FPSP like AT ALL. Got hold of a version of 060 FPSP (completely different packaging, from a linux distro). Having done the 040 one, I think I can manage the 060 now.

In progress...

[Angus]

Yeah, baby!!! :-)

[alexh]

Originally Posted by Angus

Yeah.................... but what IS it?!

It's the software that Motorola provided for the 040 (and later 060) to maintain software compatibility betwen 68881/2 programs and the new internal FPUs. Unimplemented instructions are trapped in SW and "transparently" emulated using 680x0. Thus maintaining binary compatibility with existing FPU programs. Or so it was supposed to be.

Originally Posted by jotd

Damn, 040 FPSP isn't the same as 060 FPSP like AT ALL. Got hold of a version of 060 FPSP (completely different packaging, from a linux distro). Having done the 040 one, I think I can manage the 060 now.
In progress...

Makes sense, different FPU, different CPU possibly different unimplemented instructions. Good stuff. We really appreciate all your hard work.

[Angus]

Originally Posted by alexh

It's the software that Motorola provided for the 040 (and later 060) to maintain software compatibility betwen 68881/2 programs and the new internal FPUs. Unimplemented instructions are trapped in SW and "transparently" emulated using 680x0. Thus maintaining binary compatibility with existing FPU programs. Or so it was supposed to be.

Thanks for that, Alex. Is it known why these lofty ambitions fell short of their intended objective? If I understand correctly it would have been less efficient, but compatibility would have been insured, right?

Originally Posted by alexh

Makes sense, different FPU, different CPU possibly different unimplemented instructions. Good stuff. We really appreciate all your hard work.

Damn straight!

[jotd]

funnily enough, I first tried to run TFX with the 68060 + 68060 library without whdload.

CPU command indicates 68060 + 68882 (emulated via software of course) but the game locks up just before starting the play...

Let's hope I'll be more lucky with the direct copy of Motorola code wired in LINE-F trap. On 68040 it worked right away to my surprise the contents of those 040/060 libraries are opaque and beyond my understanding. There's also MMU stuff done in them, that we don't need when whdload is running because whdload does a great job at configuring MMU properly.

[jotd]

Okay, after a few issues with the 68060 library (easy to rebuild, but problems to integrate) it was possible to upgrade the install to support 68060.

Check the zone for an updated beta package.

It doesn't work on WinUAE without unimplemented FPU instructions (Toni is aware of that FPIAR issue) but I tested on a real 68060 and it works.

The framerate isn't too impressive though. Not sure it helps, whereas it should... If someone can test the various exes (TFX, TFX.FPU, TFX.020) on a 68060 that would be cool.

The TFX.020 file is the latest, it has FPU support but I had to allocate the data block in chipmem, which could slow down, so potentially the fastest exe on 68040/68060 could be TFX.FPU (old 1995 version). But I can try to make the TFX.020 data segment use fastmem where it's possible. Could be a tedious job, but if it can speed up things on the latest exe we have that can be worth it.

[Angus]

Downloading, will check on Amiga tomorrow. :-)

[jotd]

it took you 5 minutes to answer. Were you in traffic?

[Angus]

Originally Posted by jotd

it took you 5 minutes to answer. Were you in traffic?

Apologies, Monsieur. I'd have been quicker but EAB kept refusing to let me post.

[Angus]

Originally Posted by jotd

.. If someone can test the various exes (TFX, TFX.FPU, TFX.020) on a 68060 that would be cool.

The TFX.020 file is the latest, it has FPU support but I had to allocate the data block in chipmem, which could slow down, so potentially the fastest exe on 68040/68060 could be TFX.FPU (old 1995 version). But I can try to make the TFX.020 data segment use fastmem where it's possible. Could be a tedious job, but if it can speed up things on the latest exe we have that can be worth it.

Okay, sorry for the delay. Something I needed to sort out presented itself unexpectedly today.


I tried TFX, TFX.FPU and TFX.020 and they all worked well. Although quitting from TFX.020 took a while but it eventually succeeded.


Each exe loaded into settings which I saved and then went straight to Arcade mode.



I believe TFX.020 ran a bit slower than the other two, and possibly TFX was a tiny bit smoother than TFX.FPU but it is difficult to say.



I thought I noticed something (lag) with my joystick, but it happened with all 3 so it's probably just me, or TFX in general.



I didn't copy over the included .EXE files as their sizes and dates matched the ones I had.



End of Report.

[jotd]

The objective was to get more speed on FPU versions. The contrary seemed to happen...

if that's the case that's probably because FPU emulation (using trap) is slow, exception handling overhead and instruction decoding being the issue.

Also TFX.020 has an only data segment in chip no thanks to hunk wizard...

Now that the program runs with that emulation, it will be possible to profile the emulated instructions and possibly patch the most frequent ones natively. That could make a difference.

[Angus]

I wish I could give you a more scientific assessment but without an fps meter running......

Actually, if I select all the high distance/detail options and get it to run as slow as possible, it may be easier to evaluate. I'll give that a try.

Once I save the config to high detail, the different .exes and new slave won't change it back or anything will they?

[jotd]

no, it should stay the same. Also running with NOCACHE will slow it down even more. Yeah, I'd also wish there was a FPS meter... but there isn't.

[AMike]

Sorry guys - how do I have to handle the files in the zone? Only exchange the executables from jotds data directory isn't sufficient for a correct WHD Install. Thanks

I've tested my old TFX install - 68000 and FPU works very well on my A4000/60/66 (with MuRedox) - 040 leads to an instant software failure.

[jotd]

Sorry guys - how do I have to handle the files in the zone? Only exchange the executables from jotds data directory isn't sufficient for a correct WHD Install. Thanks

if you have an old install, just put the files in "data", and unpack the zone files onto it to complete it

I've tested my old TFX install - 68000 and FPU works very well on my A4000/60/66 (with MuRedox) - 040 leads to an instant software failure.

I had tested FPU version with MuRedox in 060 config on WinUAE and it failed (plane going haywire), probably because of WinUAE limitations for FPIAR register. I think I can do even better than MuRedox (speed-wise) by patching the executable specifically. The current solution is temporary/is the backstop for instructions like cosine, sine, which are slow anyway and not worth plugging in directly. But I have to profile the code to see the potential gains. Today I've installed the FPU emulation code blindly and it works, but not as fast as it could.

The FPU emulation of the whdload works with 040, probably slow too.

[Angus]

Okay, I did some more tests and I still think TFX.EXE runs a bit faster.

I noticed when I selected Military Spec I lost all control from the joystick, but going first to Simple and then back to Military Spec got it working again. Arcade is mouse only by the way - which is unavailable in other modes. (It seems to run quite a bit faster too).

Are you aware if you use the Examine System feature it supposedly gives you a stat for floating point cycles? It said 4K with each .exe when I tried it.