FPGA Amiga

[grond]

That is an incredibly low bar.

Like: I can sing better than Elvis (because Elvis is dead).

Um, it's more like "nobody sang better than me since Elvis was still alive, no?

[grond]

No, because other people make computers. Nobody has been selling Amiga's since the 1990's because they were dead, like Elvis.

Well, he wrote "units", not " Amigas". But yes, I noticed other computers have been produced since 1994. So I guess it's more like "nobody has sung 'Love Me Tender' better since Elvis's death"?

[grond]

new stuff. why? then they can just go to shadertoy and do something there.

Yes, for them it would be like training for a 500 metre run: it's no olympic discpline, so why bother?

[grond]

so why even bother using valuiable LE space with stuff never getting used.

Because Gunnar likes doing it. This is a pasttime. If it weren't fun, it wouldn't happen.

[grond]

The order in which things are done does not depend on the date the reimplemented feature was first publically available (like doing MMU and FPU before AMMX because the 68k MMU and FPU predate MMX) but in which it makes sense from a technical point of view. E.g. if you create a new vector-FPU first, you can then use it to implement a 68k-compatible scalar FPU on top of it. So in this example you get the "who will ever use it"-FPU first and then the 68k-compatible.  If you first did a scalar FPU, you would have to scrap it when you start working on the vector-FPU. The same goes for AMMX and the 64bit mode: a part of these is the basic infrastructure on which the FPU and some bitfield instructions (which need an ALU wider than 32 bits!) are based.  This has been pointed out many times before but the same arguments repeat like the aforementioned broken record...

[grond]

so why even bother adding new stuff instead of perserving what we got?

Um, see above: because it is fun. Recreate what was already there: boring. Do an entirely new 68k CPU that implements what likely would have happened if Motorola had continued to develop the 68k CPU family: fun.

And even if nobody else uses new features, the Apollo Team members are using it.

[grond]

Brit Elite, while I find most of what you write very reasonable, I don't understand why it disturbs you that the Apollo Core has some features the 060 does not have. You can safely ignore their presence.

[grond]

It's not so much disturbing, I just wish he'd implement the important features so that I could justify buying one rather than all this fluffing crap.

How many times has it been pointed out that the "important features" are just stripped down and limited variants of the "fluffing crap" and that implementing the "fluffing crap" makes it easier to then implement the "important features" deriving them from the "fluffing crap"? I guess this is just too complicated for some to understand...

[grond]

Let's put it this way, if I were to use the Apollo Core for development (as in doing stuff for 68k machines in general), I would constantly have to double check that everything actually runs on a real machine, as there's always the chance that something doesn't behave exactly like on the real chipset (I had to do the same years ago when I used an AGA-machine to develop OCS-stuff). Being able to disable ALL additional features would of course solve this problem for me.

I'm not sure it would solve the problem. It's not that you would accidentally use RTG-chunky instead of bitplanes or use ten bitplanes instead of eight or whatever. You wouldn't accidentally use 080-only processor instructions either.

The problem is that you would have to trust the reimplementation to be true to the original. The same happens with WinUAE and the real hardware. Although tested and enhanced through many years of work, there still is a need to double-check on the actual hardware if you are really squeezing out the last DMA cycle out of your code targetting unexpanded OCS. But WinUAE has earned a reputation and thus a certain level of trust. I'm confident that the Apollo Core will earn a similar level of trust within the next years. Time will tell. BTW, the Apollo Core Team has found and reported several bugs in the CPU emulation of WinUAE so I think we are closer to the real deal than even WinUAE in at least some parts of the entire job to be done...

[grond]

but if SuperAGA has any overlapping bits/registers compared to real AGA (for example, using unused bits in the current registers), then there most certainly could be problems. Adding a RTG chunkybuffer is not a problem, but reimplementing AGA with added bells and whistles is, at least for me.

OK, I understand. AFAIK new features are using new register addresses in the hardware register address range. I am not aware of any reuse of bits within existing registers but I am not 100% sure. But I'm confident that, with the intention of reaching as big a compatibility as possible with a much faster new processor, care will be taken to avoid such possible conflicts. But yes, that doesn't mean there cannot possibly be any at all.

Anyway, thank you for explaining your point of view which I consider a very well reasoned one. It is a nice break from all this "it must crash the same way as an 060 otherwise it isn't compatible" stuff I have been reading for a long time from others.

[grond]

Thanks for proving my point...

[grond]

say they test "ok do we have a 040 or 060?"  and they test an instruction that exists on the 040 but not on the 060..   and "OK"  this instruction exists.  then we are a slow 040..  lets do this routine instead of the nicer 060 code..

and voila.  result is not as expected

And what damage is there? The 080 will execute both 040 and 060 optimised code faster than any 040 or 060.

[grond]

Oh, and yes, it is not a company doing this so expecting the project to be run like Motorola would have done it is a bit silly.

Obviously you have no idea how much work has went into it but all you can do is demand it should have been more like documentation, compiler support, MMU blabla. Must be really nice to sit in your comfy chair by the fireplace and explain to the world how things should be done...

[grond]

When I use Vampire systems, it's like using a broken UAE setup, there is speed, but software often crash in obscure ways and behave weirdly. And the speed is not really _that_ great either. On the MiST, with a few exceptions, things work consistently, and as expected.

Sounds like you have contact or power supply problems.

[grond]

I doubt it, since it is not related to one system or one power supply.

If it is not the power supply or a loose connection of the Vampire to the Amiga mainboard, then it would seem your Vampire is faulty. On the recent cores like Gold 2 and 2.5 the Vampires are 100% stable unless, you know, the obvious: MMU and FPU software. You might want to contact your seller about the card.