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

[wawrzon]

@gunnar: who knows to whom i would be praying if i did;)

honestly i hope you wont get hit by a bus any soon;)

[wawrzon]

matt, he hasnt called you a liar. he simply suggested your info may not be up to date imho. that probably since they lack time to update online documentation, which would sure be more convenient than relaying on irc for communication, but then it all takes time.

[wawrzon]

There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores.  I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.

i agree on that, there is no detailed technical expertise to understand this problem.

however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.

@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.

[wawrzon]

@olaf
i hope the extension wont become a new standard as long as they are proprietary.

[wawrzon]

You're mixing two things here: Added speed (which is a forwards compatible extension) and extended ISA (which is not a forwards compatible extension). The added value of more speed is high. The added value of an extended ISA is low (who would use it anyhow, and if so, how?)

i think its possible that people will use it. the main problem imho is similar to warpos situation. its backwards compatible. you can run pure 68k code on it. but in order to gain advantage of speed you need to compile binary that wouldnt run on pure 68k system. the closed proprietary nature of the system led to its limited popularity and to the situation that support for available hardware like sonnet has been unavailable for decade and must just be  researched by the means of reverse engineering and full reimplementation. while in this situation being of little use, it added to drain the development resources, that otherwise might have been used for more common goal, even if this aspect may not be as dramatic at second view.

[wawrzon]

The new ISA will be documented at the user level. Implementation will be proprietary just as it was for Motorola.

im fine with that. though you will agree, that closed source nature of motorola cpu technology and them breaking compatibility by giving up on 68k isa has definitely contributed to amiga hardware being dead end?

[wawrzon]

negativity? discussion and feedback is necessary especially if we all want the project to succeed.

[wawrzon]

If you don't like it, don't use it or buy.  No one is forcing you to participate in testing or making you purchase it.  You obviously have a personal axe to grind based on some of your comments or you feel you could do a better job than Gunnar.  If that's the case, then put up or shut up.

you obviously dont know, that thor collaborates with gunnar on the project and contributes to it as he did to natami.

[wawrzon]

not every application needs full screen update in a high frame rate.

though if you want introduce incompatibility to begin with, then what is the point in a 68k type cpu. er than that it looks like similar road the amiga ppc offshots took, being able to execute old code but otherwise promoting completely new binary target. even faster would be probably to put there an x86 with 68k emu.

[wawrzon]

for those who dont understand: running mac emulation on phoenix/apollo core is merely just a test case. i dont think there is "whining". perhaps just a bit too much emotionality here and there.

edit:
perhaps the best thing is to get the test boards underway and let the project gain its own dynamic, which i trust due to reconfigurability of fpga and customer/tester feedback might take a good direction in the end. we have a very competent and well opinioned people on this project. lets face it, investments in a range of around 150.- are worth the risk. i would sure think twice if it was 500.-

[wawrzon]

@ferellsl

so you want to scare one of the main contributors like thor away from the project? are you going to take his place and develop support libraries? and if not, why dont you just hold your mouth or go using os4 or something like that, instead of alienating people here?

[wawrzon]

@kolla

the answer is so far i have observed, and no, i dont know for sure, that apollo core has not yet run p96, mac os emu or os3.9, because there may be bugs with addressing modes yet to be found. but im pretty sure this will be solved.

[wawrzon]

Matt and Thomas could actually use one of the cores that has been modified to run on the Chameleon.  If my memory serves me correctly, it also has a 68k soft CPU in addition to the classic Amiga chipset.  Or better yet, they can keep using a real classic Amiga or a UAE variant.....problem solved!  Or they could buy a Mining or a Replay board or a Chameleon.  Again, problem solved.   With all the options out there for running classic systems, the arguments they've been posting here are looking very ridiculous.  It's clear they have some personal issue with Gunnar and the technical issues that they keep raising are just smokescreens.

your own words above. not speaking about matt, who anyway helped a lot with a number of amiga projects, but telling one of the few apollo team software contributors, like thor, because he has some valid concerns, he should stay away from the project is everything but constructive.

[wawrzon]

I still have no idea what you're referring too.  I haven't told THOR to stay away.  Never mentioned him.  I told Matt and THOMAS to stay away if they didn't like this project.  It's Gunnar's project and he obviously is getting along quite well in spite of Matt's and Thomas' criticisms.  If they don't like the direction that Gunnar is taking his project, they should take it up with Gunnar in offline mode rather than making a spectacle of themselves here.  And there are other people who can develop libraries for Gunnar's project, as well as complete alternatives to Gunnar's project such as the Minimig, Chameleon, Mist and Replay boards. No one is forcing anyone to like or adopt or develop for Gunnar's project.

thor and thomas richter are one and the same person. clear now?

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