To Vampire or not

[grond]

Do you guys really believe it takes your input to make a professional CPU developer and long-time Amiga user understand the value of a compatible FPU or compatibility with as much of the Amiga software catalogue as possible?

If so, you must have a strange idea of the level of intelligence, dedication and hard work it takes to develop a CPU as complex as some post-Pentium Intel CPU which usually were developed by a team of more than thousand engineers. And the FPU is STILL not done, what is Gunnar THINKING!!!

[grond]

Yes, there are incompatibilities, and it is not just the FPU. As time goes on, and there are more and more users, more and more incompatibility issues will appear. I do wonder how "the Team" will deal with this, as Gunnar is all about moving forward and leaving whatever compatibility issues behind, for the sake of performance.

So you see incompatibilities, yet fail to put the work into making clear-cut bug reports with small snippets of example code that invariably lead to crashes? Why do you then expect somebody else to hunt ghosts? 99% of the alleged incompatibilities are just bad demo or game coding or long standing bugs and software mismatches that now get attributed to the Vampire. There surely are bugs in the core. Hardly anything man made is perfect. Go read the Silicon errata for the various 68k processors out there.

Even a reproducible crash in a specific place of a program like a branch into no-man's land isn't enough to find a CPU bug because the real problem could have happened millions of instructions before. The Team you like to put into derisive quotation marks has been working in their spare time and provided hundreds of test cases and has found dozens of bugs in the CPU. And we paid for our Vampires just as you did. But you rather take a comfortable position as a big-talking paying customer demanding bug fixes and features. You are what we called a leech back in the Amiga coding days.

[grond]

Maybe advertising the FPU before it is ready is a bad idea then?

You are constantly confusing the Apollo Core with the 080 in the Vampire despite the fact that you have been told several times that there is a difference. And yes, you have managed to find a couple of quotes where the two were confused by Gunnar himself. Congratulations.  Again: the Apollo Core does have an FPU. If you are looking for a softcore to license and for some reason don't want to use an ARM, PPC or whatever-softcore, you can ask Gunnar for a quote. And you can have it with ColdFire-compatibility or without. The 080 in the Vampire is derived from the Apollo Core which doesn't mean it is identical to it.

[grond]

Yes, I do not work for "the Team", correctly observed. It is my understanding, as your answer also suggests, that only clear-cut bug reports containing code snippets is what matters. Meaning that if the program failing is proprietary, one would go through disassembling the binaries to find snippets, or what?

What do you think we team-members-without-quotation-marks do?

I'm pretty sure with your interest in unixoid operating systems you are familiar with other projects and how "bug reports" like "it crashes" and "when will feature X be implemented?" are treated there.

[grond]

Sounds like you got a weasel lawyer to come up with that one. Using that argument completely destroys any hope that the project could ever produce something that I would want to buy.

Well, then please understand that before the Vampire 2 there was a Vampire 1 and that had (as an alternative to the tg68 it came with) another core that was derived from the Apollo Core. Because of space constraints of the tiny FPGA it was single-scalar and only had partial 020 Support (and, of course, no FPU). How does this fit with your approach Apollo Core == Vampire core?

[grond]

Because frankly that interests me more than Vampire, particularly if they have some Coldfire compatibility (although who knows how they address overlapping instructions).

 It's likely an either-or option. Perhaps you could ask for a hardware switch. I'd suppose that's just a matter of the license contract and the moneys involved.  

And, if there were issues with the core's fpu, how reliable is the Apollo core as a stand alone?

 I'm not sure I understand. You mean you suspect that the Apollo Core is not as thoroughly debugged as a softcore you would license from ARM Ltd.? That could well be.

[grond]

BTW - You don't know which Coldfire family they are targeting, do you (V1, V2, etc.)?

Unfortunately not.

[grond]

How is work progressing on adapting the core to an '020 socket?

No such project. The v1200 would not connect onto the processor like the v600 does but to the A1200's expansion port. AFAIK the core is preprared for 32bit access to chipmem/Amiga-bus.

[grond]

Vampire 2 had a bigger FPGA, so it didn't need to use the cut down Vampire 1 core. That doesn't really help whatever it is your argument is.

My argument is that Apollo Core != Vampire Core. E.g. Apollo Core is three-way superscalar while the core in the Vampire is only two-way superscalar. The core in the v2 is (again) just a core derived from the more feature-complete Apollo Core but better debugged and more thoroughly tested. Thus, it is correct to say that the Apollo Core has an FPU while the core in the Vampire has none. It's like "pro" and "consumer" level variants of a product.

[grond]

http://wiki.apollo-accelerators.com/doku.php/faq


What does this mean then?

You are quoting from a site that is run by somebody as a free service to the project. I'm sure you know how to find out who it is and that it is not Gunnar. The information you quoted is inaccurate to say the least. You know that as well as anybody else. I wouldn't believe you that you didn't know that there was no FPU when you ordered your Vampire cards and that this misinformation tricked you into buying two of them.

The Vampire cards are Igor's product, Gunnar just provides the core for them on a voluntary basis. I understand that under normal circumstances a customer would not have to care about the internals of this entire project but nothing about this project and the market surrounding it is normal.

[grond]

People don't grasp that the FPU Gunnar wants is not the FPU found in 060, 040 or 68882 - he wants to build a new one, his own super duper FPU that only works with software written specifically for it. Like AMMX. No support for existing compilers, only assembler. And he wants someone to step up and write a killer app for it, so its superiority can be demonstrated.

You understood that right but draw the wrong conclusions. If you have a superfast FPU in hardware, it is easy to map the standard FPU to it. If you do the standard FPU first and then the superfast FPU, it will mean double work.  The prioritisation of the AGA implementation over the FPU also has a lot to do with the stand-alone coming out soon.

[grond]

Actually, not quite so. The problem is that the FPUs that come with (some) FPGAs are only 64 bit FPUs, but the Motorola FPUs are 80 bit wide.

Well, your statement doesn't negate mine, it renders it more precisely as I made the statement without explicitly stating that the legacy FPU mapped onto the new FPU Hardware would then, of course, only have 64bits of precision.

For most applications, this will not make much of a difference

AFAIK UAE maps the Motorola FPU instructions to the corresponding Intel processor instructions which have 64bit precision at most and nobody has ever noticed any problem with any Amiga FPU software. 64bit of precision is still an awful lot. I think it is safe to assume that the lost 16 bits of precision will not make any difference at all.