Gold 2.7 release for the Vampire accelerators

[nicholas]

A C64 is just a simulation of a Turing Machine.

Amiga OS4 is an emulation of Workbench 3.1 eh?

[nicholas]

But what exactly does the Turing Machine simulate? And what has any of this to do with the recent release of a firmware update for the Vampire?

Absolutely sod all. The ASD on this forum is strong though.

[nicholas]

There is a Gold 2.8 release coming soon.

The biggest news is that it enables use of the expansion port.

More info here: http://www.apollo-core.com/knowledge.php?b=6¬e=13305

What's the latest news on a vampire for A3000/4000?

Still far away?

[TrashyMG]

You know nothing, Jon Snow....

Did someome try Lightwave with the updated core?

Yeah it works fine,

Away from home so can't make my own video yet.

But here are some youtube links:

https://www.youtube.com/watch?v=qSrnbSjsSnE
https://youtu.be/pyyCnH8Uy7c?t=203

[midway]

Cool ! thanks mate

[AmigaOldskooler]

Thanks to the team for update 2.8. Installed it today. Works great here so far! Love the Vampire! Made a blog-post about it was well. Sorry for bad sound in the vids. Both caught with my mobile phone.

https://oldschoolgameblog.com/2018/03/18/installation-of-the-gold-2-8-core-on-vampire-v2-500/

[kolla]

Works great here so far!

Is it "spreadsheet compatible" yet?
What does Calculator say that 1.1 - 1 is now with Gold Core 2.8?

EDIT: Never mind - did it myself...

[sean_sk]

This can be fixed by turning off FPU in CLI.

I mentioned about this to a friend of mine who is a programmer and he said that this kind of thing is quite common when it comes to floating point calculations and is unsurprised by it. He comes across this often when programming. He referred me to a couple of links regarding this, although they primarily relate to Python.

http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm
https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate
https://docs.python.org/3.4/tutorial/floatingpoint.html

[kolla]

This can be fixed by turning off FPU in CLI.

That is not a fix, but rather a work-around. Also, I have not found any way to let the "FPU" be permanently off, using VControl to turn it off causes a reboot into "FPU less" environment, but on next reboot, it is back on.

I mentioned about this to a friend of mine who is a programmer and he said that this kind of thing is quite common when it comes to floating point calculations and is unsurprised by it. He comes across this often when programming.

Nobody is surprised, this type of incompatibility was expected all along, and they should be taken care of. I suppose Apollo Core specific math libraries would be another work-around, though it would not help for programs not using them. Best would be if this was fixed in the core itself.

[psxphill]

I mentioned about this to a friend of mine who is a programmer and he said that this kind of thing is quite common when it comes to floating point calculations and is unsurprised by it.

Right. It's unsurprising that if you calculate the values differently to how the 6888x and 040/060 fpu calculate it, that you would get the wrong values.

He comes across this often when programming.

On new software you can add workrounds in the source to make it work right when you recompile it using a different FPU (like using SSE instead of x87). When taking the same executable on different x86 cpus made by Intel or AMD then you'd expect the same result, or it's a bug that needs fixing (famously Intel did have a bug which they fixed and sent out replacement CPU's).

With old 680x0 software that you don't have the source for, it's not so easy to add workrounds and this particular situation really doesn't come up often when your friend is programming.

[psxphill]

Amiga OS4 is an emulation of Workbench 3.1 eh?

No, AmigaOS 4 is official. Therefore it's fine for marketing to say it's backward compatible with Amiga OS 3.1 as there is some lineage. The marketing department could decide to call it emulation, if they wanted to though.

AROS emulates the Amiga API. It's perfectly possible to emulate API's without doing anything that a machine emulator like dosbox/vice/uae does.

https://www.youtube.com/watch?v=cNlMIa-YOnM
https://archive.codeplex.com/?p=bemu

People who repeatedly use the narrow definition of Emulate make themselves look stupid. It doesn't mean a piece of software fetching opcodes and interpreting them, that is only one type of emulation.

There are so many uses of the word emulator that doesn't match the narrow definition, that I'm surprised you haven't heard of them. Terminal emulator, Hercules graphics card emulation, CGA graphics card emulation, sound blaster emulation. History is full of examples.

[Louis Dias]

This has happened on every platform (from C64 to x64) I've coded on and why in Windows I now use "decimal" instead of floats or doubles...

https://stackoverflow.com/questions/618535/difference-between-decimal-float-and-double-in-net

[kolla]

This has happened on every platform (from C64 to x64) I've coded on and why in Windows I now use "decimal" instead of floats or doubles...

And when you say "in Windows", you mean .NET, right?

How various floats are defined vary with the languages used, how the various languages used on Amiga will deal with this when running on AC68080 is anyone's guess I suppose. Is there even a way for software to know whether they are running on a "full" AC68080 FPU or just the limited, stripped down variant in the current Vampire boards? Is it clear exactly what kind of accuracy the Apollo Core FPU for V2 Vampires is operating with? I have only seen guesses by various programmers (alb42), the information on the "official sites" do not offer much insight. Is the current FPU implementation "done deal", or will it be improved upon further (aside from straight out bugs)?

In any case, we don't have the luxury of a thriving and active developer community on the Amiga, let alone commercial support from Microsoft and the like. What we have is a library of legacy software for which the source code mostly is lost or not available for legal /copyright reasons. And even when sources are available, porting them to current toolchains can quickly be a daunting task in itself.

[guest11527]

This has happened on every platform (from C64 to x64) I've coded on

Hopefully not. Did you notice that the result is just plain wrong? I mean, not only "off" by one ulp, but wrong?

and why in Windows I now use "decimal" instead of floats or doubles...

which, of course, doesn't solve the problem, but only masks it. You get other round-off errors, and in most cases, worse round-off errors because, internally, the system still works in binary.

What we have here is just a bug. Ok, that stuff happens, but I wonder where the thousands of test cases were?

[guest11527]

Right. It's unsurprising that if you calculate the values differently to how the 6888x and 040/060 fpu calculate it, that you would get the wrong values.

It does not matter whether it computes the values "differently" as long as the result is correct. It is not, so the algorithm is not only "different", it is just "wrong".

This does not require a workaround in third party software (why? Wasn't the point of this project not exactly *not* to depend on workarounds), it just requires a fix.

[UberFreak]

AROS emulates the Amiga API.

Nope, it implements it.
An API is just a set of functions, you don't emulate it, you implement it.
There can be multiple different implementations for the same API, but it has nothing to do with emulation.