Quote:

hatschi wrote: Honestly, I have explained to you earlier that there is currently no alternative for 68k-focused Amigans (alternative being a new, relatively fast accelerator board) and why I think that having a new all-in-one board *does* make sense, even if it doesn't achieve full 060-speed on old 68k-code. But you keep going on and on about the "not faster than 060" point. It might be your own reason *not* to buy a Dragon, but I would think that people who look for an accelerator/busboard-solution and who compare Ebay prices for a 1260/G-rex combo also *might* have their reasons for preferring the Dragon. The discussion shouldn't be solely CPU-focused, since the Dragon is a busboard with a Coldfire-CPU. So even if the CF can't compete when executing non-recompiled 68k-code, there are many other factors that make it appealing for Classic-geeks.

Exactly. I want one of these boards because it allows a speed increase over an unexpanded 68020, an easy RAM expansion option, the ability to add an AGP graphics card and has PCI expansion slots. Out of the 3 Amigas I have hooked up and running, I have nothing faster than a 68030 processor. I really don't care about '060 speeds for most of my existing software. What I am looking forward to is the ability to run OS3.9 at a decent resolution, USB ports, Ethernet and to make the most of any recompiled applications as and when they become available.

I think a lot of people here are blasting the Dragon because it doesn't fit THEIR needs. Sorry guys, life isn't always about YOU.

_________________
AmigaOne X1000, A4000(T), A3000, A2000, A1200(T), A1200, A500, CD32, Minimig+ARM, FPGA Arcade, Chameleon64, C-One, C128, C128D, C64C, C64, VIC-20, CBM 8032, CBM4032, Efika, Ultimate64

@Darrin

Quote:

Sorry guys, life isn't always about YOU.

As I have said... I don't know personally any 030 user. The only active users I know use 040, 060, PPC or A1/Peg.

And If most of 030 users didn't spend a single cent in their equipment the past years I doubt it's a good decission to think that those same users will spend 350Euros now when they have been able to buy full amigas with 060 and gfx card for that price.


BTW, those who don't care about 060 speed are obviously not interested in demoscene stuff. Anything less than 060 won't allow you to run productions released the last 5 years.

Last edited by Crumb on 15-Nov-2006 at 12:17 PM.
Last edited by Crumb on 15-Nov-2006 at 12:16 PM.

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Quote:

And If most of 030 users didn't spend a single cent in their equipment the past years I doubt it's a good decission to think that those same users will spend 350Euros now when they have been able to buy full amigas with 060 and gfx card for that price.

Where do I get a 060 and complete gfx-solution for 350 EUR - preferably new? Ok, get a used Blizzard 1260 for 250 EUR and then? A new Mediator 1200 LT4 for EUR 190,- plus a used Voodoo (~15 EUR)?
I can see why some people would prefer a new all-in-one solution with additional merits (e.g. GFX to CPU transfer without expansion-bus limit, AGP, SATA, etc.).

Last edited by hatschi on 15-Nov-2006 at 12:23 PM.

Quote:

Elbox uses a full cpu emulation like the one used on PPC, arm or any other "alien" cpu and that causes the big slow downs. Coldfire is no faster than a 266Mhz PPC/x86/ARM running an interpretive 680x0 emulator.

You are forgetting a very important fact.

There are four ways to run 68k programs on Coldfire.

a) use software emulation. Slow but 100% working.
b) use codlfire.lib. Much faster but slower than Coldfire optimized.
c) recompile existing executable using the executable only and using the software emulation lib.
d) compile and optimize executables for Codlfire using the source.

All four ways of running 68k executables have been done on coldfire CPUs already.

The option a) is the save and paranoid way of doing it.

But 95% of all software can actually get away with method b) and will run much faster this way.
c) recompiling the executable will work on a high number of programs, who knows maybe even on your ArtEffect
d) recompiling the source will work with all software that is still on developed for Amiga.

And frankly the only reason why I would buy new Amiga HW is that I will expect some new software coming out. Some new games or some tools like ports of Mozilla or Sputnik. And these programms can of course be optimized for Coldfire.


I think no one expects to build a render farm out of coldfires but it would be nice to be able to surve the internet with a new Aweb or Sputnik port or write email or listen to mpeg and watch videos.
And for alll these things you can compile 68k coldfire apps that will run faster on Dragon than on any other 68k Amiga before.

