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

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

[wawrzon]

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

[guest11527]

What is your definition of high?
Is trippling the FPU speed with new ISA high?

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?)

[IanP]

With (large enough) FPGA you can go on extending, the core adding new features and end users can upgrade to the new core. There could be an annual release cycle for improvements in the core for some years to come. This allows a "new generation" of "classic" Amigas or "NG Classics". They still run ALL the classic software natively (chipset/bad code limitations may still apply) and also run ALL "NG Classic" software like web browsers, video players, 3D Games etc. "NG Classic" software will NOT run on "classic" Amigas without installing an upgrade card but so what! AGA software doesn't run on OCS/ECS either currently. It would be foolish to not take the opportunity of upgrading the "CPU" with an improved ISA just because the code will not run on Motorola/Freescale "CPU" limited Amigas.

[biggun]

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?)

Thomas

you misunderstood my point

With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.

This means NEW ISA makes huge impact.
I can show you example code showing this.

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

[IanP]

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

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

[IanP]

Motorola giving up on 68k and moving to CPU32/Coldfire/PPC/ARM was a major blow for the Amiga at a time when Commodore/Amiga International didn't have the resources to handle it. Amiga development has stalled until FPGAs have become powerful and cheap enough to pick up where Motorola left of.

[Plaz]

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

[ElPolloDiabl]

@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?

[cunnpole]

Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners?

Probably, if all versions of the Apollo shared the same ISA. It could get messy fast trying to cope with all the different options. My guess is that it will continue to change for some time yet but only Gunnar can say if that will be the case.

[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

[IanP]

Probably, if all versions of the Apollo shared the same ISA. It could get messy fast trying to cope with all the different options. My guess is that it will continue to change for some time yet but only Gunnar can say if that will be the case.

Public release need to be limited to major milestone versions and bug fixes only. Beta releases are another matter, assembler/compiler writers and beta testers should have access to more frequent releases.

[biggun]

@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?

To which Coldfire you want to be compatible?
Which model - which Coldfire ISA?

For me to understand - Can you explain why you want this?

[guest11527]

Thomas

you misunderstood my point

With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.

This means NEW ISA makes huge impact.
I can show you example code showing this.

Gunnar, please. Are you telling me that the core runs at a faster speed because you added instructions? I beg your pardon...