Welcome, Guest. Please login or register.

Author Topic: Coldfire - Binary Compatible  (Read 7606 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline hbarcellosTopic starter

  • Sr. Member
  • ****
  • Join Date: May 2006
  • Posts: 426
  • Country: 00
    • Show only replies by hbarcellos
Re: Coldfire - Binary Compatible
« Reply #14 on: January 30, 2008, 02:06:30 AM »
In my rumble opinion, FPGA is emulation. You code something generic to act like the real thing.
Makes no difference to me to take a x86 laptop with amithlon and TVOUT or a fpga "One chip Amiga".
}~ A1200 - Apollo 68040 - HOTLY running OS 3.1
}~ Powerbook G4 1.67 running MorphOS 3.2 without Wifi.
}~ Powermac Quicksilver 933 with Radeon 9600 XT (r300) LOUDLY running MorphOS 3.2
}~ [MY iOS GAME]: http://goo.gl/S9nWB (Amiga users can get it FREE[/color], just ask me)
 

Offline Plaz

Re: Coldfire - Binary Compatible
« Reply #15 on: January 30, 2008, 03:12:59 AM »
Quote
is stopped due the incompatibilities of the Coldfire versus a true 68k.


Not entirely true. According to his last emails, he's still messing with a design that would use a coldfire as a pluggable replacement for cpu cards that have a soceted 68030s. Even if succesful though, there would be code compatibility issues with some software.

Plaz
 

Offline rkauer

  • Hero Member
  • *****
  • Join Date: May 2006
  • Posts: 3263
    • Show only replies by rkauer
Re: Coldfire - Binary Compatible
« Reply #16 on: January 30, 2008, 05:24:54 AM »
 Then it will be big news!

 But I'm afraid, without some hardware between the CF and the 030 socket to intercept bad code the board will stuck again.
Goodbye people.

I\'ll pop on from time to time, RL is acting up.
 

Offline alexh

  • Hero Member
  • *****
  • Join Date: Apr 2005
  • Posts: 3644
    • Show only replies by alexh
    • http://thalion.atari.org
Re: Coldfire - Binary Compatible
« Reply #17 on: January 30, 2008, 09:16:37 AM »
Quote

eslapion wrote:
Anyways, with Tobias's TG68 and FPGAs getting better and better, soon we will be able to run a virtual 68060 at 250MHz or more using simple programmable logic chips.

Yeah right... NOT. Maybe in 10 years or so.

Quote
We can already run the 68000 at nearly 100MHz using cheap FPGAs.

They are hardly cheap, they still cost more (including an adapter PCB) than a real chip.

Due to the architecture, a 100MHz 68k would be lot slower than a 50MHz 060. Not to mention it doesn't have an MMU or FPU.

Add to that, Tobias's TG68, while a great achievment, is not 100% 68k compatible (yet).
 

Offline pyrre

Re: Coldfire - Binary Compatible
« Reply #18 on: January 30, 2008, 10:58:14 AM »
I dont know what difference it would make, but reading the specs of the two prosessors reveal that the 68k is based on CISC instructions. And the coldfire is a 68k core but is designed as an RISC based CPU.
So... what difference does that make?
Amiga 1200 Tower Os 3.9
BPPC 603e+ 040-25/200, 256MBram, BVIsionPPC, Indivision AGA MK2.
Amiga 2000 (rev 4.0) Os 1.2/1.3
2088 bridgeboard, 2MB ram card, 2091 SCSI.
Amiga 500+ Os 2.1
Derringer 030, 32MBram, Buddha in sidecar, Indivision ECS.
Amiga CD32
Video decoder
 

Offline Painkiller

  • Sr. Member
  • ****
  • Join Date: Jun 2007
  • Posts: 255
    • Show only replies by Painkiller
Re: Coldfire - Binary Compatible
« Reply #19 on: January 30, 2008, 11:03:59 AM »
Hmm where is that Elbox Dragon 1200 ;)
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Coldfire - Binary Compatible
« Reply #20 on: January 30, 2008, 11:04:42 AM »
@pyrre
Quote
68k is based on CISC instructions. And the coldfire is a 68k core but is designed as an RISC based CPU.
So... what difference does that make?

None. Whatever the CPU does internally to actually execute the instructions is irrelevant.

In similar way modern x86 CPUs are RISC, but execute x86 CISC code. See Wikipedia: x86, Current implementations
 

Offline Plaz

Re: Coldfire - Binary Compatible
« Reply #21 on: January 30, 2008, 11:41:30 AM »
@Painkiller

Quote
Hmm where is that Elbox Dragon 1200 ;)


Probably still trying to work out issues #1 and #2 in my post above. One rumor was that they had made good progress with compatibility, but speed suffered because of it.

It's possible to request a custom coldfire chip from freescale. Such a chip might help with I/O and speed issues. I've wondered if Elbox ever tried. But the production run would probably be too small and expensive to make it feesable.

Plaz
 

Offline Fransexy_

  • Sr. Member
  • ****
  • Join Date: Feb 2005
  • Posts: 317
    • Show only replies by Fransexy_
Re: Coldfire - Binary Compatible
« Reply #22 on: January 30, 2008, 12:17:35 PM »
Quote

Plaz wrote:
@Painkiller

Quote
Hmm where is that Elbox Dragon 1200 ;)


