[UserReview] Vampire V2-128 received and it's just pure p0rn.

[Zooz]

@phxphill

Indeed the emulation vector access is protected, supervisor mode needed, on a vector that no amiga-land software knows about it. Hard to break. At least not less than an 040/060/HSMath library.

About precision, sure, it then is enough or NOT for a given end-user. Your choice and need, i have no problem with that. That said, even 32 bits of precision would be enough for real life usage / games and demos applications,  such as in most of the consoles (PSX,...). For Quake or let's be mad Gran Turismo, 32 is enough, like any games on such machines. If the point was to use the vampire for scientific researches, then sorry about that, it is not intended to.

About emulation, that is for me infinite discussion where FPGA coding is NOT emulation! I wont argue not a single one more on this.

At end, i'm the one who had bring the more technical data here about this fpu topic, I could also bring more about for example the 100% pipelined feature. Hope it helps the people for who the vampire is targeted to. The team is not trying to convince everybody but to bring a fpu solution at best as it could be on a given board for his customers.

[pcotter]

Hmm..
Maybe Gunnar should consult with phxphill on how to implement the Cpu/Fpu on the Fpga... and Kolla too, they seem to know what they are talking about...

[Karlos]

It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.

[psxphill]

@psxphill

You seem to have no understanding of precision and compatibility in this case, these are two totally different concepts.

No, they are not different concepts.

100% compatibility means running the same code on real hardware and apollo will yield the same results. If your precision is different then it won't.

Plus the FPSP vector affects compatibility.

Hmm..
Maybe Gunnar should consult with phxphill on how to implement the Cpu/Fpu on the Fpga... and Kolla too, they seem to know what they are talking about...

Well it seems our posts here are having a result (if a little slowly). So maybe that would be a good idea.

It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.

If you aim your emulation at a fixed set of software then sure you can get away with it, but then you can't honestly claim 100% compatibility. Some people will of course not care if they are mislead, because they already drunk the kool aid.

[Zooz]

If you aim your emulation at a fixed set of software then sure you can get away with it, but then you can't honestly claim 100% compatibility. Some people will of course not care if they are mislead, because they already drunk the kool aid.

Who's claiming the opposite ?

That is always a compromise.

One can prefer a real 060 @ 100MHz, i'm happy for those who have such an accelerator. But please keep in mind what the Vampire offers for a much lower price than a '060 accel + graphics board.

The FPU article purpose is to not mislead, so take it as it is, or use another product. We understood clearly this product is not for you, or that it could have been with some different approaches. That's all OK. Everybody is free to choose the product that fits best his tastes. But arguing infinitely is little annoying, i think you understand that.

About "Plus the FPSP vector affects compatibility". Well, FPSP always affected the compatibility, slightely or not, that is already the case with existings 68Ks (a 030 is not a 040 and is not a 060, and all ended in different FPSP supports and so in different compatibility). We are speaking here of obvious things.

Now to deal with real facts than blabla, we could also find some programs that do not works OK in WinUAE and tell which of those are so importants.

WITH "Softfloat FPU emulation lib" == 80bits
WITHOUT "Softfloat FPU emulation lib" == 64bits

All in all, of course, i agree, precision level ends in a different compatibility - in absolute - but in practice this often do not matters a lot, and have to be put in some perspective, to a given priced product.

[guest11527]

It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.

Actually, no. Almost no software uses the single precision libraries, i.e. mathieeesingtrans and mathieeesingbas. Actually, I know exactly zero software that uses it. Then we have mathieeedoubbas, which is somewhat popular. Then, for the quick'n dirty, and for low-end systems, we have mathffp and mathtrans, but these run without FPU, have a bloddy stupid math model, but are fast on FPU-less systems. They are actually in some use.

Then we have those programs that use the FPU directly. It now all depends on how the FPU was configured. If the author did nothing, the FPU runs in full 80bit precision. Whether that precision is really required for the application is another story, of course.

However, multiple things can be said:

- IEEE single precision is in almost no active use
- If single precsion is used, it is mathffp and mathtrans (CPU only)
- If the math libraries are used, it is all double precision.
- If FPU only code is used, chances are better than even that this is 80bit

Hence, results will be (slightly) different on a system that runs only with 64bit instead of 80bit. Whether this matters depends on the application, but there will be a difference.

