AGA integration in Apollo core : work in progress

[grond]

Originally Posted by meynaf

and you forget that the CPU can't use all available memory bandwidth, while DMA can use a lot more.

I don't forget anything, your statement is just wrong. The core in the Vampire can saturate all available mem bandwidth. And there is no technical reason why a CPU would not be able to do so if a DMA controller running in the same chip can.

[OlafSch]

@meynaf

Point me anywhere where compatible MMU was promised. I can remember several times that Gunnar stated the opposite. FPU is still on to-do-list but not top priority

What you and others might interpret somewhere is not important

Again WHDLoad is no MMU application. Claiming that would be misleading to average users. MMU is used for debugging with certain already mentioned tools and you would need it to run certain alternative OSs

[daxb]

Originally Posted by idrougge

Come on, be realistic. How many applications use an MMU? Can you name any?

In my S-S they are at least three commands that make use of MMU. Then ShapShifter + MuEVD and of course the other MuTools. The Mu#? debug stuff is very useful (I caught hundret of bugs over the years) but only used by a few people. Maybe virtual memory programms? We know most software doesn`t need MMU but that is just normal. It is what it is. Of course that is not an argument against MMU rather for that. MMU wasn`t introduced from the start so it isn`t supported widely. If hyperthreading is useful, why not.

[meynaf]

Originally Posted by TrashyMG

@Meynaf, why do you care? just don't bother with it.

And why do YOU care ? Show the example, just don't bother.

Originally Posted by grond

I don't forget anything, your statement is just wrong. The core in the Vampire can saturate all available mem bandwidth. And there is no technical reason why a CPU would not be able to do so if a DMA controller running in the same chip can.

I remember Gunnar stating otherwise a long time ago.

But i'll follow your argument and then tell you there isn't any more bandwidth available for SMP...

Originally Posted by OlafSch

@meynaf

Point me anywhere where compatible MMU was promised. I can remember several times that Gunnar stated the opposite. FPU is still on to-do-list but not top priority

MMU maybe not, he promised some "equivalent" functionnality years ago (whatever that means).
But the FPU is a sure thing, and this page still mentions it, which is plain wrong right now :
http://apollo-core.com/index.htm?page=features

Originally Posted by OlafSch

What you and others might interpret somewhere is not important

Yeah i know you don't care about what others have to say, you don't need to repeat it.

Originally Posted by OlafSch

Again WHDLoad is no MMU application. Claiming that would be misleading to average users. MMU is used for debugging with certain already mentioned tools and you would need it to run certain alternative OSs

Sorry, but Whdload IS an MMU application. The fact it's not mandatory changes nothing. It has the option to make use of the MMU, period. Read the docs if you don't believe it. I used it a lot on my B1230.

[demolition]

Originally Posted by OlafSch

regarding MMU that is exactly the problem. How devs admitted themselves it would slow down the core and for users it makes zero difference. It is only useful to use certain debug tools when you are a developer.

For users to embrace the Vampire, we need many developers or there will be no new awesome software made for it, so that means it is necessary to cater to those developers in any way possible. Even though an MMU does not directly help end users, it will indirectly benefit all users since it is a great tool for debugging. For WHDLoad+MMU, it simply means that the system will be more capable of catching invalid memory accesses before they cause problems with the system, thus a bug should be much less likely to take down the entire system when it crashes.

[TrashyMG]

Originally Posted by meynaf

And why do YOU care ? Show the example, just don't bother.

Because I'm a vampire user. You're inventing issues based on assumptions on how you perceive things work, yet it's clear you haven't done the research nor care to, your just churning drama when there really shouldn't be.

[meynaf]

Originally Posted by TrashyMG

Because I'm a vampire user. You're inventing issues based on assumptions on how you perceive things work, yet it's clear you haven't done the research nor care to, your just churning drama when there really shouldn't be.

Nope. I'm just telling the truth. You forget i used to be a team member so i know quite a lot of things the vampire user does not.

[grond]

Originally Posted by meynaf

But i'll follow your argument and then tell you there isn't any more bandwidth available for SMP...

Playing games again badmouthing Vampire although you should know better?

