Coldfire status

[jdiffend]

Ok, do a search and you'll find this discussed by several people in depth in several old threads.  The oldest ones probably aren't around anymore (1990ish?) but to summarize:

The Coldfire CPU is missing some 68K instructions, some are there but act differently than the 68K equivalent and the coldfires currently have some additional hardware built in that must be configured on startup so it doesn't conflict with existing Amiga hardware.  It also wasn't as feasible on older Coldfire cores due to a few missing instructions.

There are ways around all the software problems, but to do this would require a new Amiga exec.library since it executes illegal (on the coldfire) instructions early in the startup code.  It's so early that it crashes before it could even transfer to an expansion ROM (actually, it happens *while* it's checking for one).

FWIW, *IF* someone could get past the exec issue it would be the fastest 68K Amiga any of us are likely to see even with the illegal instruction traps.  Oh yeah, the latest Amiga ROMs are FULL and the instruction traps require some space.
I also think a couple other devices might need to be native Coldfire code due to the close tie in with the exec. (timer.device?)

I actually gave a commented disassembly of the latest exec to a guy (he gave me the raw disassembly and I commented it) with a V2 Coldfire dev board over a year ago and he was going to port it but I don't know how far he got.  Actually, I think it was 2 years ago that Freescale gave away the dev boards so it's been even longer than that.

If someone had access to the Amiga ROM sources this wouldn't be a bad project.  Without that you have to reverse engineer things, fix them, etc...

[Piru]

@boing

Also the speed of the ColdFire running 6K code is easily answered by looking that the instructions, addressing modes and registers offered by by both the 68000-68060 and and Specific ColdFire chip used by Elbox (or other company).

In fact I'm sure Moto/FreeScale has a comparison chart buried somewhere on their site.

Actually it's more complex than that. It depends on the frequence of the emulated instructions in the specific code being executed, and the method of emulation used. IMO to be usable the Dragon m68k emulation should be complete (and not fail with multiplication overflow and such stuff, and it should emulate supervisor mode). To get this you'd need full emulation of both user and supervisor mode. This is not fast on 266MHz chip.

jdiffend already covered some other stuff regarding this, but you can also visit the other threads (use the search function).

Anyway, I'd love to be wrong here, I'd love to see 266MHz m68k, but I believe I won't see that.

Still, Elbox can easily prove me wrong by releasing the thing and having it perform as promised.

[jdiffend]

motorollin wrote:
Well, I suppose a lot of stuff wouldn't need to be emulated (i.e. custom chips). But emulating a 68k processor on a 266MHz CPU probably wouldn't be much fun, and also may not work for non OS-friendly software.

--
moto

You aren't emulating the 68K in the same way as most people think of emulation.  Most 68K instructions would be executed natively.  

If Motorola's figures based on older Coldfire cores are correct (based on millions of lines of existing code) it would be 20% slower than native Coldfire code (that's about a 200MHz 68000 at least).  And those cores were missing more instructions and address modes than the 4e which would be even faster.  

Also remember that as shared libs and devices are updated to be coldfire native code, all apps that use them will be sped up.

Non OS friendly stuff that won't run on an 060 certainly wouldn't run on a Coldfire.
Also, some OS friendly stuff would need to be patched to run properly on the Coldfire.

[Doobrey]

jdiffend wrote:

There are ways around all the software problems, but to do this would require a new Amiga exec.library since it executes illegal (on the coldfire) instructions early in the startup code.  It's so early that it crashes before it could even transfer to an expansion ROM (actually, it happens *while* it's checking for one).

I was gonna jump in and say something like ' Easy, override the ROM on a reset with one that inits the coldfire and then go back to the standard kickstart once the traps are setup'

But then the coldstart in exec resets all traps/exceptions to the ones in ROM. So that's the simple trap method up the creek  :-x

I thought Piru was mad for suggesting a full 68k emulation, but now I see the light.

If someone had access to the Amiga ROM sources this wouldn't be a bad project.  Without that you have to reverse engineer things, fix them, etc...

Pffff.. having the sources takes all the fun out of it :crazy:

[jdiffend]

Actually it's more complex than that. It depends on the frequence of the emulated instructions in the specific code being executed, and the method of emulation used.

Motorola analyzed millions of lines of code and a 20% speed reduction was the final number they figured on but some code may be slower or faster.  But since most code is generated by a compiler it's unlikely the number will go higher than that.

