FPGA Amiga

[Niding]

Thanks for your reply!

Again, as a enduser, I actually enjoy the "bells and whistles", but we obviously have different uses for hardware, and the perspective decides how we view it.

Thanks for all the beautiful demos you have developed over the years

[Britelite]

Again, as a enduser, I actually enjoy the "bells and whistles", but we obviously have different uses for hardware, and the perspective decides how we view it.

I fully understand you, as an enduser I would also of course want as much bang for the buck when it comes to hardware. It's just a shame that most of it will most likely be left unutilized (with the exception of previously mentioned datatypes, libraries and rtg/ahi-drivers).

Thanks for all the beautiful demos you have developed over the years

And there's still more to come

[kolla]

Maybe a similar reactionpattern can be attributed to a team like Apollo, that has spent xx hours producing this product, only to have xyz people tell them its not good enough etc.

People told him way in advance that it was not the right way to go, but he chose to do it anyways.

[Niding]

Right way for who?

Again; depends on what you want from the hardware.

[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.

[kolla]

Right way for who?

For everyone, hardware developers, software developers, coders, hackers, endusers, old software... but no, he had to do it his way, and alienated many initial supporters in the process.

Again; depends on what you want from the hardware.

As an end user, I just want it to run my existing software in a satisfactory manner, as of yet, it does not.

[kolla]

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.

Who is disturbed? That is what he said he does, as do almost all coders and developers, they ignore the Apollo Core features. Nothing disturbing about that, is there? :hammer:

[psxphill]

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.

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.

Maybe there are people who want to be fluffed into a gigantic orgasm by an FPGA board. It seems ok for whdload and doing it's own thing, but it's kinda expensive for that.

[Britelite]

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.

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.

So, it's just easier for me to save the hassle and ignore the Apollo Core altogether, also considering there's really no interesting Apollo-exclusive software available.

[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...

[Britelite]

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.

On the CPU-side I don't think it would be much of a problem, 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.

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.

To be honest, I have way more trust in WinUAE than in any reimplementation. Mainly because the goals are different, WinUAE tries to be as close to the original hardware as possible where as Apollo Core wants to be compatible but also add a lot of features.

But I feel this conversation isn't moving anywhere, the Apollo Core in it's current form just isn't for me.

[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.

[psxphill]

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 don't know, how many times are you going to trot out the lies?

Because gunnar is pretty clear that he isn't going to deliver the features I want.

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.

Well, it's not compatible. In very important ways, apollo is not compatible. That is just an easy one for the weak minded to understand.

[grond]

Thanks for proving my point...

[Chucky]

Being fully compatible BRINGS the bad things aswell.. like the crashes you are talking about.. as you might know.  Amiga software is pretty often actually to be honest much badcode..  extremly much. so you never know what it expects etc etc.  so if it behaves different. some code might also execute wrong.

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..

(even if there ARE better ways of detecting the 060. this was however one example how it could be)

so for me. .FPGA must be EXACT.. or not at all :-/