Cheers
Gunnar

_________________
APOLLO the new 68K : www.apollo-core.com

@hatschi

eBay. Some years ago for 350Euros you could get a BlizzardPPC/240Mhz with 060 and BlizzardVision.

And full A4000s with CS mk2 060 , CV64...

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Quote:

eBay. Some years ago for 350Euros you could get a BlizzardPPC/240Mhz with 060 and BlizzardVision.

Err, ok, some years ago... while I highly doubt that the above price was common for that configuration (you even stated "full amigas") at that time, I thought we were discussing current options and alternatives with similar merits here?
Are there any alternatives other than much more expensive used equipment?

Last edited by hatschi on 15-Nov-2006 at 12:35 PM.

@BigGun

Quote:

a) use software emulation. Slow but 100% working.

ATM running slower than a A3640/25Mhz..

Quote:

b) use codlfire.lib. Much faster but slower than Coldfire optimized.

That won't work. It's fantasy. Simply because you have instructions that are the same but give different results. You can't notice when it's executing easily because it generates no exception like the missing ones.

Quote:

c) recompile existing executable using the executable only and using the software emulation lib.

That sounds pretty fantasy-world, could you elaborate please? Since b) won't work because you can't detect the same instructions easily I would invalidate this point.

Quote:

d) compile and optimize executables for Codlfire using the source.

That's the second feasible method. That leaves us with a) and d).

Unfortunately there's no easy access to most of the sources.

Quote:

The option a) is the save and paranoid way of doing it.

It's the only working method. You can improve it using a JIT. But it's the only serious method.

Quote:

But 95% of all software can actually get away with method b) and will run much faster this way.

A coldfire library is not possible simply because some instructions are the same but work in a different way, giving a different result and you can't trap them like missing ones. So that's a fairy tale.

Quote:

c) recompiling the executable will work on a high number of programs, who knows maybe even on your ArtEffect

You simply can't do that. You can't translate the binary easily because you can't differenciate easily which parts of the binary are code or data and you depend on branches. In addition to that translating the entire binary would cause problems with self modifying code.

Quote:

d) recompiling the source will work with all software that is still on developed for Amiga.

Unfortunately, most of killer apps are no longer in development and most of modern software will require more than 266Mhz.

Quote:

And frankly the only reason why I would buy new Amiga HW is that I will expect some new software coming out. Some new games or some tools like ports of Mozilla or Sputnik. And these programms can of course be optimized for Coldfire.

Have you tried Mozilla on a 266Mhz machine? Even with a lot of ram? Do you know how slow will it be?

Do you really think Marcik will waste his time porting Sputnik to an unreleased platform with zero users that will probably be quite slow instead of porting it to OS4 or AROS?

Quote:

I think no one expects to build a render farm out of coldfires but it would be nice to be able to surve the internet with a new Aweb or Sputnik port or write email or listen to mpeg and watch videos.

I already can do that with my CSPPC.

Using Coldfire lacks any sense. It doesn't offer any advantage over PPC, x86 or 68060 if you want to run 060 software. It would make more sense to use the same cpu as Sam440 with a 68k emulator in the flashram. You could run everything faster than 060 and if they came to a deal with OS4 team they could get OS4 ported to it.

Last edited by Crumb on 15-Nov-2006 at 12:55 PM.

_________________
The only spanish amiga news web page/club: CUAZ

@hatschi

Quote:

Err, ok, some years ago... while I highly doubt that the above price was common for that configuration (you even stated "full amigas") at that time, I thought we were discussing current options and alternatives with similar merits here?

You can get Full A4000s with 060 and Z3 gfx card from eBay now.

BTW, I said that users with 030 that didn't spend 350Euros some years ago (the same users that could have buy PPC accelerators and full A4060+RTG) are unlikely to spend 350Euros now.

Quote:

Are there any alternatives other than much more expensive used equipment?

You can get any new x86 machine and it will run 68k apps on UAE faster than any Coldfire running native Coldfire apps

_________________
The only spanish amiga news web page/club: CUAZ

@Crumb

Quote:

That won't work. It's fantasy. Simply because you have instructions that are the same but give different results. You can't notice when it's executing easily because it generates no exception like the missing ones.

But seriously, how much software actually performs a muliply or certain shift and then checks the overflow flag (or whatever flag it was)? For those few apps which actually does this, you could easily have a blacklist and use full emulation for them.