Probably still trying to work out issues #1 and #2 in my post above. One rumor was that they had made good progress with compatibility, but speed suffered because of it.

It's possible to request a custom coldfire chip from freescale. Such a chip might help with I/O and speed issues. I've wondered if Elbox ever tried. But the production run would probably be too small and expensive to make it feesable.

Plaz


I saw the video of the dragon and it work perfect.And people complained that it was slow because they took various (o lot) seconds to display a web page with a dragon pic.The case is that i put my browser on a core duo 1,6 GHZ on that page and the pic was not displayed much more faster than the coldfire.So i thinks that the test used in the demo of the dragon was not a fortunate ones because they are slow operations even on multiGHZ systems
DON\'T TAKE LIFE SO SERIOUSLY AFTER ALL NOBODY GETS OUT ALIVE OF IT
 

Offline Protek

  • Full Member
  • ***
  • Join Date: Aug 2005
  • Posts: 164
    • Show only replies by Protek
Re: Coldfire - Binary Compatible
« Reply #23 on: January 30, 2008, 12:44:21 PM »
Could an FPGA be used as a "middleman" with coldfire to handle the compatibility issues? In other words the FPGA would hold the logic to make instructions compatible in both directions in case an instruction was incompatible.

My knowledge about FPGA's and integrated chips is superficial, so I apologize, if this is a stupid suggestion.
A4000/040 3.1/3.1, 2 MB Chip, 24 MB Fast, Piccolo SD64 2MB, GVP A2000mHC+8 Rev2, 4 GB CF HD via CF IDE
A1200 3.1/3.9, Blizzard 1230MkIV 030@50 with SCSI kit, 2 MB Chip, 128 MB Fast, 1 GB CF HD via CF IDE
A600 3.1/3.1, 2 MB Chip, A603, 1GB CF HD via CF IDE
 

Offline MASACREWILL

  • Full Member
  • ***
  • Join Date: Apr 2002
  • Posts: 134
    • Show only replies by MASACREWILL
Re: Coldfire - Binary Compatible
« Reply #24 on: January 30, 2008, 01:00:24 PM »


Quote
I saw the video of the dragon and it work perfect.And people complained that it was slow because they took various (o lot) seconds to display a web page with a dragon pic.The case is that i put my browser on a core duo 1,6 GHZ on that page and the pic was not displayed much more faster than the coldfire.So i thinks that the test used in the demo of the dragon was not a fortunate ones because they are slow operations even on multiGHZ systems


..I have that video on my PC HDD, but I don`t remember where I found it on the net.. actually Dragon Coldfire looked pretty fast, but the demonstration was not very lucky.. I wonder why they are not offering  Dragon and what is with ElBox anyway.. :roll:
..A1200/ElBOX Tower/Blizz1240-40/64 MB/Mediator LT4/VooDoo3/4xEIDE/80GB HDD/Realtek 8xxx/Samsung 17\\" SM711MP LCD TV monitor with SCART-IN for 15kHz stuff.. OS 3.5 + A600 HD new!  
Old things can not get obsoleted.. ;-)
 

Offline alexh

  • Hero Member
  • *****
  • Join Date: Apr 2005
  • Posts: 3644
    • Show only replies by alexh
    • http://thalion.atari.org
Re: Coldfire - Binary Compatible
« Reply #25 on: January 30, 2008, 01:04:08 PM »
Quote

Protek wrote:
Could an FPGA be used as a "middleman" with coldfire to handle the compatibility issues? In other words the FPGA would hold the logic to make instructions compatible in both directions in case an instruction was incompatible.

Nope that is not possible, for the same reason already given as to why you cannot replace these instructions in the binary file.

You do not know what is data and what is instructions (made worse if anything is compressed).
 

Offline alexh

  • Hero Member
  • *****
  • Join Date: Apr 2005
  • Posts: 3644
    • Show only replies by alexh
    • http://thalion.atari.org
Re: Coldfire - Binary Compatible
« Reply #26 on: January 30, 2008, 01:08:39 PM »
Quote

MASACREWILL wrote:
I wonder why they are not offering  Dragon and what is with ElBox anyway.. :roll:

I *think* it was a series of things:

1) The performance was not very good
2) The compatibility was not very good
3) They stopped making the exact coldfire chip that was on the Dragon.
 

Offline arnljot

Re: Coldfire - Binary Compatible
« Reply #27 on: January 30, 2008, 01:13:27 PM »
Quote

alexh wrote:
I *think* it was a series of things:


Also, most importantly, I think time passed by and the economy went out of the project...
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline Louis Dias

Re: Coldfire - Binary Compatible
« Reply #28 on: January 30, 2008, 01:55:31 PM »
I'm pretty sure that when I looked up Coldfire tools that Freescale had a binary analyzer/converter that could take a 68K binary and make it CF-native.

Regardless, perhaps the first step should be recompiling 68k AROS to Coldfire.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Coldfire - Binary Compatible
« Reply #29 from previous page: January 30, 2008, 02:37:30 PM »
@lou_dias
Quote
I'm pretty sure that when I looked up Coldfire tools that Freescale had a binary analyzer/converter that could take a 68K binary and make it CF-native.

It doesn't work for amiga binaries, and it never can.

The problem is that in any given amiga executable it is impossible to automagically determine which part is code and which data. It just can't be done.