»

[alexh]

You'd still need the physical connection between the x86 chip and the classic Amiga chipset. Without some form of Bridge chip it wouldnt be possible. Personally I dont think it would be feasible at all.

[DamageX]

Why do you say that? All you're talking about is glue logic. It'll be more complicated than connecting an old 5V tolerant CPU but still a relatively minor obstacle.

[jdiffend]

Oliver wrote:
I spoke with a couple of engineers from Freescale at my uni last year, and they told me there had been great difficulty creating 68k compatibility in a modern chip. The documentation was poor or lost, and none of the original engineers were available.

Huh????

Ok look, the original 68K probably wasn't designed in VHDL or Verilog and it uses micro-code. The new CPU's are probably designed in one of those languages or something similar and I'm sure they don't use the original micro-code if they use it at all.

That being the case, they would have to rebuild the chip from scratch based on the specs rather than any original die info the old group had. The cpu instructions, timings, etc are well documented in the publications they provide for developers. I don't see any issue here. If someone can build an Amiga in a chip from the specs why couldn't freescale redo a CPU?

The reason the coldfire chips aren't compatible is because they were designed from the ground up to run 68K instructions in a RISC like manner, at higher speeds and from a smaller die. It was never intended to be a desktop CPU! After analyzing millons of lines of code they CHOSE to drop things that weren't used much for the sake for speed. Things like complex address modes, a register in supervisor mode and an optimized interrupt stack to name a few.

I'm sure it would be difficult to convert the existing coldfire design to be more compatible without sacrificing speed but I see no reason why they would need the original engineers to add compatability.

You sure they weren't just some lackies trying to sound important?

[jdiffend]

I've heard of the the harvard architecture

A true harvard machine IMHO would have completly seperate data and address busses for instructions and data. For example the PIC and AVR microcontrollers. This just seems to me a waste of transistors

Separate data and address busses for instructions and data???
That might work nice if all your code is in ROM like a small microcontroller but it's pretty much unworkable otherwise.

[jdiffend]

DamageX wrote:
Why do you say that? All you're talking about is glue logic. It'll be more complicated than connecting an old 5V tolerant CPU but still a relatively minor obstacle.

There's that... and converting between two totally different buss handshaking protocols withing close timing limits.

[jdiffend]

alexh wrote:
You'd still need the physical connection between the x86 chip and the classic Amiga chipset. Without some form of Bridge chip it wouldnt be possible. Personally I dont think it would be feasible at all.

It's feasible but since it's totally incompatible software wise and PC hardware is faster anyway... why bother with the miggy chipset at all???

[Zac67]

@DamageX: Unlike the Pentium Classic/MMX, the Cyrix 6x86 was already RISC.

Many years ago I hoped the Transmeta code morphing architecture could be used to emulate a 68k, but unfortunately that didn't happen.

[Comi]

So it is second half of May and no news from Elbox yet? :-?

[Tomas]

If you only use 68k, better use WinUAE. On any decent x86 system it runs circles around this ColdFire accelerator anyway.

Might run faster under emulation, but it still does not emulate the custom chipset perfectly. And what is the point in running AOS hosted ontop of another sloppy OS? Is just not the same as using the real thing...

[Piru]

@Tomas

Similarily there are no guarantees what delays or misbehaviour the coldfire m68k instruction emulation might cause. Suddenly certain instructions are massively slower than others. Also, the emulation accessing custom registeres can cause side-effects (doing more than one read or write can be fatal).

Also, it's quite unlikely the Dragon would implement full supervisor emulation, and thus you will be unable to run all the games. Thus you might end up needing to use UAE anyway.

[jdiffend]

Piru wrote:
@Tomas

Similarily there are no guarantees what delays or misbehaviour the coldfire m68k instruction emulation might cause. Suddenly certain instructions are massively slower than others. Also, the emulation accessing custom registeres can cause side-effects (doing more than one read or write can be fatal).

Illegal instruction traps would take place in the Coldfire pipeline before a read or write.

The instruction, addressing mode and address must be decoded *before* the cpu knows what to do or where to read or write. As a result the illegal instruction interrupt would be triggered before a read or write takes place.

Motorola has published a LOT of information on performance of running 68K code with the aid of traps and I'm sure it's somewhere on the Freescale site now. I *think* the performance was 10%-20% below native Coldfire code on older cores but the 4e supports more 68K modes so it shouldn't have to emulate as many instructions through traps.

Also, it's quite unlikely the Dragon would implement full supervisor emulation, and thus you will be unable to run all the games. Thus you might end up needing to use UAE anyway.

As long as a program, game or otherwise, doesn't interfere with the standard interrupt processing it has a chance of running. If it takes over and handles the traps itself a crash is guaranteed since the traps will be disabled and the interrupt stack frame is different than the 68K.

