@dan.hutch

Quote:

No, because spending £500-600 on a dated PPC motherboard is obvisously so much more worthwhile

I'd even go further by replacing te word "motherboard" with "boat anchor".

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

@elatour

OS4 won't run on the Dragon since it's Coldfire-based. Maybe you are confusing Dragon with SharkPPC (i.e. Sonnet Crescendo)?
But I agree, the bypass option is very important. It will be possible to deactivate the Dragon - at least with a jumper (can be seen on the show-photos). Hopefully, there is also a software option, comparable to holding down the "2" key on a Blizzard 1260.

Last edited by hatschi on 14-Nov-2006 at 09:43 PM.

I've dug up some text from the Elbox site regarding the current topics being discussed in this thread.


Quote:

Q: Is DRAGON able to execute 68k apps faster than G3 based boards? A: Yes. Most of 68k Amiga applications run faster on DRAGON ColdFire then in the JIT emulation on currently available PowerPC G3-based boards.

Quote:

Q: Does power of the ColdFire processor in DRAGON allow smooth playing of Divxs? A: Yes. Performance of the ColdFire MCF5475 processor combined with elements of hardware support for the decoding process of Radeon 9xxx cards allows smooth playing full-quality video from the compressed files (DivX, MPEG-2, DVD).

Quote:

Update (31 January 2005): Unfortunately, things are not always going as expected. We planned starting sales of DRAGON cards for the end of January. Some of the subassemblies have not reached us on time, though. Therefore, the sales starting date will be slightly delayed. But we have also very good news for today: We have just completed the development and beta testing of the DRAGON drivers for ATI Radeon 9200/9500/9700 graphic cards. These drivers are the first Radeon drivers for Amiga computers, which support all overlay modes provided by these card' hardware: 15-bit PC, 16-bit PC, 32-bit BGRA, VYUY422, YVYU422, YUV9 and YUV12. These functions are crucial not only for using TV cards without any CPU load, but also for smooth playing of the compressed video files.

@hatschi

Quote:

OS4 won't run on the Dragon since it's Coldfire-based. Maybe you are confusing Dragon with SharkPPC (i.e. Sonnet Crescendo)?

Yes, you are quite right. I was just reading through the rest of the thread and realized that I had in fact confused the Dragon with the SharkPPC.

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

@Rob

Quote:

Quote: Q: Is DRAGON able to execute 68k apps faster than G3 based boards? A: Yes. Most of 68k Amiga applications run faster on DRAGON ColdFire then in the JIT emulation on currently available PowerPC G3-based boards.

Which we already know to be false...

As it is, Trance is faster on a PowerUp board than the Dragon with its emulation...

Last edited by AMiGR on 14-Nov-2006 at 10:09 PM.

_________________

@AMiGR

I've sent them an email regarding the concerns about speed and a couple of other points. I've asked them if I can post the answers here. Hopefully they'll take the time to respond.

@Rob

They will probably give you the usual PR answers that contain next to no useful information. People actually *saw* it go so slowly and Elbox said that for full speed you need it to be coldfire native, so unless if they are planning on writing a good full JIT, I can't see how this can get any better. So far everything "the nay-sayers" have been saying was correct...

_________________

@Jorge

Quote:

It would be interessting to see where the bottle neck is, exactly

On classic 060 and PPC Amigas, for MPEG files the main bottleneck was the bandwidth to videomem, which was 10-15MB/s at best. The second was the CPU (IDCT and motion reconstruction in the decoder). Disk I/O was not a problem as long as you had DMA (e.g. a SCSI hard drive) when using an efficient Async I/O routine.

On the A1 videomem bandwidth is over 160MB/s so it's not as limiting as on classic. The biggest bottleneck is the decoder itself, where most of the processing is done in IDCT and motion reconstruction. IDCT speed mainly depends on raw CPU performance (integer arithmetic on small blocks of data in L1 cache). Motion block reconstruction probably depends more on your RAM bandwidth than CPU performance (since the reference frames are too large to fit into L2 cache). Disk I/O can be neglected due to DMA and Async I/O. Videomem bandwidth usage can be reduced further by using YUV420P overlay mode (12bits/pixel as opposed to YUV422 which is 16bits/pixel).

