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

[kolla]

I was not aware of that fact. Thanks for the great news regardless

I hope you are as tongue-in-cheek as I am now

[xboxOwn]

I hope you are as tongue-in-cheek as I am now

Uuh........:angry:...............okkaaay?.....uuuh........

[kolla]

Oh no! You see now how fast random statements become "facts" and "promises"?

Ask OlafS3 about facts regarding 64bit addressing, he was very well informed when it came up.

[kolla]

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

Yeah, that's kinda why I would like some BSD and Linux kernel developers on board, to have more voices to chime in regarding MMU implementation. uCLinux does not rely on the MMU.

Is 68020+AGA enough for everyone? These are well defined and it's not a bad standard but is that enough forever? If we want more, then we should create new standards.

Nothing is ever enough for everyone, I'd love FPU and MMU as well. AGA that is faster and can do higher resolutions would be awesome. To be honest, I don't care about games, I just want to animate with DPaint and various other software again with as many limitations as possible squashed, such as ammount of chipram, speed of chipram access, rendering speed etc.

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

[QuikSanz]

Many of you folks have many expectations. As long as it's totally 020 compatible and fast, who really cares! Everyone talks future, let it evolve first. Would really like to run anything on Amiga first before any other, after that it's cake.

Chris

[ElPolloDiabl]

I would like to have an 060 speed expansion this year. In another year or two the 300mhz 060 speed expansion.
There should be a compatible version and also a fast version. Because even a small group of people are going to have disagreements.

[ferrellsl]

Have you printed out his avatar photo and framed it above your bed already?

No, but I have yours mounted on my dart board and it's full of holes already.

[psxphill]

Personally, if you are going to mess around with the architecture sufficiently to force a compiler modification, you might as well recompile to something else entirely. ARM or MIPs spring to mind.

I agree. The only reason for adding extra instructions is so you can put something on your CV and to have something to talk about over a beer.

In the case of the FPU, the only way it's faster is to make it less accurate. If accuracy is not important then it's possible to make all FPU operations take no time at all, just make them all return 0. It would be just as useful for running all your old FPU apps.

I don't have any doubts over technical prowess but in terms of direction he needs to know that diverging from the original specifications is not what anyone really wants. You can probably find some people that say they are happy with it, but they are probably making assumptions over what they will receive that nobody is even attempting to achieve.

100% 68060 compatible CPU+FPU+MMU is the only "compromise" that I'm happy with, Motorola took things out and people have spent decades making sure the software runs. We shouldn't have to start that process again just yet.
 
 Even if you attempt to make something 100% compatible you will fail, if you start out aiming lower than 100% then when you fail it gets real ugly.

[ChaosLord]

And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.

All my games have use for an improved 680x0 CPU.

Even my old A500 games required a 68020+ after circa 1990.  25Mhz 68030 accelerators were sold everywhere for A500 in 1990s.  They had 68020 and 68030 accelerators in 1980s too.

All my games have use for a faster CPU.
All my games have use for additional instructions.
All my games have use for more RAM.

[psxphill]

All my games have use for additional instructions.

I am assuming you haven't written self aware games that rewrite themselves and you mean that YOU have use for additional instructions(*) in further updates.

Assume you're dead and nobody is going to bother updating your games, do you still think they have use for additional instructions(*)?

(*) additional instructions refers to ones that gunnar is going to add that will hurt compatibility, not ones that Motorola already added and we've dealt with those compatibility issues already.

[ChaosLord]

If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.

What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?

No.

Coldfire was designed on purpose to be permanently incompatible with all previous processors.

It was very deviously and fiendishly designed.  Someone paid someone a LOT of money as a bribe to cook up this wacked out mysteriously hyper-incompatible cpu.

When Matt et. al. talk about coldfire compatibilty they are referring to adding in a few new instructions that can be 100% compatible.  But you need to understand that some coldfire instructions are just completely ridiculously incompatible.

If you want to run Coldfire code on a non coldfire cpu then you must use emulation.

[Djole]

I really dont see a big problem here. Adding new instructions will not hurt compatibility of existing software. Future software can make use of them but the programmer can also decide to leave them out and use standard instructions. I see it as added value and it can be used to show of the power of the new core and thus attract more users. It wasnt an uncommon thing in Amiga land to have different executables for different processors anyway. I dont expect to see that much new software anyway...

[guest11527]

Coldfire was designed on purpose to be permanently incompatible with all previous processors.

It was very deviously and fiendishly designed.  Someone paid someone a LOT of money as a bribe to cook up this wacked out mysteriously hyper-incompatible cpu.

Hardly. Nobody was bribed for anything - what for? Motorola made a clear statement on their future product development. PPC for desktop, coldfire for embedded. Of course you don't want one product to damage or intrude the market for another, but that does not require bribary, it is a business decision. Coldfire was designed to be as minimal as possible and as cheap as possible, and that means that a lot of legacy baggadge had been removed. That they did not want to invest more money into the 68K as desktop processor was only logical after their largest user (Apple) jumped on the PPC stream.

Hence, there is no conspiracy here. It is just a business decision. In retrospect, probably not a very smart decision given the limited performance and scalability of risk processors, but back then, who could know that? All the signs were that risk would be the future, and to invest the limited resources in this branch would make sense.

[psxphill]

Adding new instructions will not hurt compatibility of existing software.

Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception. The MMU & FPU that is proposed is certainly incompatible.

I don't believe compatibility with existing software is high up on his priority list. If there is any choice of performance vs compatibility, then I expect old software to stop working to allow the handful of new apps to run quicker. I don't expect that he's running every single piece of software ever written to check that his changes aren't causing any problems either.

[guest11527]

Any opcode that would cause an exception on a real 680x0 cpu can be used by software as a virtual opcode. LINEA & LINEF were officially available for that, but it's certainly possible that a piece of software could rely on any exception. The MMU & FPU that is proposed is certainly incompatible.

Actually, it is a bit more complicated. Line-A is certainly not available for new opcodes as this line is taken, both by MacOs (operating system traps) and also by Atari TOS (the blitter).

The F-Space is partially available. Motorola has the standard 68882 FPU mapped there, and the MMU, and some extended instructions of the 68060/040 map here.

Besides that, some new functions can at least cause problems, e.g. a new set of data registers or a new address register. Problem is that these are not saved and restored by the exec scheduler. Thus, the scheduler would need to be patched. But then, a couple of utilities depend on the stack frame of the scheduler, thus you can either continue to use these programs and not make use of the new registers, or use the registers and get rid of the programs.

Actually, I personally would rather get rid of the extra registers as I consider the Amiga "market" too small for such an experiment.

Anyhow, all these are engineering arguments, but my central point is not even related to engineering. I don't want to repeat this all over again.