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

[Zooz]

Hi Thomas

Some words about "except that upgrading the code is probably not quite as straightforeward as it was for the libraries."

Not sure it really matter since in all cases, such updates would need team collaboration, where of course they know how to update it. And if you meant that it needs a new core to upgrade it, it does not actually. There is a accessible vector for that, and can be 'hot' overwritten.

[Zooz]

The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga. Personally i find this a good news and is welcomed. It also was done with constraints in mind. Whatever solution the team selected they did because of constraints they knows and solved and well. The result is a fpu that already reached a nice level of compatibility. It covers all the existing fpu instructions from 881 to 060. The 881/2 instructions are covered with solution that do not 'eat' fpga space while being faster than any existing library.

[Zooz]

It's a software emulated fpu. Those have existed for years.

Lol no. Speaking of Gold2.7, it is hardware implemented. Quite all 040 fpu instructions are, all Ea modes are, Registers are. It is clear that only some 881/2 instr are software emulated. And even for the emulated ones they benefits of the hardware implementation. EA computation is done by hw for example, and also castings and primitives,  which helps lower (and simplify)  the emulation overhead by an important factor.

[Zooz]

Gold 2.7 still uses FEMU. It might be tuned for Apollo, but FEMU isn't the first 6888x emulator for fpuless 680x0 systems

Erm.

Then i need quote again what i told here :

Lol no. Speaking of Gold2.7, it is hardware implemented. Quite all 040 fpu instructions are, all Ea modes are, Registers are. It is clear that only some 881/2 instr are software emulated. And even for the emulated ones they benefits of the hardware implementation. EA computation is done by hw for example, and also castings and primitives,  which helps lower (and simplify)  the emulation overhead by an important factor.

The FPU in GOLD2.7 is HW. Just as 040 and 060 FPU is ! With only little differences. Then the emulated instructions are no more FEMU related, strictly speaking. FEMU was written with F-TRAPS mechanic and with OS MATHLIBS calls. The GOLD2.7 embeds true HW FPU + a VECTOR mechanic for the emulated 881/2 instructions, that benefits also from the HW FPU Core, and do not relies on OS MATHLIBS anymore.

Seems to me you are speaking from old assumptions based on old progress. Since, the team worked hard to fit real FPU in the core. Before telling such assumptions (with so much certainty) you should at mimimum inform yourself on current status.

[Zooz]

To feed the technical background of this thread,  and not the trolls,

this article can help have better overview of the soon to come Vampire FPU :

http://www.apollo-accelerators.com/wiki/doku.php/fpu

For sure it help clarify some questionings.

[Zooz]

Yeah, it seems current FPGA is not worth buying if you want full FPU compatibility.

"Reduction is in discussion and depends of the space remaining in FPGA, either 64bits or little less."

So you might not even get 64 bits.


There has obviously been some changes, because only a little while ago gunnar posted

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

"FPU performance improved a lot with new FEMU and GOLD 2.7

While the wiki says "The current FPU Core is NOT anymore based on the FEMU program."

Which is good that they come round at least in some ways to the correct way of thinking.

But of course there is still some emulation going on & it's not 040/060 compatible, which for me is still bad.

"Those instructions are handled using some optimized FPSP code.

The FPSP code is instantiated using a new dedicated FPU Vector."


And who knows what will actually get released.

"Some of the following specifications might change in final GOLD 2.7 release."

It really looks like to me you either need buy some better glasses or learn how to read. The FPU is clearly 040/060 fpu. You are tiring man. Remains only the precision which is only a choice related to fpga contrainsts while not impacting compatibility that much according to all videos/witnesses from the beta testers.

[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.

[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.

[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.