Id buy a coldfire

[xeron]

bloodline wrote:
and no Atari software ever needed anything moe powerful than an 8Mhz 68000...

Bzzzt! Lots of Atari software has been released that use 020, 030, 040 and even 060 processors. Most people don't use just the basic GEM desktop and TOS, they use MiNT, MagiC, etc.

Sure the Flacon has some nice features, but it was too little too late.

So are you saying Atari fans should just give up with their machines and operating system, and forget it? Why is it any different to the Amiga?

Atari is a hobby computer, much like the Amiga. Its users grew up with Atari, they enjoy using them, tinkering with them, and upgrading them.

[bloodline]

Tickly wrote:

bloodline wrote:
and no Atari software ever needed anything moe powerful than an 8Mhz 68000...

Bzzzt! Lots of Atari software has been released that use 020, 030, 040 and even 060 processors. Most people don't use just the basic GEM desktop and TOS, they use MiNT, MagiC, etc.

Sure the Flacon has some nice features, but it was too little too late.

So are you saying Atari fans should just give up with their machines and operating system, and forget it? Why is it any different to the Amiga?

Sorry, no!!! I was just saying that the Falcon had some nice features, that would have been better served on an A1200... :-)

bloodline wrote:

mdma wrote:

bloodline wrote:

Tickly wrote:
Well, heres a forum topic over on Atari.org about "The Atari Coldfire project": http://forums.atari.org/read.php3?num=3&id=11991&thread=11979. spooky mirroring of amiga.org or what?  ;-)

There were some prototype Atari specific PowerPC cards made, but I can't find info about them now (damn it!). here is some info about a project to fit Phase 5 PowerUP cards into an Atari Falcon, but I don't think that got anywhere...

Here is some info about the "Hades", "Medusa" and "Milan" Atari clones.

Facinating, but the Atari was built of standard computer components, and had a freely avaible, portable OS (I refer to GEM as TOS was was well toss :-D ).

I really don't get the point... GEM is available for PC's and no Atari software ever needed anything moe powerful than an 8Mhz 68000...

Sure the Flacon has some nice features, but it was too little too late. I rather liked the 16bit GFX and 16bit Audio... the A1200 should have had those...

Milan '060

These would be nice for running AROS!

Certainly doable, but I'm sure you are well aware of that... :-D

Any yes, I wish I hadn't trashed the Old ST I had, AROS on that would have been soooooo funny :-)  :-)

If I ever get my hands on that TT i mentioned a while ago, I'll port AROS to it straight away.

[Oli_hd]

Hi,

I know tha Oli_HD stated that making a new MoBo would be very difficult

It wouldnt be difficult, its just something that I cant see a market for yet, If you wanted a new motherboard would you pick a 800Mhz or a 220Mhz Coldfire? Now if lots of Amiga's upgraded to the Coldfire then a full motherboard may be a good product.

Your right about just adding a PCI slot and having a full motherboard, heck Motorola's dev board would just about do (1 PCI slot, ethernet, 2X serial, SDram and flash chip)

[yssing]

Your right about just adding a PCI slot and having a full motherboard, heck Motorola's dev board would just about do (1 PCI slot, ethernet, 2X serial, SDram and flash chip)

Allright :-) Yeah, just port AROS to the DEV board then :-)

[KennyR]

I'd pick 4. I already have a PPC card in my Miggy, and very fast it is too (even though in it's present state it's used more like a FPU than a CPU).

Anyone want to design a dual G3/Coldfire accelerator card? :-D

[jdiffend]

bloodline wrote:
I think the point here is, buy a Cold Fire if you have apps on your Amiga now, which need more power... ray tracing, music processing and image processing springs to mind.

I spent quite a bit of time looking into this a couple years ago and well.... the problem with the Coldfire is compatibility.  Even with the emulation libs there is stuff that just won't run without a recompile, rewrite or patch.  

The supervisor stack is NOT compatible with the 68K.  You really need to rewrite *at least* the exec.

Software must use the math libs if floating point is used.

There needs to be Coldfire math libs.

You need to patch any software with unemulatable instructions like mpy/div with illegal instructions that can be trapped and add emulation for them to the emulation libs.

The list goes on  and on.  

Just having the hardware isn't going to cut it.  As it is I'm not sure Oli's emulation approach will work.

[bloodline]

jdiffend wrote:

bloodline wrote:
I think the point here is, buy a Cold Fire if you have apps on your Amiga now, which need more power... ray tracing, music processing and image processing springs to mind.

I spent quite a bit of time looking into this a couple years ago and well.... the problem with the Coldfire is compatibility.  Even with the emulation libs there is stuff that just won't run without a recompile, rewrite or patch.  