@Crumb

Quote:

You can get any new x86 machine and it will run 68k apps on UAE faster than any Coldfire running native Coldfire apps

...or any 68060 for that matter. Again, that's not an alternative to people who bought a stock A1200 on Ebay or from an Amiga-dealer and who wish to upgrade it. If your only gauge is performance, there wouldn't be any logical reasons to still use Amiga classic equipment. Luckily, many still do.

@Crumb

It would be nice if you could inform yourself better before you spread false information here.
Talk to some coldfire developers before you make wild claims.
I have developed on Coldfire already.

You can ask any serious coldfire developer and all will tell you that the coldfire.lib option will work for 90% of the normal 68k executables as the few not hundred percent compatible asm opcodes are only rarely used in normal programs .

If you do ont believe me then give your next Freescale office a call and talk with them.
Or call these people http://www.microapl.co.uk/Porting/ColdFire/overview.html they can certainly tell you why they have developed the coldfire.lib and how many old 68k applications use it succesfully to run on Coldfire.


Cheers
Gunnar

_________________
APOLLO the new 68K : www.apollo-core.com

@Crumb

Quote:

You simply can't do that. You can't translate the binary easily because you can't differenciate easily which parts of the binary are code or data and you depend on branches. In addition to that translating the entire binary would cause problems with self modifying code.

But you can do what OxyPatcher and friends do. Once you get a trap, replace the instruction causing it with a jump to the emulation routine. Also, self modifying code as a way of optimizing your code hasn't been practical since the 68000 days, as it wont work on CPU's with a cache, like the 68020 and above.

@AmiDog
Quote:

AmiDog wrote: @Crumb Quote: That won't work. It's fantasy. Simply because you have instructions that are the same but give different results. You can't notice when it's executing easily because it generates no exception like the missing ones. But seriously, how much software actually performs a muliply or certain shift and then checks the overflow flag (or whatever flag it was)? For those few apps which actually does this, you could easily have a blacklist and use full emulation for them.

Quoted from CF68KLib-manual:

Quote:

5.2 Handling 68020 Multiply/Divide Instructions CF68KLib provides full support for the 68020 multiply and divide instructions. However under normal circumstances these routines would not be called because the ColdFire processor does not trap out when it encounters the instructions. What is needed is a way of forcing the ColdFire processor to trap so that CF68KLib can handle the instruction. CF68KLib reassigns one of the 16-bit opcodes, 0x4E00, which is not used in 680x0 or ColdFire and which causes an exception. This is used as an 'escape' telling CF68KLib to emulate the next instruction. For example if your source code contains: .short 0x4E00 divsl.l d0,d1:d2 …then CF68KLib will catch the exception caused by the 0x4E00 opcode and emulate the DIVSL instruction which follows as though it had itself caused the exception.

@BigGun


Quote:

It would be nice if you could inform yourself better before you spread false information here.

I already did


Quote:

Talk to some coldfire developers before you make wild claims.

Already did that... I suggest you checking out this document:
http://piru.dyndns.org/~p/coldfire-v4-m68k.txt


Quote:

I have developed on Coldfire already.

And I have developed for x86, PPC and 680x0 but still that doesn't mean I'm full of knowledge.

Quote:

You can ask any serious coldfire developer and all will tell you that the coldfire.lib option will work for 90% of the normal 68k executables as the few not hundred percent compatible asm opcodes are only rarely used in normal programs .

I seriously doubt that library works well with AmigaOS. Otherwise Elbox would have used it. and 90% is not 100%.

_________________
The only spanish amiga news web page/club: CUAZ

@AmiDog

AFAIK you can't get a trap of instructions that already exist. BTW although it's not a common practice I know self modifying code has been used in 040/060 in some scene intros to reduce code size.

@all coldfire fans

Although I don't think it happens I would love to see Dragon running 060 apps (including scene demos) faster than 060/50.

I have nothing to add that I haven't said before. If brute-force emulation (emulating everything including OS libraries) is slower than real 060/50, then it's not for me.
I also doubt it can run more than any other cpu running an interpretive emulator. I doubt it makes any sense today (it could have been great 3-4 years ago) but the more options the merrier.

_________________
The only spanish amiga news web page/club: CUAZ

@AmiDog

Quote:

But seriously, how much software actually performs a muliply or certain shift and then checks the overflow flag (or whatever flag it was)? For those few apps which actually does this, you could easily have a blacklist and use full emulation for them.

Problem is, you dont know.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@BigGun

Quote:

No, actually I think this is not such a big issue. You know yourself that a coldfire clean Exec or gfx.library will make a BIG difference and getting the small exec or the gfx lib coldfire clean is actually not difficult at all.

It makes difference. One unnamed OS vendor did this and results were good.

Quote:

I'll now compile Aweb and 194x for Coldfire. I have no doubt that the coldfire version will run much faster on the Dragon.

Would Cf code run on 68k?

Edit: NB: if Cf could run existing 68k software faster than real 060 it would be definitely the best 68k accelerator. It would have point over PPC boards: no need to install new OS.

Last edited by itix on 15-Nov-2006 at 03:09 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Crumb

If prefer not to trust Freescale but to base your coldfire knowledge
on piru then maybe you should at least care to read his post completely.

Piru even gave examples of how the few misbehaving 68k instructions
can be patched in a way similar to oxypatcher. Something that you claimed that it will not work.

Crumb, the point here is that to run 68k code on Codlfire you have several options.
I have already explained the four options to you before.
They range from slow but 100% working to fast but only working for 90% of the apps.

Elbox is just at the beginning, the Dragon was only just showcased.
They clearly did not have time to fully optimize this yet.

I think we all agree that the Coldfire is not comperable to Opteron, G5 or duocore performance.
And no one will ever claim this.

But from seeing an alpha version of the Dragon you can not claim that it will be impossible for the Dragon to run most 68k apps as fast or faster as an 68060.

Before you bash the demoed alpha version of the Dragon, be fair and give them some time to better utilize the optimisation potential.

Maybe you remember that the Amiga1000 was shipped with Kickstart 1.1 which was known to be buggy and not fully stable?
Kick 1.2 came out soon after the first Amiga1000.

Be fair to Elbox ang give them some time to bring out ColdfireKick 1.x

Cheers

_________________
APOLLO the new 68K : www.apollo-core.com

The only way to have a really fast 680x0 in my opinion is to implement it in a FPGA, like they have done for the classic Amiga chipset in the MiniMig project. The latest FPGA chips are made with 90nm technology, can be clocked up to 1GHz and have more than enough gates to implement a fast, pipelined 680x0-compatible CPU/FPU with large L1 caches, etc. so you could have that dream 68080@1GHz :) It'd be a lot of work though...

@BigGun

Quote:

c) recompiling the executable will work on a high number of programs, who knows maybe even on your ArtEffect

Isn't this basically a JIT option "a la" Amithlon style? I ask only because I got the impression from others here that this was not going to be a part of the product, but if it is, wouldn't it make close to half of this thread's discussion pointless?

@Thread

Hatschi and others here make a good point that most people here are overlooking. This may not be the ideal product to go forward and modernize the platform, but for the retro gamer and retro user with only classic hardware which wants to keep using classic this hardware with some custom chipset banging software, this is ideal, specially when one considers that this is the only accelerator that will even be available for a stock classic system that doesn't already have one, whether because it never did, or because the one it did have has gone to pasture without possibility of repair. If it has a 68k JIT, even better IMHO, but this is still NOT the only reason that this product might be appealing to some.

Just like the C64, there will still be people developping for the classic 68k systems for years to come, perhaps not killer apps, but certainly more apps, and if the Dragon becomes the defacto classic add-on, then this will undoubtedly mean that many will also release optimized executables for this processor too. I'm amazed by the amount of freeware/shareware software that is still coming out for these systems. Undoubtedly, many people will more than likely source compile what they can get their hands on as it either gets passed on, sold or open sourced over time, and try to compile executables wherever the latter is not possible.

In any case, I'm not a expert on the ColdFire, and some of you might be proven right about some of the "unsurmountable" issues, but I'm not going to be quite as quick to rule out the usefulness of this board yet. There is no harm in taking a wait and see approach, IMHO.

Last edited by elatour on 15-Nov-2006 at 04:54 PM.
Last edited by elatour on 15-Nov-2006 at 04:52 PM.
Last edited by elatour on 15-Nov-2006 at 03:28 PM.

_________________
When swimming with sharks, make sure to bring lots of band-aids...