Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: on May 17, 2007, 02:35:57 PM
-
For more than 2 years now, Elbox has been publishing on their web site that they are going to make an accelerator that is based on the new Coldfire series of processors(Freescale, formerly Motorola).
Now for people out there who don't know what the Coldfire is, its what happened to the 68k when it refused to get faster. Coldfire processors are essentially 68k processors on steroids. They are dazzling fast but, they lost some instructions in the evolution process so they are not quite totally compatible with Amigas.
See: http://elbox.com/faq_dragon.html
Only a few weeks ago, I was arguing that it is possible, using present day technology, to make a 68k based Amiga that is much faster than a PC can emulate. Or more accurately, it is possible to make a 68k processor that is faster than an emulated one.
See: http://www.amiga.org/forums/showthread.php?t=28960
To give a scale of comparison, my real Amiga 3000 with Mercury 35MHz 68040 provides 26.45 MIPS of processing power. My dual core PC running WinUAE 1.4.2 provides around 190MIPS of processing power in 68040 JIT mode.
The Dragon, using a 266MHz (that's less than 1/10 the clocking of my PC Intel dual core processor) Coldfire processor promises to deliver... hold on to your hat... 410MIPS of processing power that is fully 68k compatible.
You should also know that a new 68060 processor costs around 600$. Such a CPU can deliver around 40MIPS of 68k processing power. The specific Coldfire model that is going to be used on the Dragon costs... 42$ !!!
That's 40 MIPS for 600$ vs 410 MIPS for 42$.
Are we going to see the rebirth of the 68k based Amiga or is this just a fad?
-
Vapour has already entered and is here to stay I'm afraid...
-
Just for the fun of it, I went to digikey's web site and searched for the MCF5475, which is the processor the Dragon is supposed to use.
They have it in stock. So I don't know for the accelerator part but the processor does exist, it is cheap and it is easy to get.
-
:horse:
-
The Dragon has been announced for ages and has yet to surface. The Coldfire processor isn't fully compatible it seems and software has to be recompiled for it. I don't know this for fact but if it's true then it could be the reason it has never been available. And it probably won't be ever...
Edit:
@Zac
Oh yeah I forgot our great new emoticon!
:horse:
-
Zac67 wrote:
:horse:
Well... I can see that hopes are very high indeed... :inquisitive:
-
What I've heard about the Dragon is that it requires a recompile of the code in order to get that performance. Running code through an emulator brings it down to about 68040 performance. Dragon is not worth the effort. :-(
-
Another thing to keep in mind, "mips" isn't really an accurate way to determine processor speed. You'll get different results depending on what instruction is being tested, and an emulator throws this out of whack anyway. (F.e, I get 1500 MIPS in SysSpeed within WinUAE, and around 90 on my 68060.)
My personal opinion is that the Dragon is pure vapor. No doubt, it would be very cool to see a fast 68k accelerator. I'm not so sure about seeing one faster than WinUAE on a modern PC though. ;-)
-
My personal opinion is that the Dragon is pure vapor.
I agree that it might be "vapor" in a sense that it will probably never get released.
But calling it "pure vapor" suggests that it simply doesn't exist and was never seen running.
A year ago the Dragon was demonstrated at a Polish meeting. (http://tdolphin.org/amikrak/amizaduszki2006.php) Some movies here. (http://dahoo.untergrund.net/other/az_xvid/)
-
Well, well... sometimes you gotta dig...
68k compatibility has been a big issue with Colfire processors and microcontrollers.
There has been a big pressure on Freescale for them to release a version of the Coldfire that is compatible enough NOT to require recompiles to run 68k code.
Of course, the Coldfire series has instructions of its own but the reason for the Dragon to take so long is because the V4e series of Coldfires were delayed.
Only the V4e core provides sufficient 68k compatibility to consider using it in a 68k compatible system. And yes, there are tremendous speed losses when doing so. Native Coldfire instructions are much faster.
Still, at 266 MHz, an accelerator like that should be expected to provide around 200 MIPS. Kiss you 68060 goodbye...
I doubt, however, that Freescale had the Amiga anywhere near their minds when they came up with the compatibility embedded in the V4e.
-
If the speedloss is so big that it underperforms my current 060 then I won't kiss it goodbye!
A lot of old 68k software won't be recompiled for coldfire. Authors and/or source code are long gone.
-
Flashlab wrote:
If the speedloss is so big that it underperforms my current 060 then I won't kiss it goodbye!
A lot of old 68k software won't be recompiled for coldfire. Authors and/or source code are long gone.
I think this should make for an accelerator that is just above twice the speed of the fastest 060 without recompilation.
But since the CPU is less than 1/10 the cost of the 060, that is where the final result should be very impressive.
It also has a DDR-SDRAM controller built-in, Ethernet controller built-in, USB built-in and other goodies...
That should make for a features and power packed little device that should cost around 200$.
That is, of course, assuming the V4e core can deliver on its compatibility promise. But seeing it play DiVX movies on an OS 3.9 workbench really gets me salivating...
I suppose if it is possible to have librairies specifically for the 68060 then I guess it should also be possible to have some for the Coldfire that uses some of its faster native instructions.
-
410MIPS of processing power that is fully 68k compatible.
NOT ! Coldfire is not fully 68k compatible. emulation degrades it to normal 68040-68060 performance. That's why elbox abandoned/shelved it. Now, if we were in the early 90's, and software vendors were available/willing to recompile their stuff for coldfire, it would be meaningful, but unfortunately we're in 2007, and there isn't any software vendors around, so coldfire is mostly a useless effort. still I would like elbox to release it. maybe if some crazy person ports a decent browser to it, it may be profitable, NOT. but probably wouldn't hurt elbox anymore, since they already did the R&D.
-
Is there any valid reason why a coldfire couldnt run a hotspot-JIT for 68K?
-
countzero wrote:
410MIPS of processing power that is fully 68k compatible.
NOT ! Coldfire is not fully 68k compatible. emulation degrades it to normal 68040-68060 performance. That's why elbox abandoned/shelved it. Now, if we were in the early 90's, and software vendors were available/willing to recompile their stuff for coldfire, it would be meaningful, but unfortunately we're in 2007, and there isn't any software vendors around, so coldfire is mostly a useless effort. still I would like elbox to release it. maybe if some crazy person ports a decent browser to it, it may be profitable, NOT. but probably wouldn't hurt elbox anymore, since they already did the R&D.
Apparently you didn't read what I just posted above.
I said the full compatible instructions cause a loss of performance.
Nonetheless, if the V4e provides similar performance to a 68060, the 060 costs more than 600$ (just the chip) while the 5475 costs 42$.
It still makes for a very low cost and quite powerful box.
But considering what I found to post the previous message, I would still expect it to outperform the fastest 060 2:1.
-
mel_zoom wrote:
Is there any valid reason why a coldfire couldnt run a hotspot-JIT for 68K?
JIT implies emulation. On the V4e core there is no need for emulation.
It is simply that, just like on a real 68040/68060, instructions take more than one cycle to complete.
However, the fastest 68060 runs at 75MHz. Presently, the V4e core is available at up to 266MHz.
Also, while the 68060 has a total of 16k of cache, the MCF5475 has 64k. Plus an internal 32k of super fast SRAM that's perfect to put an ultra fast stack.
Also, since the V4e core has a built-in DDR-SDRAM controller, you can have external RAM just as fast as the CPU itself... making the cache only useful to alleviate the RAM's latency.
-
There are tools on the Freescale site that supposedly analyze a 68k .exe and convert it to a cf .exe. I don't see why as a user, I run this app on my 68k executables and save the new version off as run it and see what happens.
...but anyway, I thought the big problem was the lack of a "Supervisor" mode...
-
nobody is building anything... there are like 10 guys left in the amiga scene.... not realy a "market".
Want a new amiga... look on eBay.
-
The only way to get a Coldfire running 68k software is to compile a huge database that knows how to patch every little bit of software around (you can call it the Microsoft approach, that's 'Legacy Support' in Windows) - a gigantic effort and no one is going to do it.
If you consider using JIT: no point in using a Coldfire in the first place. A fast, basic x86 mainboard + CPU is available for little more than $100 (see Amithlon) - why spend more on a board that actually offers less? Because the x86 board is able to run Windoze? Come on...
-
This forum has allready had a thread about recompiling for Coldfire (feck knows were, I can't be bothered to look)and if I remember correctly "clean system friendly code" was pretty much a case of pumping the code through the above mentioned tools. Not all code is "clean" & "system friendly" however but I don't recall the specifics.
The Polish demonstration showed the Dragon as being rather impressive and I have little doubt that many Coldfire naysayers are only saying "can't do, won't do" due to some bizare retro 68k religious attitude.
All that's said and done is just a big steaming pile of nonsense until......I've said it before and here I go again....IT'S ALL WORDS UNTIL THE SILICON IS IN MY HANDS!!!! :-D
-
@guru-666: you can call me naive, you can call me stupid :-D or you can call me a true believer...but...
Less than 2 years ago, i was almost the ONLY Amiga user in this part of the world.
NOW, we are over 25 ACTIVE & proud Amiga users. (So your guessing of 10 Amiga users should count up to 35 now)
Some of them come from different platforms, some of them have a LOT of skills (and i mean A LOT), and are willing to do almost anything to keep the platform alive
Unfortunately (for them), not all of them can read/speak english , so im kind of "official translator" or something like that, when it comes to talk about news or anything Amiga-related :-D
Anyway, to my point: some of them, suggested me yesterday, if it would be possible to make an accelerator for the Amiga using parts of Macs (i know it may sound like insane to some of you, but this friend actually thinks that using some custom chips from Macs he can build Amiga ccelerators, if instructions are given to him. Hes got a lot of knowledge about soldering & about chips, has a lot of tools to do the job, he even told me he might be able to fix one of my defective PPC cards (i yet have to see that to believe), he has a lot of love for the platform and wont let her die..)
Anyway, guys, i know that a lot of talented, full of skills and very capble guys of the Amiga scene read this, so if anybody has any toughts about how to assemble an accelerator...drop me a line...
Regards
Sebastian
-
Zac67 wrote:
A fast, basic x86 mainboard + CPU is available for little more than $100 (see Amithlon) - why spend more on a board that actually offers less? Because the x86 board is able to run Windoze? Come on...
Oh come on, you know why, It all comes down to what you consider an Amiga to be. Some people need the real thing, others are happy with emulation. I use my creaking old A1200T in favour of UAE most of the time and my PC is way faster (AMD 4200 X2), it just "feels" better. :-D
-
@gavilan
I would say naive would be the bast way to describe it your perspective.
BTW there are 5000 isch members on this site alone. thats tiny in the persepective of a market. (I don't think that all 5000 are active members either.)
when I said that there where only 10 users left, I was exagerating. there are maybe 5000....worlddwide... LOL. Not all current amiga users care about some coldfire nonsense that has nothing to do with the amiga anyway.... so maybe you move a few hundred units.... best of luck with the future.
@Zac67
zac is right! whats the point exactly?
-
@ Gavilan
Cool, I just signed up to an Open University course to study a Ba Sci +Honours in Computing and design. I hope the platform still survives (and grows) by the time I finish. It would be good to give something back to the machine that got me into computers in the first place. :-D
-
.....and no, before anyone thinks I'm totally mad, I did not join the OU to become an Amiga developer. That would be ...silly.
-
Zac67 wrote:
The only way to get a Coldfire running 68k software is to compile a huge database that knows how to patch every little bit of software around (you can call it the Microsoft approach, that's 'Legacy Support' in Windows) - a gigantic effort and no one is going to do it.
:madashell: :madashell: :madashell:
Its NOT needed in the V4e core!!!
All previous cores needed that but not on the V4e!!!
Anyways, at 42$, a Coldfire is actually much cheaper than x86.
-
eslapion wrote:
Its NOT needed in the V4e core!!!
All previous cores needed that but not on the V4e!!!
Well, yes and no. The V4e solves most of the bigger compatability problems, but it's not perfect. There are a couple of multiplication instructions that set flags on 680X0 chips but don't on ColdFire and the floating point format isn't compatible (80-bit vs 64-bit IIRC). Plus there are still a bunch of instructions that aren't implemented on the V4e so you either need to emulate those instructions by trapping exceptions (as the library supplied by Freescale does) or write a dynarec/JIT that translates the offending instructions before executing them.
-
Anyways, at 42$, a Coldfire is actually much cheaper than x86.
Cheaper than what x86 ?
Just for fun checked a big german mailorder shop (for endcostumers), and voila! AMD Sempron64 3000+ (boxed and with VAT) for 30 Euro :crazy:
-
MskoDestny wrote:
eslapion wrote:
Its NOT needed in the V4e core!!!
All previous cores needed that but not on the V4e!!!
Well, yes and no. The V4e solves most of the bigger compatability problems, but it's not perfect. There are a couple of multiplication instructions that set flags on 680X0 chips but don't on ColdFire and the floating point format isn't compatible (80-bit vs 64-bit IIRC). Plus there are still a bunch of instructions that aren't implemented on the V4e so you either need to emulate those instructions by trapping exceptions (as the library supplied by Freescale does) or write a dynarec/JIT that translates the offending instructions before executing them.
Freescale says the 68882 is available as an external peripheral to the Coldfire. Do they make 266MHz version of the 68882?
If so then there is a potential solution to the floating point problem.
As for the instructions that require trapping, how do the Freescale library perform?
-
In my understanding the V4(e) core needs a Program (the CF68klib which is provided by Freescale (Programed by MicroAPL) to run 68k code properly.
There are two ways this CF68kLib works
a) Run code, trap out when needed -> The opcodes that are "double" in 68k and CF and behave differently can not trap out and do whatever they should do in Coldfire world. Maybe that is a bit different to what they would do on 68k.
There are only a few (4?) opcodes that are double between 68060 and coldfire V4e instruction set an behave differently, but it is a valid point when speaking about binary compatability.
b) Set up an virtual 68k on Coldfire but without MMU and FPU, run 68k code. One problem could be if you want to emulate an 68060 (because there are only a few (4?) opcodes that are double between 68060 and coldfire V4e instruction set) that you probably need an MMU for your AMIGA to work...
You could emulate an 68030 but i think it has more unupported instructions, which should slow down the Emulation...
Someone (i think his name was Darek Smirtana?) from Elbox wrote in a forum post that they had to write their own software because the one that was provided by Freescale did not work, without getting more specific.
I also think (like eslapion) that if the Coldfire V4e at 266MHz gives a raw Power on 68k code that is at least at an level of an 68060 @ 100MHz i will be fine with it. One could argue that a 68k emulator on an embedded PPC is faster then "Emulation" on the Coldfire and probably cheaper but that is another thing.
The price difference between the Chips (68060 vs Colfire) and goodies (USB/Ethernet/PCI) that come with the Coldfire speak for the Coldfire. Performance wise there are only guesses, and a little Screenshot from ATARI Coldfire Project where "Raw Power" of an Coldfire developer board (V4 @ 200MHz, TOS under 68k Emulation) is equal to TOS running on a real ATARI that is equipped with a CT63 Accelerator (68060 @ 100 MHz)
As for the x86, i somehow have a bad feeling about having one in my AMIGA. It's fine for my PC running UAE but not for the Miggy. If it were for the money i would have sold my Blizzard 1260 on eBay for 200€-300€ already...
-
:-o Deja Vu :-o
This thread has happened before....
-
Eslapion, I don't want to destroy your hopes, but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. What you thought was DivX playback was just a DVD player hooked up to the TV card in the demomachine.
Anyway I'm surprised that the Dragon (even as a prototype) even came into existence, something I alway heavyly doubted. I stand corrected at that one.
-
Tripitaka wrote:
:-o Deja Vu :-o
This thread has happened before....
As there is not much to talk about in Amiga land... better to talk about the Coldfire then about the (bad) weather... :lol:
-
Lemmink wrote:
... but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. ..
The thing that i do not understand is: The Coldfire is (Mips wise) roughly 4 times faster than a 68060 @ 70 MHz it shares a good lot of instructions/adressing modes with the 68k (75%?). Why shouldn't it reach the performance of an 68060 or more? :-?
-
Lemmink wrote:
Eslapion, I don't want to destroy your hopes, but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. What you thought was DivX playback was just a DVD player hooked up to the TV card in the demomachine.
Well, that really leaves one on his appetite... at least when compared to the performance that seems to have been obtained with the Atari Coldfire project.
-
I must admit it's only a screenshot, actually it is about porting PCI drivers to Atari but as the guy had no ATARI PCI device he used his Coldfire Evaluation Board (from the ATARI Coldfire Project) for development, and i stumbled over the Screenshot...
Link, look in lower half -> the two pictures before the GFX Card... (http://perso.orange.fr/didierm/ct60/ctpci-e.htm)
I do not know which instructions are used in the Tests/Benchmark and how accurate it is.
-
We'll get no real answer to all this until we get an actual Coldfire based accelerator.
The compatibility issue is seemingly no worse than going from 68040 to 68060 and everything that wouldn't work we'd either have to pre-process, emulate or shunt back over to the 68020 (in A1200 or whatever).
Can it be done? Yes, will it be done. Who cares anymore.
-
Here is another project I have located for the Amiga that is based on the Coldfire.
http://www.cdtv.org.uk/coldfire/
-
Why dont make contact with them and try some interview about Dragon and Shark, future of Elbox..
Now is good time becouse of half time between Amiga and Hyperion.
-
Donar wrote:
Lemmink wrote:
... but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. ..
The thing that i do not understand is: The Coldfire is (Mips wise) roughly 4 times faster than a 68060 @ 70 MHz it shares a good lot of instructions/adressing modes with the 68k (75%?). Why shouldn't it reach the performance of an 68060 or more? :-?
Exceptions are rather expensive on modern pipelined processors as the pipeline has to be flushed. The V4e has 9 pipeline stages so each time it hits an unimplemented instruction it burns through 9 cycles before the first instruction that emulates the missing one finished completion and it is going to need to execute several instructions to simulate the missing one. The 68060 can execute >1 instruction per cycle on average (note that it takes longer than 1 cycle for an instruction to complete because of pipelining, but more than one instruction is inflight at a time). So it probably takes a ColdFire CPU upwards of 10 cycles to execute certain instructions that might have taken effectively 1 cycle or less on the 060, but the ColdFire is only clocked about 4 times as fast.
A well written dynarec should have a much lower performance penalty, but it's much harder to write than a trap based solution.
-
I wrote them last month and they claim the dragon's still planned to be released. Just finishing up software.
-
I just spoke to an electrical enginer who's more into digital electronics than me.
He said the trapping method could be replaced by a huge (about 256MB) look up table that would essentially become the microcode for a conversion processor.
Essentially, you get the coldfire to run as a sort of interpreter that runs in loops into the 256MB and that tells it how to interpret the real 68k code.
This way, there is no flushing the pipeline.
-
Flushing the pipeline is a problem when using a exception based approach (which isn't entirely possible) - you're talking about emulation. Plus, there are more efficient ways to emulate without huge lookup tables.
The only way you'd really get the most out of a CF would be to combine all these methods and let the task scheduler choose the appropriate one based on a database: all unknown tasks run through a JIT compiler (lowest speed), some known tasks are patched during load time and flagged as CF compatible (full speed).
This would add a tiny bit overhead to the scheduler, but permit 'clean' software to run full speed. You can even start out JITing everything and add patches later through updates.
After all, it's not impossible, but may not be worth the while.
-
eslapion wrote:
Here is another project I have located for the Amiga that is based on the Coldfire.
http://www.cdtv.org.uk/coldfire/
That would be Oli_hd's project that has fallen on hard times.
The difficulties of developing such a thing on your own are quite amazing I'd imagine. Still he did seem to get pretty far with it all, certainly at the electrical level, not so sure on the software running front.
I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint* :-D
Andy
-
eslapion wrote:
I just spoke to an electrical enginer who's more into digital electronics than me.
He said the trapping method could be replaced by a huge (about 256MB) look up table that would essentially become the microcode for a conversion processor.
Essentially, you get the coldfire to run as a sort of interpreter that runs in loops into the 256MB and that tells it how to interpret the real 68k code.
This way, there is no flushing the pipeline.
;-) :-) :-D :lol: :roflmao:
Trust me, pipeline flushing would probably be *much* faster than this! Randomly accesed large lookup tables (anything larger than the cache) hammer any CPU, simply because memory access is generally one of the slowest things they do and such lookups tend defeat caches completely.
However, I doubt that such a lookup table would need to be quite that large. If you assume 680x0 code uses 16-bit instruction words most of the time, you'd need 65536 entries in your table. It would be larger than this due to extended opcodes, but 256MB is basically an immense overestimate.
Regardless, you are still talking varions memory read and computed jump instructions before you even get to emulating your opcode. This is not going to be quick at all.
I once wrote a small VM as an exercise that works in the manner you are suggesting. It has 256 possible instructions (an enumeration) and 16 general purpose registers (and some stack pointers) employing a load-store architecture. Instructions generally consist of byte pairs, one for the instruction and one for the effective address (mostly register to register, but depends on the instruction type).
A hand optimised assembly version of the interpreter uses a computed jump that is about as efficient as it can get for this (each instruction handler has the code required to calculate the next jump inlined onto the end of it, so you dont branch from a central loop out to a handler and back). The code table is about 16K, each handler starting at a cache aligned address.
It's an order of magnitude simpler than a real 68K and it gets about 2 MIPs on a 25MHz 040. With any luck you'll see this is not going to be a realistic option for a coldfire native 68K emulation.
-
A dynarec/JIT doesn't really have to be all that slow. You don't have to deal with the mess of emulating a fundamentally different architecture, just expanding certain unimplemented instructions into multiple implemented ones. You don't have to deal with register mapping or simulating flag behavior (well except for those previously mentioned multiply instructions). Plus in theory, a sufficiently advanced dynarec can actually improve performance. HP's Dynamo is a dynarec that doesn't do any translation between architectures it just does processor specific optimizations and optimizations that can only be reasoned about at runtime.
-
So, a thought....
How much more compatible is the v4e coldfire in instructions to say a 68020 or a 68000. Why do we need to emulate all instructions on a 68060 for?? most of the 68k apps are 020 or 68000 compatible versions. If it's easier to trap 020 code for exceptions than it is the multitude more on 060, why not forget about 060 completely.
I would rater a 200Mhz 020 based processor than a 100Mhz 060. Any newer programs designed from that day forth could be coded in native coldfire and hense get a speed increase. There is no real benifit to emulate an 060 or even 040. Winuae runs all the programs I use on 020 just as fast and I can always add in the 881 fpu if I want to use it that is and that's completely software emulation.
-
SHADES wrote:
I would rather a 200Mhz 020 based processor than a 100Mhz 060.
I'd buy a 200Mhz 020 anyday.
-
SHADES wrote:
So, a thought....
How much more compatible is the v4e coldfire in instructions to say a 68020 or a 68000. Why do we need to emulate all instructions on a 68060 for?? most of the 68k apps are 020 or 68000 compatible versions. If it's easier to trap 020 code for exceptions than it is the multitude more on 060, why not forget about 060 completely.
I would rater a 200Mhz 020 based processor than a 100Mhz 060. Any newer programs designed from that day forth could be coded in native coldfire and hense get a speed increase. There is no real benifit to emulate an 060 or even 040. Winuae runs all the programs I use on 020 just as fast and I can always add in the 881 fpu if I want to use it that is and that's completely software emulation.
Actually, the thing that makes a 68040 run faster is the fact that it has fewer instructions built into it when compared to the 68020/68881 combination.
And the 68060 has even fewer instructions than the 68040.
In reality, what makes these processors more complex is the caching system and the pipelining architecture.
In the A1200, caching for the 68020 has no usefulness at all because the RAM is just as fast as the CPU. Not so when you run a 68060 at 60MHz or more.
Even if you can buy DDR SDRAM that runs at 266MHz or much faster nowawadays, we still have a serious problem of latency and caching is still necessary. In order to take advantage of the higher speed of this type of memory, you have to have burst access and only the 68030 and up have that.
So, even if you have a 68020 running at 200MHz, if its RAM responds at an equivalent speed of 20MHz because of lack of caching and burst access, what you'll end up with is like a 68020 running at 20MHz.
-
MskoDestny wrote:
A dynarec/JIT doesn't really have to be all that slow. You don't have to deal with the mess of emulating a fundamentally different architecture, just expanding certain unimplemented instructions into multiple implemented ones. You don't have to deal with register mapping or simulating flag behavior (well except for those previously mentioned multiply instructions). Plus in theory, a sufficiently advanced dynarec can actually improve performance. HP's Dynamo is a dynarec that doesn't do any translation between architectures it just does processor specific optimizations and optimizations that can only be reasoned about at runtime.
Precisely. If you look up the other N threads about coldfire/68k compatibility you'll see I've given HP Dynamo as a working example of how a coldfire 68K-JIT could work.
-
I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*
Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.
I have backtracked to the MCF5206 Coldfire which seems to have a bus that may suit the miggy more (There isnt a 5406 though, so if this did work I dunno where it would take me, except freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)
Im also doing a few other bits just to get more insite into miggy specifics. (AKA Im playing about with stuff)
-
@Karlos:
Your posts are the only reason I know about HP's Dynamo. I just couldn't remember who had brought it up.
Oli_hd wrote:
Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
Out of curiousity, what in particular about the MCF5407 bus was the problem?
A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.
Too bad the 5407 is the only V4 or V4e Coldfire that isn't in the hobbyist unfriendly BGA package.
freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)
I would guess it's for high volume customers that are ordering in the kind of quantities that make a custom manufactured part practical. I could be wrong though.
-
Oli_hd wrote:
I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*
Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
A V4e CF card may work, assuming you used the PCI bus of the CF as the interface between the CF and the miggy while keeping all address mapped correctly.
That seems to be a problem even with the 68060 etc accelerators too (though different I admit) would it require something like the GAL arrays or FPGA based bridges that they use to translate bus addressing and data signals?
Oli_hd wrote:
I have backtracked to the MCF5206 Coldfire which seems to have a bus that may suit the miggy more (There isnt a 5406 though, so if this did work I dunno where it would take me, except freescale have put up a "Make your own Coldfire" proggy which you build from the basic blocks and when the design is done it gets e-mailed to Freescale... what happens then I dunno, if enough people want the same thing maybe it gets made)
Im also doing a few other bits just to get more insite into miggy specifics. (AKA Im playing about with stuff)
Isn't the 5206 even less compatible with the 68k line than the 54XX series though? Or are you approaching it as a co-processor this time rather than a replacement host cpu?
Sorry for all the questions but it was reading about your CF project that prompted me to dig out my A1200 again and re-catch the Amiga bug... Dennis and the MiniMig just sealed the deal :-D
Andy
-
Oli_hd wrote:
AJCopland wrote:
I've always hoped he'd open source everything if he didn't plan to take it any further *hint-hint*
Wouldnt help Im afraid, my problem was with the coldfire/68K bus interface with the V4 CF.
Maybe someone could give you a hand if he sees more of your card/glue logic...
AJCopland wrote:
That seems to be a problem even with the 68060 etc accelerators too (though different I admit) would it require something like the GAL arrays or FPGA based bridges that they use to translate bus addressing and data signals?
...
Andy
Not that i know what i'm talking about, but maybe the information i heard helps...
For a Coldfire card to work it had to imitate dynamic bus sizing of the 030 (like it's done on the 040/060 cards) so i think your GAL/FPGA guess is right.
The information needed for this interface should be available from Motorola/Freescale but their implementation is not the fastest one. But hey it's a start.
-
so? What's happening? Any indication the dragon might still be released? Is Elbox still trading?
(please don't reply if you "believe" or are "convinced" it won't be released - unless of course you have some evidence to that effect)
-
Donar on 2007/5/17 22:11:49
Lemmink wrote:
... but the Elbox coldfire will never go faster then any 68060 accelerator for the Amiga. The outcome of the presentation was that the card ran unmodified / optimised software at the speed of an 68040 at about 33 MHz. ..
The thing that i do not understand is: The Coldfire is (Mips wise) roughly 4 times faster than a 68060 @ 70 MHz it shares a good lot of instructions/adressing modes with the 68k (75%?). Why shouldn't it reach the performance of an 68060 or more?
I explained this 4 years ago in June 2003 already. See ColdFire V4 Amiga accelerator project from the m68k emulation perspective (http://www.iki.fi/sintonen/coldfire-v4-m68k.txt).
Anyhow, my prediction for the resulting speed wasn't far off. Dragon is actually slower than my predictions for the practical coldfire accelerators.
-
Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished. After 2006-dec-24, when hyperion announces that os4 finally finished, the ppc cards marketed, its available in Q1/2007. After 31th of March it is changed to Q2/2007. Now we're in the last day of q2/2007. So back to the dragon, i think the situation is the same. it will still the same in this year, if you asking me.
-
-D- wrote:
Another thing to keep in mind, "mips" isn't really an accurate way to determine processor speed. You'll get different results depending on what instruction is being tested, and an emulator throws this out of whack anyway. (F.e, I get 1500 MIPS in SysSpeed within WinUAE, and around 90 on my 68060.)
My personal opinion is that the Dragon is pure vapor. No doubt, it would be very cool to see a fast 68k accelerator. I'm not so sure about seeing one faster than WinUAE on a modern PC though. ;-)
Allow me : MIPS = Meaningless Indicator of Processor Speed
-
@derringer3
Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished.
When OS4 is finished? Even that is currently under debate. For the lawsuit, Hyperion wants to make it appear that it was finished in 2003/2004, Xmas 2006 they said that "It's done" and some months ago they announced that they are preparing the final ISO including packaging. So we have three dates that could be interpreted in such a way that "OS4 is done".
Elbox would still choose another date. Preferably one that lies far far in the future. :-P
-
humppa wrote:
@derringer3
Look, in elbox's webpage the Sharkppc cards were marketed that these cards will go into production when os4 finished.
When OS4 is finished? Even that is currently under debate. For the lawsuit, Hyperion wants to make it appear that it was finished in 2003/2004, Xmas 2006 they said that "It's done" and some months ago they announced that they are preparing the final ISO including packaging. So we have three dates that could be interpreted in such a way that "OS4 is done".
Elbox would still choose another date. Preferably one that lies far far in the future. :-P
Elbox has stated that production of shark will procede when OS4 is released. It has not been released and may not be for a while now with the ongoing court case. Why would anyone buy a shark PPC if there is not an OS to run it on?
-
Wake up and smell the java. There will NEVER EVER be a shark PPC.
-
Ok, os4 is not relased, or more to the point i can't buy it to my beloved a1200ppc.
But above all, if these elbox products is ready for the productions, elbox why don't relase any preview for its speed benchmark under pre relased (beta,test version, etc) os4. Or some review, technical specification working with real-life apps, games etc. in an on-line or printed magazine. Or at least in its own webpage. Or do something.
-
But above all, if these elbox products is ready for the productions, elbox why don't relase any preview for its speed benchmark under pre relased (beta,test version, etc) os4.
Because they don't have any access to OS4. I also doubt they are in contact with Hyperion or Amiga Inc in any kind of form.
There will never be a SharkPPC. Get over it. Btw, the prices of the Sonnet Crescendo (http://store1.sonnettech.com/product_info.php?cPath=22_30&products_id=37) are simply hilarious compared to the prices that Elbox states for the SharkPPC. Not that we aren't used to that however...
-
Piru wrote:
I explained this 4 years ago in June 2003 already. See ColdFire V4 Amiga accelerator project from the m68k emulation perspective (http://www.iki.fi/sintonen/coldfire-v4-m68k.txt).
Thanks for the link, i think i already had read it at some time but hope(d):
a) You are over pessimistic about performance problems.
b) Your conclusion that Coldfusion would be slower than a 68060@50 would be based on the CFV4@162Mhz (as we now have a 266MHz part).
Hey Elbox release the Dragon, then we can see if it's crap or not.
-
Is the coldfire range still being developed for? I think Elbox had mentioned the Dragon being fully upgradable with future coldfire revisions, so maybe what their waiting for is a newer chips, or again maybe not :lol:
-
Akiko wrote:
Is the coldfire range still being developed for?
Motorola/Freescale "presented" a Coldfire V5 in 2002 it should have been two times faster than the V4... whatever happened to it...