IMO to be usable the Dragon m68k emulation should be complete (and not fail with multiplication overflow and such stuff, and it should emulate supervisor mode). To get this you'd need full emulation of both user and supervisor mode. This is not fast on 266MHz chip.

Software could be written to scan through a program looking for the mul/div instructions where they wouldn't function the same.  They could be replaced with an illegal instruction that could be trapped just like the others.  

Most software doesn't use supervisor mode so the changes to the interrupt handling wouldn't be a problem.  Games had a habit of breaking on some Amigas back in the day so I wouldn't expect to run them on the Coldfire as is.

jdiffend already covered some other stuff regarding this, but you can also visit the other threads (use the search function).

I think I end up discussing this about once a year.
Nobody ever seems to use the search.

Anyway, I'd love to be wrong here, I'd love to see 266MHz m68k, but I believe I won't see that.

Still, Elbox can easily prove me wrong by releasing the thing and having it perform as promised.

Well, I have no doubts they can do the hardware... it's the software that is a PITA.  Since the Minimig can load the OS from a device I have no doubts someone could load the Kickstart and patch it.

[jdiffend]

BTW, wheter or not the mul/div is a problem depends on how the compilers generated code.  If it wasn't optimal to do the mul/div and then test-branch it should rarely appear.  If it was optimal it will be all over the place and the code pattern from the compiler should be easy for a program to identify and patch as I suggested.

The full emulation would only be needed if someone couldn't figure out another way or for problem software.  If you did do full emulation it would be pretty easy to use just in time compilation and write out the alternate code to execute natively.  It wouldn't be like going from 68K to X86.  Your registers are the same (on the 4e anyway... stupid supervisor mode on 2-3 cores sucks) and most instrucitons are the same.

[jdiffend]

Doobrey wrote:
I was gonna jump in and say something like ' Easy, override the ROM on a reset with one that inits the coldfire and then go back to the standard kickstart once the traps are setup'

But then the coldstart in exec resets all traps/exceptions to the ones in ROM. So that's the simple trap method up the creek  :-x

Actually... that's not far from what I was thinking.  Start with an alternate ROM, copy the existing kickstart to RAM, patch it, jump to the kickstart in RAM and turn off the boot ROM.  Sorta like a 1000 that patches the ROM after loading it.

[Piru]

Software could be written to scan through a program looking for the mul/div instructions where they wouldn't function the same. They could be replaced with an illegal instruction that could be trapped just like the others.

That doesn't work well. The problem is that there is no way to determine if some value is code or data. Checksums would also be a problem (just try running xvs.library or elbox drivers when the code has been modified, for example).

[Doobrey]

Piru wrote:
Checksums would also be a problem (just try running xvs.library or elbox drivers when the code has been modified, for example).

 :lol:

[jdiffend]

Piru wrote:
That doesn't work well. The problem is that there is no way to determine if some value is code or data. Checksums would also be a problem (just try running xvs.library or elbox drivers when the code has been modified, for example).

The checksums are copy protection and there isn't much you can do about it unless you want to crack the software completely.

BTW, I've seen it done in the past.  

[Piru]

It depends on if you want to fail randomly or not. Personally I wouldn't want to have such code in my system, but that's just me.

[utri007]

Piru is moust likely one of the world, he knows much amiga hardware.

So would you like to wrote new amiga exec for coldfire ?

We need positive additude in this dark time.

[Piru]

So would you like to wrote new amiga exec for coldfire ?

Seriously? No.

I've brought up my reasons often enough. I think using coldfire isn't that good idea.

Anyway, maybe I'm wrong and it'll work out. We'll see.

[alexh]

One thing you could do, if this is an A1200 only upgrade, is use a technique similar to the one used in the Blizzard PPC.

Use the onboard EC020 to boot make the patches, load the libraries and then pass over to the Coldfire.

Dunno if you can do that with the TrapDoor interface, I think it's either the CPU on the motherboard, or ones on the card. (I suppose they could slap down an uber cheap EC020 on the Dragonboard?)

[motorollin]

Why not just physically replace the Kickstart ROM with one which is compatible with Coldfire?

--
moto

[Doobrey]

@motorollin,
 'Cos it'd mean trying to make a deal with Amiga Inc to get a license and the sources?(IIRC, they don't have the sources to 3.5+3.9 so patching that could be another problem)