[motorollin]

jdiffend wrote:
As long as a program, game or otherwise, doesn't interfere with the standard interrupt processing it has a chance of running. If it takes over and handles the traps itself a crash is guaranteed since the traps will be disabled and the interrupt stack frame is different than the 68K.

What does this mean for software like WHDLoad?

--
moto

[jdiffend]

motorollin wrote:

What does this mean for software like WHDLoad?

--
moto

As far as with a Coldfire goes...
WHDLoad will probably run fine but the games it loads onto your machine will have a high failure rate. If someone is crazy enough to patch the games so they work on the Coldfire then they will work just fine. But that amount of patching would be much more difficult than what they are doing now. It really just depends on the game.

Are there any games that will run? Yes, games that use the external math libs, support RTG and are multi-tasking friendly have a good chance of running. Games like that tend to be written to follow the rules. Some patches may be required but the amount of work doing that is reasonable.

The system hogging super scrolling massive sprite reusing super games that tried to squeeze every last ounce out of an Amiga 500 could present serious issues unless you run them in an emulator with UAE or something like it.
Since the Architecture of the 68K and Coldfire are so close and some OS calls or hardware accesses can be handled natively it *could* be fast enought to run the games just fine with UAE and patching wouldn't be needed.

Anything that can be recompiled to Coldfire code would be very fast and unless it messed with interrupt handlers should be ok.

Anything that was compiled to run on the 060 would also be pretty fast since many of the unsupported instructions won't be used. Some of the people claiming the instruction traps would be too slow don't realize that some of the unsupported instructions/modes weren't supported by the 060 either and we've been running software without them for years.

Motorola's performance estimates were made with 68000 code, not 68060 code. Add to that the additional compatibility the 4e has over the initial core the estimates were made with and it has the *potential* to be pretty fast. I'm guessing software will average within 15% of native Coldfire code and will be much faster than an 060. Even at 20% that's still like running at 200MHz or faster.

The biggest issue for most non-game software would be the instructions that have different behavior but aren't trapable. In many situations it's unlikely to be a problem but it can be. The software won't crash but it will have unpredictable behavior since it won't branch when it should. A patcher could be written to deal with this but it requires a lot of know how and quite a bit of code to decode and test instructions to keep it from accidentally patching something it shouldn't. Even with such precautions there are bound to be some programs that can't be patched without someone looking at it by hand and others where it's impossible.

As far as Elbox goes... I don't have enough info to go beyond what Freescale has published about the chip. They offer no hints as to how they are dealing with anything.
Without knowing what they have done to insure compatibility we have no way of knowing what if anything will run.

Now for a reality check. Welcome to the late 90s. We are talking about 266MHz. It's still going to be VERY SLOW by today's standards and the Amiga chipset hasn't been sped up at all. Freescale WAS talking about 500MHz and superscaler in the next couple years but I won't hold my breath. I wouldn't expect 1GHz for 5 years at this rate and multi-core? What's that?

[Piru]

the instruction traps would be too slow don't realize that some of the unsupported instructions/modes weren't supported by the 060 either and we've been running software without them for years.

The traps are very very slow. They're so slow that software doing realtime patching (trapped instruction is replaced with direct jsr to emulation code) was developed: CyberPatcher / OxyPatcher.

But I've mentioned all this 3 years ago already, lets just wait if anything shows up. If something does show up, then we will see what the real world performance is.

[jdiffend]

Piru wrote:
The traps are very very slow. They're so slow that software doing realtime patching (trapped instruction is replaced with direct jsr to emulation code) was developed: CyberPatcher / OxyPatcher.

What exactly is very very slow? 10%? 20%? 50%?

The 060 suffered over a 20% hit in performance from traps since it depended on it's superscaler architecture for it's speed. A trap was like killing the execution of 2 instructions instead of 1. And the difference in speed between the faster 040's and the 060 was only about 10MHz when it first came out. That made it no faster or even slower than an 040 when running some software.


You keep talking about the 060... this isn't an 060. The 060 came out over ten years ago. The 060 has dual 8K caches... the Coldfire... dual 32K and the Coldfire is running at over 3x the clock speed. Even an 060 running at 266MHz using traps would be faster than an 060 at 75MHz without them.

As far as CyberPatcher or Oxypather go the same thing can also be done for the coldfire.

But I've mentioned all this 3 years ago already

And that makes you right how? If you were wrong then you won't be any more correct now.

You were totally off base on the post about unexpected behavior caused by multiple reads or writes to hardware that would be caused by the instruction traps.

lets just wait if anything shows up. If something does show up, then we will see what the real world performance is.

I agree on this part. The hardware may be great but it's the software that will decide what if anything will work.
It could be a case of here's the hardware and we'll get around to the software someday.

Look, there are pleanty of reasons for this not to work without making up additional ones.