[kolla]

I guess you are referring to the tests of the individual FPU instructions. This is not testing the FPU.

October 4. 2016:

2016-10-04 [16:42:02] We said we our FPU is in testing - correct

[ShK]

What is a precision on AmigaOS 4 with PPC 440ep?

[Zooz]

What is a precision on AmigaOS 4 with PPC 440ep?

64bits

What is a default precision on UAE without Softfloat FPU emulation lib?

64bits


This is called pragmatism.

[Djole]

http://forum.apollo-accelerators.com/viewtopic.php?f=9&t=1867

New info.... for the guys stuck in 2016 like kolla

[polyp2000]

I cannot belive you guys are arguing about "100% compatibility" when we all know thats IS, and never was a thing. In the case of future software working on non apollo hardware thats a problem created by the developers and not apollo.

[Karlos]

@ThomasRichter

I think you are overstating the case. Warp3D, MiniGL etc use 32 bit floating point almost exclusively, as does quake. In fact, there original source assembler hacks in the x87 versions to explicitly set the precision to 32-bit.

Applications using the libraries you describe are by definition not compiled for any FPU as they are relying on libraries which in turn may use FPU. Binaries compiled to use FPU directly generally will use whatever precision their use case demands. For games, that's almost exclusively 32 bit

[Lord Aga]

Beta testers running existing software does nothing to prove 100% compatibility.

Unlike forum bitching which improves compatibility by 400%. Therefore Apollo is by far the most compatible thing on this planet.

In thirty seconds you could break it by overwriting the FPSP Vector.

That's all fine and dandy, but what about Vector Sigma?

[psxphill]

All in all, of course, i agree, precision level ends in a different compatibility - in absolute - but in practice this often do not matters a lot, and have to be put in some perspective, to a given priced product.

Of course it's a personal choice. But there is no point in arguing that a Skoda Fabia is faster than a Bugatti Veyron and then start talking about affordability.

I cannot belive you guys are arguing about "100% compatibility" when we all know thats IS, and never was a thing. In the case of future software working on non apollo hardware thats a problem created by the developers and not apollo.

According to some people the Apollo already is 100% compatible and claiming anything else is heresay lest it might upset the gods.

The FPU article purpose is to not mislead, so take it as it is, or use another product. We understood clearly this product is not for you, or that it could have been with some different approaches. That's all OK. Everybody is free to choose the product that fits best his tastes. But arguing infinitely is little annoying, i think you understand that.

I wasn't suggesting the FPU article was misleading, but people on this thread make various sycophantic claims in support of Apollo which contradict the FPU article.

About "Plus the FPSP vector affects compatibility". Well, FPSP always affected the compatibility, slightely or not, that is already the case with existings 68Ks (a 030 is not a 040 and is not a 060, and all ended in different FPSP supports and so in different compatibility). We are speaking here of obvious things.

Yes, but those things exist already and have existed for 20 years. Creating new incompatibilities when there are alternatives is less than ideal IMO.

Unlike forum bitching which improves compatibility by 400%. Therefore Apollo is by far the most compatible thing on this planet.

In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.

http://www.apollo-core.com/knowledge.php?b=2¬e=8608

Now I can't conclusively prove that the bitching had any effect, but the people claiming that FEMU was superior to emulating the 6888x natively must feel really silly now.

[Djole]

In September the 2.7 gold was based on FEMU, much forum bitching later and now 2.7 gold is not based on FEMU.

http://www.apollo-core.com/knowledge.php?b=2¬e=8608

Now I can't conclusively prove that the bitching had any effect, but the people claiming that FEMU was superior to emulating the 6888x natively must feel really silly now.

That's called progress....

You don't seem to get 080 is a new generation 68k CPU. Like the most of the line, it brings up some incompatibilities or better said, new features... It doesn't seem the goal was to mimic any previous 68k but to improve all of them...

[kolla]

http://forum.apollo-accelerators.com/viewtopic.php?f=9&t=1867

New info.... for the guys stuck in 2016 like kolla

"new info" is a constant with this project, very often contradictory and misleading info.

Well, at least one can now point at something when minions are screaming that there is no software emulation taking place. Also I like that it says "host memory", one can then speculate what is meant with "host".