motorollin wrote:
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
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?
