A.D.A. Amiga Demoscene Archive

I am seriously running out of ideas regarding a strange FPU bug that is related to my A4000 with 68060/50 Mhz in a Cyberstorm MK1. I am about to think that the hardware is defective, but then again, I might as well have misconfigured something.

The bug first appeared to me when I was still active on the Amiga about 10 years ago. It showed with the first demos that made good use of the FPU, e.g. Ride/Skarla, Cybercinematastic/Loonies, or IKAnim/Loonies.

What the bug does on my machine is that certain FPU calculations apparently return funny results which results in wobbly 3D scenes in the aforementioned demos. Sometimes, not all the time, the polygons are drawn all over the screen, or at least the textures are wobbling more than they normally would.

I can't quantify the effect of this bug any better at the moment, but I am writing this in the hope that I might possibly be able to patch those issues away.

Any ideas guys?
What versions of 68060.library, setpatch and other relevant tools are you using?

My Amiga is running OS3.0. See below for its config according to WhichAmiga.

68060 FPU is not fully compatible with 68882 and has to emulate certain instructions. You could try to run Cyberpatcher (the tool included by phase5), Oxypatcher (it's supposed to be faster) or MuRedox (it requires MMU.library).

Hi Crumb, thanks for the reply. I have tried both, Cyberpatcher and Oxypatcher and they both have no effect on my issue. I'll will try Muredox, maybe that will do the trick.

Apparently some guy at English Amiga Board suggested that my rev1 68060 itself might be the issue, as the latest revision of the 68060 was rev6. Any thoughts on that?

Does the gfx glitches happen when your amiga is cold and you cold boot or does that happen when it's been working an hour or so? try to run these demos with your computer case open.

Is your memory 100% ok? run some tests to check it (there are some memory testers at aminet). MK1 memory interface is quite picky, perhaps your memory modules are not completely ok. It could also be a problem of chipmem. If you have fast memory in the motherboard you can try to remove it too -but leave chipmem module or it won't boot :-)

I don't think you have problems due to 060 revision but who knows. AFAIK differences are minor and the problems are corrected in the firmware so you don't have to worry about that. If it was a big problem with the chip your problem I guess you would probable be able to reproduce it easily.

Try to disable CGX and run demos from AGA WB or even boot without Startup-sequence, launch setpatch and later your demo.

hey noname
have u tried to update your accelerator libs with these ? http://phase5.a1k.org/ , the package on top, thats the 060 libs i am using on my a1200, allso u shouldnt need any of the patchers at all on any of the demos u mention here as far as i remember, they should all be nicely coded for the 060 (dont have my miggy near to test though :P )
i might add that i'm using classicWB setup by bloodwych (not that it matters), but maybe your setpatch needs an update ? cant remember what version is with classicWB, but i think yours is fine though

Extralife, thanks for the link to the Phase 5 page. It contained newer version of the relevant libs, so I gladly downloaded them. They didn't remove my issue, but anyway, good to have.

Crumb, those glitches happen always. My CPU is cooled and the case is always open. I can't say for sure that the memory is 100% fine. But I spent several hours playing around with different combinations and the associated jumper settings (what a joy on the Mark 1 :). It didn't change anything to my issue.

If you have various memory modules you can test them separately. Configure your mk1 for just 1 memory module and try them one by one.

Precision issues?

1) some library/program that gets run during startup on your machine sets you to single precision mode?
2) the emulation code for transcendental instructions is bugged on your machine, for some reason?

If either of the two above is true, it should be possible to identify this by writing a test program that runs a sequence of calculations (FADD FSUB FMUL FDIV FSQRT FSIN FCOS etc) with differing inputs, and records all intermediate output values. Then someone else with 060 could run the same program and compare the outputs.

If you make a copy of your system files and that very demo and run in WinUAE it could tell you if it's a matter of settings or a broken FPU. I know of at least one case where a broken FPU (though an 882) was causing similar problems.

The test-program calculates sines of all 32bit values and prints out a debug line if the returned value is not in the range of -1 .. +1. Running it in WinUAE - with a copy of my real Amiga system as a hardfile - causes no debug lines at all. Running it on the real Amiga 4060 causes in excess of 500 MB of debug lines; most, if not all of them indicate that "NaN" has been returned instead of a valid sine value. They start kicking in when we pass 16384.

Now I would gladly like to ask someone with a real 060 to run this program for me as well, if you can spare an hour of computation time. But as it stands, I am pretty sure that there is something wrong with my (or my kind of) 68060 FPU.

---

Therefore, i started looking for workarounds that avoid using that fsin at all. One promising alternative seems to be "fastsincos.lha" from Aminet (http://aminet.net/package/dev/asm/fastsincos). Has anyone ever used that library and can make any comment?

I tried to assemble it yesterday but failed on a few lines that looked odd to me. The author states that he used StormC and Phxass. I have not tested it with StormC, but Phxass, Vasm, Devpac and Asmone all choked on the same lines. Do they look valid to you? Do I maybe have to modify something in the assembler settings to make it work with those floating point equates?

Recall that all trigonometric and transcendental instructions in the 68060 are software-emulated.
I suspect that it's not your CPU, but the FPSP package that is broken.
I.e. your 68060 board has buggy on-board firmware.

For some more conclusive tests, generate a table with the result for fsin(x) for all values from 0..65536. Email it to me and I'll do a comparison run on my 1200.

Carsten Schlote produced an alternative firmware for both Cyberstorm MKI & MKII named MKxDiag. Latest version is 40.8 but on MKI you'll need some hardware to burn the firmware in other chip (overwritting your chip may not be a good idea).

I haven't tested it but you may try out this 68060 library from Carsten:
http://web.archive.org/web/20050205061226/http://w ww.neodyne.de/bodylove/Downloads/MC68060_40_14.lha