You know, there are some of us who agree with Kolla and don't see the need for all this defensiveness about the Vampire.
I, for one, want a compatible CPU, FPU and MMU. I don't see gcc being adapted for the special instruction set of the "080", particularly since the instruction set is still changing. Likewise, there's no way anyone is going to spend even a tiny bit of work caring about the special case of an "080" for LLVM - all energy is going in to generating code than can run on real m68k chips. If an emulation or an FPGA implementation can also run code that runs on real m68k chips, then great!
All this talk about memory controllers requiring a different kind of MMU is bull. You're conflating issues. A memory controller needs access to things that an MMU needs to do, but this does not require a reinvention of an MMU. There's no good reason whatsoever that an m68k compatible MMU can't also support the needs of a memory controller (or multiple controllers) without making the MMU incompatible from the point of view of the running OS.
What I'm getting at here is that there are all of these apologists for the Vampire that are pretending that there are reasons why a non-standard MMU and non-standard FPU are somehow "necessary", when it's nothing but bull. What each and every apologist here is missing is how this is going to mean the Vampire will miss out on helping with real projects such as gcc, LLVM, and all the cool tools and software that come with a proper suite from each of those.
Also, there's no good technical reason that I can imagine or have seen here or anywhere else that suggests that anything but a superset of the m68k instruction set is necessary. Add features all you want, but trying to say that they have to come at the expense of compatibility is specious at best and willfully ignorant at worst.
Kolla has a tremendous amount of patience to deal will all of the apologists. I'd have given up a long time ago. I don't even have anything else to add here besides this until there are Vampire options that can run m68k code properly. It's of interest to me personally when I can run NetBSD on it and work on testing toolchain issues.
One day, we'll make another ixemul library based on modern NetBSD and we'll again have a way to compile and run lots of free and open source software on AmigaDOS.
There is absolutely nothing wrong about having reservations about anything, in this case, the Apollo Core. Britelite for example has laid out what his concerns are without feeling the need to kick sand in the eyes of the developers. I grant you that there are Apollo supporters that resort to personal commentary, just like some people do the other way. Thats not helpful ofcourse.
8bitguy has been in the IRC channel, and said flat out that Vampire wasnt for him (atleast currently), and the obvious question came from someone "what are you doing here then?". The reply "we all like to chat about technical aspects of anything amiga right?
" And that put that to rest.
So you should ask yourself why Britelite doesnt get any pushback when he makes posts.
And you praise kolla for his patience, which is kinda rich, given all he does is post negative comments. Thats not really hard to do. If he was working on a project that kept getting hammered with negativity, and THEN kept on working and replying to forums, then I would be impressed with his patience. But thats not the case.
I remember when FEMU was in its first stages. The performance and visual quality was less than stellar, and certain people just had run victorylaps onto that fact. Jari/FEMU didnt even bother replying on forums, instead hes been steadily improving FEMU, and from Gold 2.7 and 3, the performance looks greatly improved.
And then there is the whole WORK IN PROGRESS part, that people seem to be missing constantly. There is only so much x people can do. Jari joining with his FEMU/FPU work accelerated that aspect of the core, which is great.
Lastly; its not my project. If I want "true" legacy accelerators, there are several options for me. Ive decided to give Apollo my bucks, but those that decide for other alternatives are not any more wrong or right in their decision. Its what make your userexpirience best for your needs that counts.
Either way, I dont feel the incessive need to kick sand in the eyes of the developers. Take a cue from Britelite about how to approach feedback, if anything.
