Coldfire - Binary Compatible

[Donar]

It is possible to configure the CF68klib so that it sets up a Virtual 68k on the Coldfire (with e.g. 68060 as target), but then FPU and MMU will not work and it can not execute Coldfire Code anymore. Would it be possible to place the MMU and FPU in an FPGA'ed ChipSet?

[Donar]

I don't understand the question. The coldfire is not suitable to the amiga...

The Coldfire can behave like an 680x0 without MMU and FPU, if you build the right CF68klib from MicroAPL which then sets up a Virtual Machine on the CF. At least that is what the CF68klib manual says.

Problem would be:
Getting the CF on the Amiga Bus.
I think you need an MMU for setting this kind of extension up.
No FPU support.

I would hate the think how complex an FPU in an FPGA would be!

Ok thanks, it was just an idea for a work around for some problems.

[Donar]

Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.

If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P

You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.

I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.

[Donar]

As i do not know how to explain it properly i take this rather lenghty cut&paste. Sorry for the inconvenience...

User Mode Library
In this form CF68KLib will install its own handlers for the 'Illegal Instruction' and 'Address Error' exceptions which can occur when unimplemented 680x0 instructions are executed on ColdFire. These handlers will perform the same
function as the missing instruction and then return execution to the instruction which follows. The existence of CF68KLib is thus transparent to your application code except that it can incur a substantial performance penalty.

It is occasionally necessary to make minor modifications to your 680x0 program before it can be run under CF68KLib. This is because there are a very small number of 680x0 instructions which are also legal in ColdFire (and hence do not cause an exception) but which do not behave identically. As an example, the MULS instruction executes identically under ColdFire except that it does not set the Overflow flag in the condition codes register.

Ok this is what everybody is always talking about.

Supervisor Mode Library
The ColdFire supervisor model is very different to the 680x0. For example there is only one stack pointer instead of separate User and Supervisor stacks, and the format of an exception stack frame is different. This means that although instructions such as TRAP and RTE are implemented in the ColdFire architecture, a 680x0 binary such as an operating system would be unlikely to work correctly. For this type of problem you can use the Supervisor Mode form
of CF68KLib. In the Supervisor Mode form, the CF68KLib library takes over the handling of all ColdFire exceptions in order to implement a complete 680x0 virtual machine.
The presence of CF68KLib is transparent to your 680x0 code, which 'thinks' it is running on a real 680x0 processor, and you can run an entire 680x0 operating
system including interrupt-driven hardware inside the virtual machine. Because the Supervisor Mode form of CF68KLib has to take over the handling of all ColdFire exceptions it is generally not possible to use this form of the library alongside a native ColdFire operating system, although you can still execute application-level ColdFire code.

No problems with the different supervisor mode model, as the 68k one is emulated. And as it is not mentioned otherwise (as it is on the paragraph about user mode) it seems that also the differently implemented CF/68k instructions return the proper result!?

If you wonder where i pulled that from:
Click

[Donar]

User Mode or Supervisor Mode library doesn't matter.

I only find it strange that in the user mode paragraph it is mentioned explicitly that the differently implemented instructions will not work, and in the supervisor mode paragraph there is no word about it. It sounds like the library will set up an full 680x0 Emulator (without MMU/FPU) on the Coldfire but maybe i interprete in the text what i want to be true :lol:  

Are you a coder, Donar?

No, but i think i can read...  :-)

[Donar]

Well, no offence intended, but read the remainder of the document.

I have read the whole document months ago.... Maybe we can make a deal? I'll shut my mouth now, and you try out how Coldfire behaves when you get your Coldfire EVB and tell us your findings in the next thread (that surely will appear). ;-)

It all depends on what you really want to achieve:

-Having new hardware that follows in the footsteps of the AMIGA architecture (see Natami project) but is fast enough to not bore the user to death, while waiting for a window to open (as AGA will do, when you use HighRes in 256 colours).

And no i do not want to play Crysis in 1680x1050 on it nor do i want to compress all my DVD's to MPEG 4 or watch BluRay on it. I have a fast PC and PS3 for such things.

[Donar]

...footsteps of the AMIGA architecture...

Hacking together out of date technologies into something that is a little bit compatible to the old Amiga line of computers is not following in the footsteps of  AMiGA...

Maybe it's not in the footsteps of the AMIGA if you think of the most advanced computer that is available on earth. But it would be in the footsteps of how things were done "differently" in the AMIGA.

Taking the most advanced technology available to the consumer, putting it together in a new and innovative way and packaging it in a user-friendly way is following in the footsteps...

I like the idea but as i do not think that somebody who shares your vision of a new AMIGA has the funds to realize it, its just not going to happen. Somebody could cludge together an FPGA'ed Chip set and some processor in his cellar. But there is no way anybody beats Intel, AMD and NVidia with his cellar invention. :-(

Unfortunately only Apple come close to that...

Why do you think so? Because Apple sells dual processor workstations with four cores to everyone who want's to have more than one hard disk in his computer? Ok i admit: OSX just works out of the box.

[Donar]

bloodline wrote:

Apple now take the best technologies available, and package it in pretty user friendly boxes. That is what the Amiga was all about..

But in the end a MacPro is just a dual processor Workstation with EFI instead of a BIOS, which you could also get from Boxxtech. I would have found it interesting if they had (for example) included a Cell or DSP that could assist the XEON's for special purposes.

[Donar]

bloodline wrote:

For what purpose...?

Videoencoding, Raytracing booster.

A Cell or a DSP isn't going to offer anything over over a regular GPU

I do not know how good it works on an Apple computer. But if you try to do computational work on the GPU under Win XP (e.g. Folding @ Home) your GUI will slow down, and you have to dedicate one CPU core for "feeding/checking" the GPU client which runs on the GFX card, or it will be real slow, additionally you can only use ATI/AMD cards as NVidia cards are (according to the development team at Stanford university) not able to do this kind of work. You also have to stay on certain catalyst versions - and even then most people have severe issues with it.

I really do not care if you take Cell or a Radeon as super fast subsystem (take something with a good GFlop/Watt/Price ratio), but please integrate it properly into the whole System and OS, so that it is usable without any issues.
 

...and certainly nothing for the consumer price bracket...

I do not want Apple to integrate the Cell into a MacMini besides the Core 2Duo, but maybe into the MacPro. A MacPro is not what i think about for the consumer price bracket also.

Edit: If any body want's to talk about Coldfire, just do it i did not mean to hijack the thread.