Freescale Coldfire V4s

[matthey]

Joska mentions about 90% compatibility with the ColdFire on the Atari with it's patching and traps:

http://www.amiga.org/forums/showthread.php?t=60771&page=3

A 68k fpga processor can handle the self modifying code better than the 68040, 68060 or ColdFire. They should be more compatible also but we will have to see what the performance is like. I expect the Natami Apollo fpga CPU will be competitive with a fast 68060. A ColdFire V4 should be faster with ColdFire code. Maybe the ColdFire could be used for I/O and (DSP like) sound processing. The fpga could then run the Apollo core if your fpga is big enough or the fpgaArcade core otherwise.

[Iggy]

Joska mentions about 90% compatibility with the ColdFire on the Atari with it's patching and traps:

http://www.amiga.org/forums/showthread.php?t=60771&page=3

A 68k fpga processor can handle the self modifying code better than the 68040, 68060 or ColdFire. They should be more compatible also but we will have to see what the performance is like. I expect the Natami Apollo fpga CPU will be competitive with a fast 68060. A ColdFire V4 should be faster with ColdFire code. Maybe the ColdFire could be used for I/O and (DSP like) sound processing. The fpga could then run the Apollo core if your fpga is big enough or the fpgaArcade core otherwise.

Interesting idea.I wonder how well a 68K softcore and another processor could co-exist.

[matthey]

Interesting idea.I wonder how well a 68K softcore and another processor could co-exist.

That would be the tricky part. I expect you would run a kind of simple service and overseer OS on the CF. This isn't so much unlike the ARM CPU on the fpgaArcade. The Natami may be able to have the 68060 and fpga Apollo active at the same time. Synchronizing and sharing data is the difficult part. It's done with the Amiga CPU and custom chip's "processors" like copper and blitter.

[dreamcast270mhz]

@Iggy

You've piqued my interest. What company do you work for, some sort of embedded computer company?

On the side of this, I am very interrested in this.

If the Atari Coldfire system is pretty good with compatibility, wouldn't it be possible to use a sort of application layer that could modify instructions to Coldfire specific code.

If not, another model would be to recompile applications that we do have the source for, put the coldfire on a board with a 68k, and have a "wrapper" that is tested with applications before being released and from the results of its use come up with a way to send certain applications to the 68k and others to the Coldfire.

[Zac67]

Recompiling source code will be fine - you 'just' require the source. However, some instructions behave differently, so without code analysis you will never know if the code at hand works OK.

[matthey]

Recompiling source code will be fine - you 'just' require the source. However, some instructions behave differently, so without code analysis you will never know if the code at hand works OK.

If you recompile the code for ColdFire, you could put a ColdFire identifier for the code in the executable. This is how PPC code in an Amiga executable works. There is probably already a ColdFire ELF code identifier if using AROS. Vbbc/vasm may already be able to compile and assemble it. I have assembled ColdFire code on my Amiga into an executable with vasm. I disassembled which verified that it did use the ColdFire instructions.

[Piru]

If you recompile the code for ColdFire, you could put a ColdFire identifier for the code in the executable. This is how PPC code in an Amiga executable works. There is probably already a ColdFire ELF code identifier if using AROS. Vbbc/vasm may already be able to compile and assemble it. I have assembled ColdFire code on my Amiga into an executable with vasm. I disassembled which verified that it did use the ColdFire instructions.

He was clearly referring to the fact that you cannot execute 68k code in a transparent manner, even if using the compatibility library, not on how to detect CF binaries.

[Iggy]

He was clearly referring to the fact that you cannot execute 68k code in a transparent manner, even if using the compatibility library, not on how to detect CF binaries.

You guys should pay attention to Piru's comments and my own on compatibility issues.
The Firebee crew has recompiled there entire OS and uses three different methods/work arounds to address Coldfire incompatibility.
And still their system only runs about 50% of their software.
They're currently considering replacing the CF68KLib library with a more effective tool.

A Coldfire implementation is NOT going to have the compatibility of a 68K system, a FPGA based system, or emulation.
It will be significantly faster on software that can be recompiled, patched, or trapped with effective software.
But its still a Coldfire native system, not a 68K.

Oh, sorry, I forgot to mention. In from the mid '80s to early '90s I worked for Delmar Co in Middletown De where we developed and sold 68K based systems running Microware's OS9.
I developed a relationship with Motorola Semiconductor back then (obtaining early XC samples for all kinds of things like the 6829MMU for the 6809 processor).
Since then, I've maintained my Delaware business license and still do some consulting work (much less then in the past because it doesn't pay as well as it used to).
Freescale still offers me samples of specific items I want to work with. The last time I asked them for something was when I was investigating the MPC8640/8641.
Curiously enough, it was Paul Gentle (@ Varisys) that convinced me to look at Freescale's Qorlq line instead of focusing on the e600 core.
Currently, of all the PPCs in production, Freescale's products based on the new 64bit e5500 and e6500 cores look the most promising.

[dreamcast270mhz]

@Iggy.

I've been paying attention, and I now think your best bet would be to try and do this, if you are interested in pursuing it. Somehow set up this CF board as a Co-Processor, in Phase5 card fashion or similar, and from there get AROS recompiled for CF, and run it similarly to 3.9/WarpOS. But, I think it would be better to develop an Amiga PCI card for other systems and have it emulate say an ECS system. It woul pair well with MOS, and you could have slots for CPU and the chipsets from an Amiga, granting otherwise dead Amigas a new lease on life.

[Iggy]

@Iggy.

I've been paying attention, and I now think your best bet would be to try and do this, if you are interested in pursuing it. Somehow set up this CF board as a Co-Processor, in Phase5 card fashion or similar, and from there get AROS recompiled for CF, and run it similarly to 3.9/WarpOS. But, I think it would be better to develop an Amiga PCI card for other systems and have it emulate say an ECS system. It woul pair well with MOS, and you could have slots for CPU and the chipsets from an Amiga, granting otherwise dead Amigas a new lease on life.

I like all the positive idea, but right now I just need something I can develop with.
I'm currently looking at 68K compiler tools I can run on my X86 system and packages like PortAsm/68K for Coldfire which will allow me to move code to a Coldfire processor.

[yssing]

Wouldnt it be better to look at the V5?

[Iggy]

Wouldnt it be better to look at the V5?

It absolutely would, but Freescale won't sell you one.
The only place you find the V5 is in Laser printer engines.

I'm not into salvaging such a complex BGA.

[yssing]

Ohh, didnt know that, that sucks

[Louis Dias]

I still don't understand why someone can't simply create a compiler that treats a 68k executable and libraries as intermediate code and creates a compiled native CF version.

In this method, you could then just throw files at it and produce CF binaries, swap out binaries in your app folder and just launch the native CF version(s)...

[Piru]

I still don't understand why someone can't simply create a compiler that treats a 68k executable and libraries as intermediate code and creates a compiled native CF version.

There is no way to tell which part of the binary is code and which data. If you translate data in similar manner you'll just corrupt it.

It is also extremely difficult if not impossible to handle code that calculates checksum of the code itself or does dynamic relocation and/or modification to the code before execution (not all self modifying code is bad, patching the code before running it is quite common).

In short, it cannot be done.

[Fats]

There is no way to tell which part of the binary is code and which data. If you translate data in similar manner you'll just corrupt it.

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.). You could combine it with a cache that remembers translated code.
In a later stage you can make tools that makes binary patches from this cache so this information can be distributed or updated so that the loader doesn't need to find out each time it loads a program.
Non-trivial job, I agree, but what would we hobby programmers do otherwise ?

greets,
Staf.