The main thread could run from cache while the secondary thread could saturate the memory interface. No problem there. This plus you again fail to point out a significant difference between a secondary CPU and a DMA controller that would favour the DMA controller. Why would the DMA controller not be limited by the memory bandwidth but a second CPU would? Again no sustainable argument from you why a CPU would not be ≥ a DMA controller.

[TrashyMG]

Originally Posted by meynaf

Nope. I'm just telling the truth. You forget i used to be a team member so i know quite a lot of things the vampire user does not.

Ah so that explain the venomous attitude you have and why you're churning a toxic attitude in this forum towards the Vampire well and to Apollo Core team.

[StingRay]

Originally Posted by OlafSch

Again WHDLoad is no MMU application.

Well, WHDLoad uses the MMU quite extensively! It's a must to have an MMU equipped machine for every serious WHDLoad developer. So while WHDLoad of course works without MMU it is not correct that it is a "no MMU application"!

[TuKo]

Originally Posted by meynaf

Nope. I'm just telling the truth. You forget i used to be a team member so i know quite a lot of things the vampire user does not.

[meynaf]

Originally Posted by grond

Playing games again badmouthing Vampire although you should know better?

The main thread could run from cache while the secondary thread could saturate the memory interface. No problem there. This plus you again fail to point out a significant difference between a secondary CPU and a DMA controller that would favour the DMA controller. Why would the DMA controller not be limited by the memory bandwidth but a second CPU would? Again no sustainable argument from you why a CPU would not be ≥ a DMA controller.

DMA has been invented for a good reason.
And hyperthreading isn't exactly a second cpu.

Originally Posted by TrashyMG

Ah so that explain the venomous attitude you have and why you're churning a toxic attitude in this forum towards the Vampire well and to Apollo Core team.

What you wrote here is just disgusting and has been reported to moderation.

[meynaf]

Originally Posted by TuKo

Yes i'm telling the truth and you can be contemptuous if you want, this won't change.

[TuKo]

No, I'm not contemptuous. I'm also telling the truth and maybe also playing the same stubborn game.

[grond]

Originally Posted by meynaf

DMA has been invented for a good reason.
And hyperthreading isn't exactly a second cpu.

Then tell us the good reason. I will: transistors were sparse and nobody could imagine having two or more CPUs on a single chip.

Again trying to argue against today's technology with 1980s technical arguments. And again zero sustainable technical arguments from you.

[Signman]

Originally Posted by meynaf

Nope. I'm just telling the truth. You forget i used to be a team member so i know quite a lot of things the vampire user does not.

Looks like somebody is mad because he was kicked out of the treehouse.
Give back your decoder ring.

[DamienD]

<sigh>

Here we go again. I really, really, really don't have the time to be trying to clean up this constant fighting. I have enough to do on EAB already.

I do not and will not take sides but it's a moderation nightmare, how does one even attempt to control this mess

...and please people, don't be reporting each others' posts when one person says something that you don't like and then you retaliate and a flame war ensues etc.

Again, if you cannot get along I will just close the thread as I don't have hours free to deal with this constant shite.

Last warning to all involved, keep on topic without name calling / fighting etc. We as Global Moderators have discussed this, if it doesn't stop then we will start giving repeat offenders 1 / 2 week bans; unfortunately there's nothing else left to do...

[grond]

Originally Posted by DamienD

Again, if you cannot get along I will just close the thread

That's obviously the plan: if you can't stop the product, you can at least stop the threads about it.

[demolition]

Originally Posted by grond

Then tell us the good reason. I will: transistors were sparse and nobody could imagine having two or more CPUs on a single chip.

Actually, SMT was thought of all the way back in the 50s and was a part of the design of the IBM ACS-360 (https://en.wikipedia.org/wiki/ACS-1). Although this project was never finished, it shows that it is not a new invention. For a long time it probably made the most sense on mainframe systems rather than in personal computers since as you mention, transistors were expensive.

[DamienD]

Originally Posted by grond

That's obviously the plan: if you can't stop the product, you can at least stop the threads about it.

Maybe, maybe not... Again, we are not taking sides.

Anyway, just cleaning / closing threads hasn't stopped this issue from constantly re-occurring so, as mentioned above, we will be trialing a different method until things improve... and that's handing out bans

No more warnings to all involved, you will just receive a ban. End of story!!!