@COBRA

I always dreamed about using the UWSCSI chip of the CSPPC to copy blocks of memory between fast ram and gfx card ram.

I remember reading that some scsi chips could do that. Afaik bPlan used a chip to copy blocks of memory without using the cpu in the Efika (it's used to make hard disk work in DMA mode regardless of the problems of Freescale embedded P-ATA and also to copy from fast ram to gfx card ram).

I guess that it wouldn't save much time on hardware like A1 or Pegasos but for Classics it would be quite interesting (unfortunately that would require rewritting the scsi driver to add the new copy function).

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

Quote:

AMiGR wrote: @Rob Quote: Quote: Q: Is DRAGON able to execute 68k apps faster than G3 based boards? A: Yes. Most of 68k Amiga applications run faster on DRAGON ColdFire then in the JIT emulation on currently available PowerPC G3-based boards. Which we already know to be false... As it is, Trance is faster on a PowerUp board than the Dragon with its emulation...

Amigr, please don't be so fast with damming the Coldfire!
Its way to early to come to this conclusions.

What some people have seen so far was only a very early version of the Dragon
with a Workbench that was not fully optimized for the Coldfire yet.

Please ask yourself: What is the main reasons why 68k Amiga programs feel much faster running on MOS directly than on UAE on MOS?

The reason is, that the underlaying OS and GFX libraries need to be emulated in UAE and that this slows everything down => BIG TIME.

The same is currently true for the Dragon.
Give them a few weeks and wait for a Coldfire version of exec, gfx.lib and of some datatypes and the underlaying OS will run MUCH faster and so will of course all 68k programs run much faster too.



Cheers
Gunnar

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

@BigGun

Quote:

Amigr, please don't be so fast with damming the Coldfire! Its way to early to come to this conclusions.

I agree. While I also don't expect the Coldfire to outperform a 68060 on old 680x0-code, I find it a bit to early to draw such conclusions purely based on the speed that some icons show up on Workbench. There are too many factors that are *not* dependent on the CPU that could have a big influence on that, e.g. storage media (we see an USB-stick on the videos and when opening the drawers the Elbox guy is mentioning "flash") and WB patches (IconBeFast - big difference!).

@BigGun

Quote:

What is the main reasons why 68k Amiga programs feel much faster running on MOS directly than on UAE on MOS?

UAE emulates custom chips even when you are using P96. Amithlon didn't emulate custom chips and that's the reason it's faster. Amithlon run 99% of the system emulated and that didn't slowed it down. Bernd Meyer showed a 233Mhz iMac running OS3.9 with a modified UAE for Linux-PPC that used his preliminar JIT and it achieved 060 speeds and even surpassed it.

It's custom chip emulation what slows down UAE so much. You can try out BasiliskII and check out that the cpu hungry programs run much faster than on UAE simply because you don't have to emulate custom chips.

Interpretive emulation makes that a pityful 600Mhz g3 runs faster than a 060. With JIT emulation the speed is much much faster than on a real 060 so even if you ran most of software libraries emulated it would be much faster than a classic.

The supposed advantage of Dragon was that it was going to be capable of running unmodified 680x0 binaries faster than 060.

Even if you made an AROS-Coldfire version it won't be fast without a JIT. And the cpu emulation used by Elbox will probably slow down native coldfire apps too.

Quote:

Give them a few weeks and wait for a Coldfire version of exec, gfx.lib and of some datatypes and the underlaying OS will run MUCH faster and so will of course all 68k programs run much faster too.

I guess it will run faster than the crappy machine shown in the video, but it won't run 68060 programs faster than my CSPPC.

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

@Crumb

If you could DMA from RAM to videomem it would help, if the decoder was able to decode into another buffer while DMA is transferring data to videomem. Unfortunately avcodec.library does not support this. Also, DMA can only transfer data "as is" without any processing, while even for YUV overlay you have to rearrange the YUV data so that it is suitable for the display hardware. Also consider that a 25fps DVD resolution movie (720x576), using YUV422 overlay requires 720x576x25x2 bytes (20MB) to be transferred to videomem every second. On my CVPPC I had 15MB/s bandwidth to videomem, so even if you were doing nothing else but copying data from fastmem to videomem, it would not be fast enough for movies of such resolution.

@hatschi

Quote:

There are too many factors that are *not* dependent on the CPU that could have a big influence on that, e.g. storage media (we see an USB-stick on the videos and when opening the drawers the Elbox guy is mentioning "flash") and WB patches (IconBeFast - big difference!).

I have an AlgorUSB and that's USB1.1 instead of USB2 like the Spider they are using

I use PowerIcons with PNG icons and my A3640/30 shows them faster than the machine in the video

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

@COBRA

You could do like AmiDog did with his AMP2 video player and reduce the size of the screen transfered to video ram. The PIP mode will smooth the image slightly and will allow you to resize it to the size of the screen

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

@BigGun

Quote:

Give them a few weeks and wait for a Coldfire version of exec, gfx.lib and of some datatypes and the underlaying OS will run MUCH faster and so will of course all 68k programs run much faster too.

Aint "few weeks" little optimistic?

And when Dragon is going an emulation route are there possibly better (faster, cheaper) processors available than Coldfire? No, I dont mean PPC...

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

@Crumb

Quote:

I have an AlgorUSB and that's USB1.1 instead of USB2 like the Spider they are using

The "2.0" in Spider 2 doesn't mean that it is running at that speed, it is merely compatible to the USB 2.0 standard. It was frequently reported that the Spider 2 doesn't provide much of a speed advantage over comparable USB 1.1 cards.

@BigGun

Quote:

Amigr, please don't be so fast with damming the Coldfire! Its way to early to come to this conclusions. What some people have seen so far was only a very early version of the Dragon with a Workbench that was not fully optimized for the Coldfire yet.

Sigh, the Coldfire is advertised as a fast *68k* compatible solution. If the 68k *emulation* is slow, nothing will make it faster apart from a proper JiT. Even if you port the OS to ColdFire, what will make the actual *emulation* faster?

Quote:

Please ask yourself: What is the main reasons why 68k Amiga programs feel much faster running on MOS directly than on UAE on MOS?

Huh? Who is using UAE on MOS to run 68k programs apart from old games? MorphOS is AmigaOS compatible, it doesn't need UAE. Anyway, I *have* used Trance (the MorphOS JIT) on mostly 68k MorphOS back on the early betas, when it wasn't fully integrated into the system: The emulation (translation, actually) itself produced *fast* code anyway. Amithlon is fast on slow x86 machines while all it is running most of the time is the 68k OS and applications stuff emulated.

In fact... there is no reason to ask myself anything, or to think about it, I was using MorphOS long before it reached this fully PPC-native state and long before Trance was there. From all reports, the current version of the ColdFire is as slow as the first version of MorphOS was, 0.1, which was fully emulated, minus CyberGraphiX. Do you know what the difference is? MorphOS 0.1 was running on a PPC, a totally incompatible processor while the Dragon is advertised as a *68k* compatible solution. Hello? If it needs so slow emulation and requires a native OS to work properly, it *BLATANTLY* is not and *everything* we have been saying *all* along is *right*.

Quote:

Give them a few weeks and wait for a Coldfire version of exec, gfx.lib and of some datatypes and the underlaying OS will run MUCH faster and so will of course all 68k programs run much faster too.

They will not run much faster, in fact, they will *appear* to be running faster, due to them calling faster underlying functions. This will NOT make the 68k emulation itself any faster, which defeats the *whole* point of using a ColdFire.

_________________

@AMiGR

Quote:

From all reports, the current version of the ColdFire is as slow as the first version of MorphOS was, 0.1, which was fully emulated, minus CyberGraphiX.

So you are comparing a CPU (Coldfire) with an operating system (Morphos 0.1)?

@itix

Quote:

itix wrote: @BigGun Quote: Give them a few weeks and wait for a Coldfire version of exec, gfx.lib and of some datatypes and the underlaying OS will run MUCH faster and so will of course all 68k programs run much faster too. Aint "few weeks" little optimistic?

@ Itix:
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.

@ Ney sayerr
To behonest all I can't stand all these NEY-sayng any more.
I'll now compile Aweb and 194x for Coldfire.
I have no doubt that the coldfire version will run much faster on the Dragon.


Cheers
Gunnar

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