in case you are interested to test new fpga accelerators for a600/a500

[wawrzon]

I am continuously surprised at the politics, it all seems a bit unnecessary to be honest.
/Mike

so since everybody is a bit sensitive about their projects and surprised about the politics, can this be considered settled in order to start over in mutual respect?

[wawrzon]

Wow, so I'm supposed to magically know that?  I really don't care if I scare Thomas or Thor or whatever he calls himself, away from this project.  With help like his, Gunnar and his project don't need any enemies!  Thomas/Thor has been the most vocal detractor of this project via this thread.  Scaring him away might be doing everyone a favor!

you could inform yourself to whom are you talking to and adjust your tone. and now good luck to continue to do your best to drive people who put work on this project apart.

[wawrzon]

On the one hand side he is afraid that new instructions would kill split the community
and that this would kill AMIGA - on the other hand Thomas did ask for special instruciton to decode JPEG faster.

i think thomas is generally sceptical about added instructions at least before a full stable 020 compatibility is achieved. not sure if any of us is totally against it. he just mentioned an example what would be useful from his point of view, if it is unavoidable.

[wawrzon]

lemme comment quickly on subject of "fragmenting the community". because i think it really is an issue.

we have now four main camps everybody knows about and none is particularly happy about the split: amiga, morphos, os4 and aros.

then on amiga we have different 68k cpu versions there is a lot dedicated optimized software versions for. which is pain in the back, because its likely that users are using wrong software versions on wrong cpu and dont know what goes wrong. this is certainly annoying.

then there is aros with all the supported platforms. good thing about is that whatever gets into the repository it is built for all platforms mutually. but all other contributions must be compiled for every platform separately.

now, we have exotic niches like warpos. just as we speak there is an (interesting) project to get warpos working on mediator/sonnet setup i have already pointed to before:
http://eab.abime.net/showthread.php?t=76633&page=3
it is all fine but this is just another incompatible binary platform.

another example is aros68k. although it executes amiga software and aros68k hunk binaries should run natively on amiga except they are linked against aros exclusive libraries, everything else would have to be defined as just another separate platform when putting it on, lets say, aminet.

taking it all into account, even though i am one of very few open aros68k supporters, my concern is to find a lowest common denominator to achieve maximal gain with a minimal effort for all or most these platforms. im not trying to prevent anyone from anything, just placing food for thought in this context.

[wawrzon]

but isn't this project in alpha stage anyways? Wouldn't there be multiple core versions that will meet everyone's meet in the long rung?

i hope the subsequent versions of the core will improve upon each other. what i definitely do not like to see, would be different incompatible versions of the core to address different expectations. some compromise gotta be found.

[wawrzon]

I discovered in OS 4.1 that 128 MB is nothing...

i see everybody is buying os4.1fe to try it out on uae and discovers that it is about unusable. funny. the same people could get aros68k, which is for free, can use almost unlimited amount of ram and unlimited screen resolution under uae, and discover, that 128mb ram is already plenty with the same or better features as are impossible to reach on os4. css web browsing to name just an example.

in short: as thor said above, the 68k code is more efficient, at least when it comes to memory usage.

[wawrzon]

I find it interesting that noone has bothered to test out AROS/m68k on Vampire600 yet.

they did before the core gained 020 extensions. which didnt run, and therefore led to discovery that aros68k, even though compiled for plain 68000 target, had an asm inline containing an 020 instruction by oversight. toni found and fixed it. i think this is already some positive outcome of collaboration on the aros68k/apollo front.

i dont know though why they didnt come any further with it, or if they did, why the did not communicate it.

[wawrzon]

There are developers assigned to the 68k GCC backend but what they do is usually minimal maintenance. It wouldn't hurt to try inviting them to participate. As far as BSD/Linux 68k developers, there aren't very many active 68k developers and most need an MMU (ThoR and Frank Wille could give some insight if they were interested).

radoslaw k. (strim) is netbsd developer and maintainer for amiga. he is a talented driver coder, provided wide pool of support for specific amiga extensions including mediator boards and zorro cards. would be worth to attract, but
1. he is critical about closed source, he mentioned it to me in context of apollo core.
2. he has other own hardware projects and in particular a concurrent sonnet warpos driver project i mentioned above.

[wawrzon]

May I ask which software you currently use that goes down to the MMU directly?

some versions of voodoo warp3d drivers? maybe shapeshifter for updating the display..