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

[psxphill]

leaving out evident issue of 68k software emu on x86 host, amithlon didnt provide amiga chipset functionalities. i bet this will make a noticeable difference.

Being able to skip emulating different areas of memory and switching between emulating cpu/blitter/copper etc will make a huge difference.

Ditching the OS and letting all the memory accesses through to the hardware would require a bit of work, but you may be able to use the amiga pci drivers.

That would be the ultimate, something bootable that allows you to enable different JIT emulators 68k/ppc/arm etc that can then boot different OS.

[psxphill]

The difference was just where "the software runs". For the 68882, it runs as microcode in the ROM of the chip. For the 68040, it is 68K code in the 68040.library.

Only some of it is 68k in the 68040.library, some of it is implemented in hardware. Less of it is implemented in hardware on the 68060, I'd settle for vampire being compatible with the 68060. I'd like to be able to switch to 68040 though because there are times when you can't run any emulation software.

The 080 fpu is the first ever 68k fpu in an (amiga targeted) fpga.

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

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

If that's not correct, then great, 882 me up.

Eagerly awaiting an A1200 version!

Your assumption is wrong.

The 040 & 060 cpu can still run some of the 68882 instructions & emulates some of them, while vampire can run none of them and emulates all of them. If vampire could run all 060 or 040 instructions without emulation then this discussion wouldn't exist.

[psxphill]

So you should ask yourself why Britelite doesnt get any pushback when he makes posts.

WTF? You're suggesting that you give him an easy ride because of a personality contest. Nice.

And you praise kolla for his patience, which is kinda rich, given all he does is post negative comments.

If people didn't care then they wouldn't post what they wanted. The sycophantic behaviour just gets in the way of technical discussions.

[psxphill]

Hardly, because then it wouldn't be able to get one clock cycle for elementary arithmetic instructions .

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

However, from what I know, I afraid that this is only a 64bit FPU, i.e. results may differ from the full 80 bit implementation Motorola provided. Again, "in typical applications", this may not make much of a difference.

Which means it won't bite you in the ass until it's too late.

[psxphill]

There's no point in any technical discussion with you or Kolla.  Several people who are much more technically inclined have engaged you both and shown your rants and arguments to be fallacies and slander, yet you persist....

That is a lie. Nobody technically inclined has engaged and all I get is rants and arguments from those who do.

You must be a Trump supporter.

[psxphill]

Nice to see the clarifications regarding precision.

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 (unless they just did "rename FEMU FPSPcode").

"Those instructions are handled using some optimized FPSP code.

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

I'm not against emulation at all, I consider Apollo an emulator after all, I just want it hidden from view so that it is 100% compatible. So that Vector is a problem to me.
It's not like you need it to be user visible.

So still some time to wait for them to figure out that 100% compatibility is the way forward, who knows what will actually get released though.

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

[psxphill]

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.

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

In thirty seconds you could break it by overwriting the FPSP Vector. Real hardware won't care, Apollo will fail to run certain instructions.

I don't actually care whether it uses emulation, I consider Apollo an emulator after all. But that FPSP vector is a problem. If he hides it so that it's no longer visible then that would be fine. Ultimately I'd like to see it compatible with FPSP 040/060 packages, they are software after all.

64 bit precision might not worry you or the beta testers, but it's not 100% compatible. Maybe it runs most scene demos fine, they admit that is all they care about. If they run out of FPGA space and they have to drop down from 64 bits (which they say they might do) then I'm sure they'll start caring less and less about scene demos as well. I also made it clear that I accept the FPGA is limited, which is why I explicitly pointed out that current FPGA isn't for people who want 100% compatibility & it's definitely worth waiting.

Your response is an indication of Apollo trolls. I guess we have to keep putting up with you until Gunnar accepts to make it 100% compatible by hiding the floating point software emulation and the new FPGAs are available.

Of course we'll go back to the MMU and having to listen to all the reasons we can't have a compatible one, then one day magically it will be a good idea after all.

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

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

[psxphill]

The Vampire is using a SUB_SET of the full Apollo core because it is using a smaller FPGA and so features were removed.  As described in a link a page or so ago, some reworking was done to make space for an FPU in the Vampire accelerator board.  No sacrifices will need to be made for future boards with larger FGPAs.

Alot of the discussion lately is when I was criticised for wanting to wait for a large FPGA.

you (and obviously kolla) do not understand what the project is about... it is not about a 100% compatible FPGA based excelerator

Why am always being told it is 100% compatible?

Then, Jari came up with the will and the competence to make FEMU.

Because he got tired of the bitching. I still remember the times that Gunnar said we don't need a 68k compatible FPU.

[psxphill]

No one apparently has asked you to produce your ID unless of course you really ARE Kolla.

Are you seeing things? it WAS Kolla that posted about the ID card.

I was blocked from posting unless I send copy of an ID card, but why would I trust them with that kind of information. And... what misinformation specifically?

[psxphill]

Exactly!  He had multiple accounts over at the Apollo/Vampire forums which is why one would suspect the same here.

Kolla posting something about Kolla is not proof that anyone else is Kolla though.

You seem to be jumping to conclusions.

and even admit that the Vampire/Apollo moderators asked you to produce your ID, which you refused to do.

What is that an admission of? Is he supposed to be ashamed that people online creepily asked him for photo id? It sounds more like victim shaming.