The supervisor stack is NOT compatible with the 68K.  You really need to rewrite *at least* the exec.

Software must use the math libs if floating point is used.

There needs to be Coldfire math libs.

You need to patch any software with unemulatable instructions like mpy/div with illegal instructions that can be trapped and add emulation for them to the emulation libs.

The list goes on  and on.  

Just having the hardware isn't going to cut it.  As it is I'm not sure Oli's emulation approach will work.

If it's just the supervisor stuff that's the problem then AROS will cover that!!!! :-o

[jdiffend]

Only if you replace the Kickstart ROM!
And no... supervisor mode isn't the only problem... but I assume you were being funny.

[xeron]

As I understand it, Oli is intending to use a V4 coldfire in the final versions, which are more 680x0 compatible.

[jdiffend]

V4 core fixes NONE of the things I mentioned but it does support a few more address modes than the V3 so less instructions need emulated.

The V4e supposedly adds a supervisor stack pointer which will speed up emulation of the exec.  It does not fix ANY of the things I mentioned... nor will a V5 core or probably even a V6 core!

The supervisor stack is different on the Coldfire CPUs for speed.  It's a much faster way to implement the supervisor stack in a RISC cpu.  It's highly unlikely they will try to add more 68K compatibility after the V4e unless it's with additional address modes.

The mpy/div instructions don't set certain status bits and any software that tests those without first executing an instruction that will set them will not function the same on the Coldfire as a 680x0.  Patching these instructions with an illegal instruction that can be trapped allows exact emulation where needed... but a program to do that still needs to be written.

The FPU on future chips isn't fully compatible but is similar to the one on the 060.  

MMU?  I really haven't looked at that.

Certain address modes can't be emulated because of the way a pipelined CPU executes instructions.  These should not be a problem for any software that was compiled or written for 68040 and above.  68020 code... could fail.  The only solution short of a rewrite or recompile is to patch those instructions just like I suggested for the mpy/div.

The nice thing about the patched software is it could still run on 680x0 processors if you have a program similar to decigel to run on them.  The exception could be caught, the instruction decoded and the program patched to the original instruction on the fly.

[bloodline]

jdiffend wrote:
V4 core fixes NONE of the things I mentioned but it does support a few more address modes than the V3 so less instructions need emulated.

The V4e supposedly adds a supervisor stack pointer which will speed up emulation of the exec.  It does not fix ANY of the things I mentioned... nor will a V5 core or probably even a V6 core!

The supervisor stack is different on the Coldfire CPUs for speed.  It's a much faster way to implement the supervisor stack in a RISC cpu.  It's highly unlikely they will try to add more 68K compatibility after the V4e unless it's with additional address modes.

The mpy/div instructions don't set certain status bits and any software that tests those without first executing an instruction that will set them will not function the same on the Coldfire as a 680x0.  Patching these instructions with an illegal instruction that can be trapped allows exact emulation where needed... but a program to do that still needs to be written.

The FPU on future chips isn't fully compatible but is similar to the one on the 060.  

MMU?  I really haven't looked at that.

Certain address modes can't be emulated because of the way a pipelined CPU executes instructions.  These should not be a problem for any software that was compiled or written for 68040 and above.  68020 code... could fail.  The only solution short of a rewrite or recompile is to patch those instructions just like I suggested for the mpy/div.

The nice thing about the patched software is it could still run on 680x0 processors if you have a program similar to decigel to run on them.  The exception could be caught, the instruction decoded and the program patched to the original instruction on the fly.

I guess Oli's going to have to wait until you port AROS to the Coldfire before he can get his board running then :-)

[jdiffend]

He seems to think he can get it working with just emulation... I have my doubts.  And I don't think an AROS port will solve some of his problems.

The AROS port is for my own project and I hope to start next week.  But like I said... it will be aimed at a V2 core.  Well see... it sounds like I have another job (finally) and that comes first.   I think Oli might have been planning his own port anyway.

I was working on a Coldfire version of the exec... but that bit the dust when my hard drive got wiped a few days back so I'd have to start over.

While I'm on the kickstart subject... the new commented kickstart disassembly I've been working on could be done in a day or two if I'd just stop being lazy.  (less than 1000 lines to comment) I've only put in about 5 days work total but I started a year ago. :-D  
Since Amiga Inc is legal happy :roll: it would be released as the disassembler, config files, a diff file and a batch file to run everything.  I'd still need to compare several ROM versions so it will work on more than just one.

[jdiffend]

Um... less than 1000 lines to comment on the exec... not the entire kickstart.  I'm not that fast!  
 :lol: