Apollo Team announces the Vampire V4

[kolla]

An incomplete FPU emulation and a bad JPEG implementation working hand in hand. You don't need an FPU for JPEG.

I know, but legacy software being what it is, that is how it works.

I am more puzzled by the occasional 8000000B errors that sometimes may pop up during filesystem validation (FFS).

[kolla]

But who would buy a Vampire if it came with a core that is slower, but fully replicates existing 040 or 060?

[kolla]

The FFS certainly does not use the FPU. It goes through the utility.library for some 64bit math, though. The Guru is a line-F trap, though the long arithmetic is in line 4. Hard to say what goes wrong there.

Right. If I find time I may set up a card with whole lot of FFS and trash them on purpose, see if I can find some pattern in the behaviour. For now I use PFS3.

[kolla]

Umm...I would. :rtfm:

Yeah, same here. Then I would want Vampire for all my systems instead of just goofing around with it on a couple.

[kolla]

+1

A floppy port would be nice for replacing an old MB though.

Silly question: what prevents USB floppy drive?

[kolla]

There isn't a lot of this software as far as I know - most should have used the AmigaOS IEEE libraries which would have abstracted the problem of FPU-availability away.

It's an interesting experiment to remove the math libraries, and see how much stops working.

[kolla]

So what are the existing features?

[kolla]

it allows programs to run that would otherwise fail.

Or allows programs to fail that would otherwise not run

[kolla]

@QuikSanz -

The Apollo core does have an MMU implementation. However it is not backwards-compatible with previous Motorola designs.

It supports new features such as non-executable memory. This is pretty much an expectation of any modern MMU. The MMU has a "modern, forward-looking" design instead of being compatible with 20+ year old designs in the 68060 and earlier generations.

I am speculating that the MMU in Apollo Core is mostly used to move memory addresses around so that AmigaOS and its apps find what they expects at the addresses they expects. With multithreaded I/O-operatings, legacy I/O, DMA, SAGA and kickstart protection, it should be quite busy already.

[kolla]

No, it's exactly what was written.

Oh shut up, butthead, stop being such a dumbass - the quote was...

what many has been saying;

-I enjoy being able to run Workbench RTG/Thru HDMI without Indivision.

Niding was paraphrasing Vampire users, not stating an opinion.

[kolla]

It's very strange that people who say "buy it for the existing features" have no answer to this

Because there is no answer to this, there is nowhere to point for info.

[kolla]

Is it that hard to read about the features on the official site ?

And which site is that?

I thought http://www.apollo-accelerators.com - but Gunnar said information there is questionable at best, because it is maintained by volunteers outside the team.

Also - it not at all updated.

Or should Gunnar pay a visit to every Amiga user and draw it out to them ?

No, he should just maintain a relevant feature list, very much like
http://www.apollo-core.com/index.htm?page=features

The product page
http://www.apollo-core.com/index.htm?page=products
does not spell out features in any meaningful way.

[kolla]

I am sure you are aware of the HW features. You can read more about the softcore here: http://wiki.apollo-accelerators.com/doku.php/start

And you can always visit the IRC channel and communicate with the team directly....

... where Gunnar will tell you not to trust anything on the wiki you mention.

[kolla]

coldfire replacement? it isnt compatible at all, in the shape its tested and provided for amiga community? if it was meant as coldfire replacement why even bother for amiga compatibility?

https://web.archive.org/web/20150901065243/http://www.apollo-core.com:80/

Apollo is code compatible with the Motorola M68K and ColdFire families.

This was two years ago. Since then, the project has turned left and right and left again a few times, for various reasons. Maybe someone realized that his amazing new cpu was not so amazing after all? Maybe he realized that the embedded market already have 68k softcores that takes care of its legacy needs? Who knows.

[kolla]

Gunnar doesn't appear to listen to his market, the market is so desperate that they are listening to him.

The biggest challenge is attracting developers, people willing to commit to the rather big effort it is to move to a new 68k architecture. Gunnar has repeatedly uttered his frustration over lack of people interested in coding for him. He said this why there is no FPU - lack of interest from develeopers. But then he also says that they don't need any more people to "test" the FPU, and the few developers who did offer to help were shunned off because they rather want compatibility than new bling-bling, since new bling-bling means no support in existing developer tool chains, and assembler only. I wonder how long this situation will persist, if someone is willing to update the 68k backends for gcc and clang/llvm to support the Apollo Core - that would be a mile stone.

I also wonder if the Apollo Team has done _any_ research or survey among developers regarding what features they want or lack.

Anyways, if Apollo Core cannot offer the solution wanted, something else will show up.

[kolla]

It's simple. He is only wasting scarce resources on developing SAGA because he can't use code from minimig/replay because he's keeping apollo closed source for his intended commercial use.

SAGA is supposed to be open sourced at some point, maybe you can find a fitting speculation as for why that is?