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

[OlafS3]

Gave up :-/

I have made a comment on the apollo-core forum that there is a problem and people try to sign up and fail

So do not give up

[OlafS3]

Hmm 060, now that would be interesting. Anyway would like to purchase one so emailed info@natami.net.

Still a little hesitant especially with some Amiga hardware projects, notably a certain scan doubler.

the card has LAN and a modern video output and it is promised that there will be RTG and a new improved amiga chipset added. At the start it is a accellerator with 128 MB RAM.

[OlafS3]

yes, even though i though that bga package igor is using now woulkd be bigger than the previous one. but actually we are reffering here to that sandwitch socit board proposed by gunnar, arent we? and i thought that would be begi enough for what he considers a full core.

the thread you are referring to is for the bigger FPGA

[OlafS3]

Is the new improved Amiga chipset something like Super AGA or something better than OCS/ECS/AGA but along the line of new improved custom chipset? Will it be backward compatible with OCS/ECS/AGA?

If we make games on the new improved custom chipset does that mean it will not run on Amiga CD 32/A500/1200/etc that do not have this chipset installed in their system?

As I understand it the chipset is planned to be backward compatible and also with more advanced features. But I am not involved there so it is better gunnar answers that.

[OlafS3]

Which from what I was reading can be enabled over time with firmware updates as the hardware is all there just not enabled?

Would like to be part of this if I can as it is about time a good accelerator appeared especially with the tech that is available now.

The price is spot on too, anyway will hurry up and wait. Hopefully they will sort out their forum or allow interest to be taken here.

it will be updated over time. As someone already mentioned it is about developer boards to have more people testing and developing for it (like drivers). There will be updates over time. At the start it is accellerator with 128 MB RAM, other features will be added later.

I have left a comment there regarding registration problems and a link to this thread

[OlafS3]

errrm, guys, even being op in this thread, silly question, how have you managed to register?
im seriously starting to think about getting another a600;)

A500 or A600

If the register not works Gunnar has another homepage and the email there should work. I do not know if the email on the register page works now or not. It seems there was a problem. If you have a problem I could also leave a message on the apollo core forum.

[OlafS3]

a500 is too bulky. i have a sentiment for the 600 for its compact form factor and because it was the firsta amiga i owned;). but i would have to get ks3.1 for it first as i understand.
i was a member on natami forum, they could take my details from there or from you.

I do not know if Gunnar has access to the Natami forum (he was not administrator there) and passwords are normally hidden. Best is to try to registrate and if not works inform me and I can post it on apollo forum.

A600 is my favorite too because it is small and I want to show it at amiga meeting(s)

[OlafS3]

Let me know how I can take part.
I own a Amiga500 rev 6a, amiga1200 1.4.d, and a amiga600.

Btw: I am registered on both apollo-core.com & Natami.net

there is this thread on apollo core forum:
http://www.apollo-core.com/knowledge.php?b=7

just write there that you are interested and if you prefer A500 or A600

[OlafS3]

No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.



#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.



It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.

Matt you start to slightly nerving now. With the next wave there will be a number of new testers (some active here in this forum) who will test and verify it using the newest core. This idelogic debates (by technicians) if more or less registers are better are far from real. You should do that debate by PM or email and not in the public because most people do not understand it and are only getting irritated except you want to harm the project. If that is your goal then go on like you do. BTW as I wrote on apollo forum most of it is to me rather theoretical.

[OlafS3]

I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.

The debates on apollo forum were in the same tone as here (partly worse). Matt can like it or not but decisions and work is not done by him but by Gunnar and some others. At the end the result counts and we will see it when we will have and use the new cards. That debates if one register more or less is better or worse or if without one command the world goes under are nerving. If Matt would want to help he would buy a card and help testing and help to improve compatibility instead continuing the debate from apollo forum on a public forum where people only get wrong impressions.

Regarding ISA extensions I am of the same opinion that supporting existing ISA is more important than extending it because we have only few developers (like Novacoder) left who would really use this new commands. Most others are using compilers. We have a huge 68k codebase with lots of compilers, libraries and applications and games but many of these are closed or written in asm. Who will adapt the compilers? And even when they are adapted many programs are not available in source. So most energy should be invested in getting the most for the existing codebase.

The rest of the debate between Matt and Gunnar was that Matt preferred something different because what Gunnar does would be not best for ASIC and Gunnar denied that. I cannot judge who is right or wrong there and I do not care. Sorry Matt I do not believe that there will be any ASIC design in foreseeable future (high costs) and if someone would really invest in such a project the design certainly could be adapted (assuming that Matt is right at all, Gunnar is working at IBM so he should have some clue too). I want the best for existing FPGAs. Besides I think FPGA is more interesting and has more geek factor than ASIC right now.

[OlafS3]

So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
 
 Hopefully you will open source it so we can remove them.

Huh?

Was that a joke?

[OlafS3]

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.

what do you mean with old and new core?

old core is existing 68k processors? If the new ISA supports old ISA what is the problem adding new except almost no software will use it?

[OlafS3]

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.

Sometimes I have problems to understand the problems. All old code should run on it (as fast as possible) and of course when new 68k software is developed (for 68000-68060). Most people will use compilers and not directly write asm so compiler generated code should also work. Then there could compilers be extended to support new commands but that would be only a new compile if you use a high-language and as long as you are aware that this code needs apollo I do not see a real problem. If someone writes asm he certainly knows anyway what he does. There should be documentation then what is supported by old ISA and what is only available on new ISA. And the programmer then has to decide. But in general I do not see a real problem. I think technicians sometimes are lost in the wood nobody else even see and are only irritating others by becoming ideologic/religious about it (what it sometimes seem to me).

[OlafS3]

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.

Might be that many programs are not benefitting from it because they were compiled with compilers not supporting these new instructions or even written in asm not using this commands but I do not understand why it is a real problem as long as 68000-68060 code works on it. Who wants to use the new commands has either use new compilers (with a new apollo target) or write it himself in asm. As long as people are aware that apollo specific code not necessarily runs on 68000 I do not really see the problem. Anyway hopefully apollo (+new chipset) becomes the new standard and nobody will then care about a plain A500 when developing a new software. I think there of demanding applications and games, who will try to run them on such hardware anyway?

[OlafS3]

For a long time software for Amiga has come released in more than one version. For example... 68000 and 68020 versions. Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners?  Or am I misunderstanding this part of the discussion?

That being said, how would a compiler deal with new features added to Apollo? In the case of 68K vs 020 versions, it was basically a compiler switch option.

And maybe that second question belongs over at the techie Apollo thread.

Plaz

I am not a compiler developer but I think it would be a added switch