Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: WolfToTheMoon on January 16, 2011, 11:12:16 AM
-
I've been following the Atari Firebee(Coldfire) project with great interest.
They seem to be close to delivering their promised product(for 599 euros which includes the 120 euros for the FPGA onboard which we would not need if the AGA would be used for legacy apps). The hardware phase is mostly over and now they're primarily busy with porting software.
As far as I can see, they have successfully managed to overcome the Coldfire 68K incompatibility with something they claim to be a "light compatibility layer".
Since AROS68K is open source(the Atari team has done some patching of the TOS source code). I'm no expert here and I'd be interested in some of the more knowledgeable members opinion, but I believe a similar process could be possible to enable full Coldfire compatibility for the AROS68K.
Why am I bringing this up? Well, the Coldfire v4 offers DDR RAM, has MMU, FPU and clocks at 266 MHZ(400 MIPS). It is also cheaper then 68060 and runs with very little power(3-5 W). For those not being able to buy what is probably going to be a very expensive NATAMI board, it might be a viable alternative to get significantly more performance out of AROS68K and their 68K systems. The Firebee can now run FireTOS at 1920x1080 resolution!!! :)
http://acp.atari.org/
-
It still won't run amiga 68k software so I don't see the point. Why not just use x86?
-
Since AROS68K is open source(the Atari team has done some patching of the TOS source code). I'm no expert here and I'd be interested in some of the more knowledgeable members opinion, but I believe a similar process could be possible to enable full Coldfire compatibility for the AROS68K.
It's perfectly possible to run aros on coldfire. The question is whether it's actually worth it.
Compatibility for old applications is a problem. You'd need to either to create patches or come up with a dynamic recompiler that converts 68k to coldfire at run time.
For the price there are more powerful solutions.
-
It still won't run amiga 68k software so I don't see the point. Why not just use x86?
I agree, use x86. I'm simply asking whether it'd be possible to do a Amiga "FireBee" edition for the 68K guys. The Atari crew seem to be able to work with it just fine. Sure, you'd need to recompile apps to run on AROS68K coldfire, but at least it offers a significant performance upgrade for a decent amount of money.
One solution might be maybe to use the onboard 68K for legacy software and Coldfire board for AROS68K.
-
There are plenty of threads on this forum as well as the Natami forum about why ColdFire is less than optimum for the Amiga. AROS 68k probably will be part of the future for some fpga based 68k Amiga though. That is what the Natami is planning...
http://www.natami.net/
-
There are plenty of threads on this forum as well as the Natami forum about why ColdFire is less than optimum for the Amiga. AROS 68k probably will be part of the future for some fpga based 68k Amiga though. That is what the Natami is planning...
http://www.natami.net/
Yes, I'm well aware of the Natami and their plans. The problem with Natami is price. It will probably be expensive.
Coldfire less then optimum for the Amiga? I agree it's less then optimum for the KS/WB 3.1 combo for known issues. However, not for AROS68K, since it could be patched to remedy any issues with compatibility. The issue remains for the legacy 68K software, but that could be handled by the 68K/AGA on board A1200/A4000.
Looking at the Atari Firebee project, I think one could get a expansion board with the Coldfire CPU with similar power for lower price then Natami. It would lack Natami-specific features like Super-AGA, but it could also pack it's own graphics system that could be more powerful then Natami's if not AGA related.
-
The issue remains for the legacy 68K software, but that could be handled by the 68K/AGA on board A1200/A4000.
No I couldn't. There's no way the coldfire board and the on board 68k could do proper cache snooping, leading to the same issues that existed with the powerup boards: Cacheflushes on context switches.
Unless of course you mean rebooting to 68k AmigaOS to run amiga apps of course...
-
Bus snooping was supposed to be a feature of the 68040 and above when working in environments with DMA controllers and such, but did it ever actually work?
-
Looking at the Atari Firebee project, I think one could get a expansion board with the Coldfire CPU with similar power for lower price then Natami. It would lack Natami-specific features like Super-AGA, but it could also pack it's own graphics system that could be more powerful then Natami's if not AGA related.
Don't just look at clock speed of the ColdFire vs N68k vs 68060. The ColdFire is a cut down "cheapened" 68k CPU for embedded systems. It's not as powerful as the 68060. Sure, it has larger caches and some modern features that the 68060 didn't get way back then but adding those would have been easy had the 68060 been continued. Motorola/FreeScale didn't want the 68k/ColdFire competing with PowerPC. There is no future for ColdFire except as a little brother "embedded" CPU. The N68k project is an attempt to continue the 68k line as a powerful processor. The 68k was abandoned because of marketing reasons before it's power was explored. The N68050 should already be on par with the V4 ColdFire at a lower clock speed while the N68070 should easily outperform it. Parallel processing is a big part of the reason why. The N68k should be much easier to program and much more Amiga compatible than the ColdFire too. If you want a cheaper Amiga than the Natami, then there is the MiniMig 68020+AGA. I'd rather go that route than try and make a cheap ColdFire based Amiga.
-
Don't just look at clock speed of the ColdFire vs N68k vs 68060. The ColdFire is a cut down "cheapened" 68k CPU for embedded systems. It's not as powerful as the 68060. Sure, it has larger caches and some modern features that the 68060 didn't get way back then but adding those would have been easy had the 68060 been continued. Motorola/FreeScale didn't want the 68k/ColdFire competing with PowerPC. There is no future for ColdFire except as a little brother "embedded" CPU. The N68k project is an attempt to continue the 68k line as a powerful processor. The 68k was abandoned because of marketing reasons before it's power was explored. The N68050 should already be on par with the V4 ColdFire at a lower clock speed while the N68070 should easily outperform it. Parallel processing is a big part of the reason why. The N68k should be much easier to program and much more Amiga compatible than the ColdFire too. If you want a cheaper Amiga than the Natami, then there is the MiniMig 68020+AGA. I'd rather go that route than try and make a cheap ColdFire based Amiga.
The 68060 does 110 MIPS @ 75 MHz
The Coldfire V4(e) does 400 MIPS @ 266 MHz
The advantages of the 68060 is that it is a fully superscalar design, while the CF V4 is only partially so. Still, your reasoning may apply to lower end V1, V2 and V3 Coldfires. I believe a CF V4(e) @ 266 MHz is handily faster then any 68K silicon. The V5 Coldfire is fully superscalar(and 300 MHz) but Freescale will only make it for you if you order a (pretty) large number of them.
The N68050 should already be on par with the V4 ColdFire at a lower clock speed while the N68070 should easily outperform it
the key word being "should" :)
-
I recall reports of Elbox's "Dragon" which ran @266mhz effectively being about the speed of a 40mhz 68040 in real-world tests due to compatibility trapping, etc.
IOW, coldfire ain't gonna happen for the Amiga.
Not at a speed that makes any sense.
Frankly what I'd like to see is something like taking a single-core Atom or Geode and running a virtualized 68k CPU with JIT on it on an Amiga accelerator card. Although I'd wager interfacing a virtual CPU to real hardware in that circumstance would be a nightmare to attempt.
-
I recall reports of Elbox's "Dragon" which ran @266mhz effectively being about the speed of a 40mhz 68040 in real-world tests due to compatibility trapping, etc.
That's known for the AmigaOS and I'm not suggesting that.
But here we're talking about AROS68K. Which could be patched to avoid compatibility trapping on ColdFire. The only thing in question is how to provide full backwards compatibility with 68K... software or hardware emulation?
P.S. The V5 Coldfire @ 333 MHZ does 610 MIPS.
P.P.S. If what you say is true that it would be about 40 MHz 68040 in "emulated" mode, than maybe that's not that bad after all. Which memory and bus speed did Elbox's Dragon run? I'm thinking DDR2 RAM should speed up things. ATA controller is also built in V4e core.
-
The 68060 does 110 MIPS @ 75 MHz
The Coldfire V4(e) does 400 MIPS @ 266 MHz
The advantages of the 68060 is that it is a fully superscalar design, while the CF V4 is only partially so. Still, your reasoning may apply to lower end V1, V2 and V3 Coldfires. I believe a CF V4(e) @ 266 MHz is handily faster then any 68K silicon. The V5 Coldfire is fully superscalar(and 300 MHz) but Freescale will only make it for you if you order a (pretty) large number of them.
The 68060 is already about the same MIPS/MHz as the V4 ColdFire with smaller caches, no link stack, etc. The 68060 can do more per cycle than the V4 ColdFire. Multilplication, division, shifting is all faster on the 68060. The 68060 has useful instructions that are missing on the ColdFire. Granted, the ColdFire has some useful instruction additions also. The N68k has everything except clock speed. None of the instructions are missing, ColdFire additions are included, other instruction additions are useful, multiple instructions per clock are possible, large caches, link stack, predicated branches, byte and word instructions are as fast as long, bitfield instructions are fast, large instruction prefetch, etc. The V4 ColdFire is nothing special. It's on par with a very fast 68040 with larger caches and a few other enhancements. The V5 ColdFire is a different story. It's more like a 68060 from what little information I could find on it. It would very likely be faster than the N68070 will be in fpga. The ColdFire does need optimized code and would be harder to get max performance from than the N68070 as currently planned. It's easy enough to say, just compile new code for it, but that's where a lot of the problem is. Compilers generate poor code especially on the 68k. I have a library that started out at 67648 bytes and I have optimized down to 39824 bytes so far. I think 1/2 the original size is possible although I'm optimizing for speed and not size. Before you say that this must have been some poor C coders, I'll tell you that this piece of work was done by a fairly famous pair of brothers (in Amiga land) who now work for Hyperion. I hope there PPC optimizing is better because the PPC is not nearly as forgiving of crap code.
-
That's known for the AmigaOS and I'm not suggesting that.
But here we're talking about AROS68K. Which could be patched to avoid compatibility trapping on ColdFire. The only thing in question is how to provide full backwards compatibility with 68K... software or hardware emulation?
P.S. The V5 Coldfire @ 333 MHZ does 610 MIPS.
P.P.S. If what you say is true that it would be about 40 MHz 68040 in "emulated" mode, than maybe that's not that bad after all. Which memory and bus speed did Elbox's Dragon run? I'm thinking DDR2 RAM should speed up things. ATA controller is also built in V4e core.
Re-werite an OS that hasn't been finished yet to run on a CPU thats only partially compatible. Then require that apps be re-compiled for the new CPU or run in an emulation mode that provides much lower performance. The entire idea sounds kind of painful.
And how are you going to implement the rest of the chipset? Is this going to be an accelerator card or a complete new computer?
Yes the Natami will be fairly expensive, but hopfully it will offer a good level of compatibility. Your idea doesn't offer much compatibility at all.
Personally, I'll stick with NG OS' and hope for better emulation as they progress.
-
Re-werite an OS that hasn't been finished yet to run on a CPU thats only partially compatible.
I think "re-write" might be just a tad bit too extreme. Sure, some patching would be required. I plan to maybe get an ColdFire evaluation board once AROS68K progresses enough and test it.
Then require that apps be re-compiled for the new CPU or run in an emulation mode that provides much lower performance. The entire idea sounds kind of painful.
The way you say it it does sound painful. :)
But I'd like to investigate further just how much is the performance drop of using Coldfire with AROS68K and then see whether it is painful or not.
And how are you going to implement the rest of the chipset? Is this going to be an accelerator card or a complete new computer?
It makes sense to be an accelerator card since it would be much cheaper to the end user and I would consider this to be a hobby and the lower the price the better(Also, then I'd avoid having a FPGA aboard which is expensive).
Yes the Natami will be fairly expensive, but hopefully it will offer a good level of compatibility. Your idea doesn't offer much compatibility at all.
Too early to say about compatibility. But if I can get 68040 performance of the CPU in the emulation mode, I'd be more then happy. The rest of the board should be pretty powerful(compared to classic 68K systems).
Personally, I'll stick with NG OS' and hope for better emulation as they progress.
I agree to that. I hope to develop for the future WB X(which will have emulation). This would be a fun side hobby project and it might benefit those people who'd like to keep their 68K hardware(and benefit me to gain more knowledge on the matter). I'm still undecided whether to go with something 6502-based or 68k based. Might end-up doing an 16-bit C64 clone afterall :). It would be cheaper and simpler. But if I can get people interested in this, then maybe a joint effort could be made. I'll talk with some of the local Amiga users and see if anyone is interested.
It would not be a commercial project since I cannot guarantee to be able to finish it, whatever the reason. :roflmao:
-
As you've pointed out, it is a hobby so I'm not going to discourage you.
If you do explore using a Coldfire CPU, hopefully you can keep us informed as to your progress.
-
@WolfToTheMoon
I don't mean to discourage you either but I see the hurdles and they are tough. The Natami team, Elbox and probably others have evaluated the ColdFire a lot. I think it would be neat to look at the FIDO instead. It's a CPU32 compatible 68k processor that's pretty neat. It's not as fast as the CF but it's cheap cheap and has some pretty nifty features. Exec would probably have to be modified for this too. I really like this 68k CPU in the bargain basement price range...
http://www.innovasic.com/products/ic/67-fido1100-32bit-comm-controller/
-
@WolfToTheMoon
I don't mean to discourage you either but I see the hurdles and they are tough. The Natami team, Elbox and probably others have evaluated the ColdFire a lot. I think it would be neat to look at the FIDO instead. It's a CPU32 compatible 68k processor that's pretty neat. It's not as fast as the CF but it's cheap cheap and has some pretty nifty features. Exec would probably have to be modified for this too. I really like this 68k CPU in the bargain basement price range...
http://www.innovasic.com/products/ic/67-fido1100-32bit-comm-controller/
I've noticed FIDO but I haven't considered it. Do you think one could use a dual CPU configuration and possibly use FIDO to execute legacy 68K apps and CF to run patched AROS68K? I'd like to keep CF on board so to be able to use faster DDR memory and it would offer greater speed in native CF applications(and those that would be cross-compatible between 68K and CF).
also, feel free to name any other 68K and 6502 compatible CPUs as I'm still evaluating all options :)
-
I've noticed FIDO but I haven't considered it. Do you think one could use a dual CPU configuration and possibly use FIDO to execute legacy 68K apps and CF to run patched AROS68K? I'd like to keep CF on board so to be able to use faster DDR memory and it would offer greater speed in native CF applications(and those that would be cross-compatible between 68K and CF).
also, feel free to name any other 68K and 6502 compatible CPUs as I'm still evaluating all options :)
That might make more sense. FIDO has an operating speed of 66Mhz. Considering that it is a 68000 and that a 50Mhz 68060 would probably outperform it, adding a Coldfire processor to either makes some sense.
The real trick would be getting AROS to use both processors. AmigaOS and its derivitives have never sucessfully used more than one processor.
-
I've noticed FIDO but I haven't considered it. Do you think one could use a dual CPU configuration and possibly use FIDO to execute legacy 68K apps and CF to run patched AROS68K? I'd like to keep CF on board so to be able to use faster DDR memory and it would offer greater speed in native CF applications(and those that would be cross-compatible between 68K and CF).
The 68k CPU instructions of FIDO are more compatible with 68k but the interrupt system is totally different (although superior). Some 68000 programs would not run on it because of interrupt usage. It's also not fully 68020 compatible as it's missing bit field instructions. GCC loves to use the bitfield instructions too. You might notice that the MiniMig is getting bit field instructions and the N68k will have 1 cycle bit field instructions where the 68060 is 6+ cycles pOEP only. An fpga is really hard to beat as far as flexibility which equates to compatibility. It's the best way to go for emulating the Amiga chip set and then adding a processor isn't much more. The prices are dropping faster on the fpga's than the real CPUs. I do see some sense in using the CF as an I/O chip but I don't see any 68k processors besides the real 68k that will give the compatibility. The best solution would be to have enough demand to burn a real cpu from the N68070. The N68k will be using DDR2 memory by the way.
-
That might make more sense. FIDO has an operating speed of 66Mhz. Considering that it is a 68000 and that a 50Mhz 68060 would probably outperform it, adding a Coldfire processor to either makes some sense.
The real trick would be getting AROS to use both processors. AmigaOS and its derivitives have never sucessfully used more than one processor.
No, that's out of the question. SMP would be too big of a hassle and even if it could be done, I'd then simply have 2 Coldfires and have one of those emulate 68K.
AROS 68K could run on both CPUs indivudally. FIDO would "simply" execute all those apps that have a problem with CF. But it complicates things, I'd need dedicated SDRAM for FIDO and sharing resources(graphics, HD, audio) could be a problem. To tell you the thruth, I'd much rather emulate 68K compatibility on CF. It's simpler, cheaper and, like I said, I'd be happy with 68040 performance.
-
The best solution would be to have enough demand to burn a real cpu from the N68070.
Indeed. But it must be first tested. How far are they from implementing it?
-
Indeed. But it must be first tested. How far are they from implementing it?
The first Natami MX (developer) boards, I believe, should be arriving to the team at anytime. The N68050 is only running in simulation at this point but that allows for some testing. There is a lot of work ahead before the N68070 is done. It would probably be a couple of years at current pace I would guess. The price of the fpga should have dropped substantially by then. The N68050 will be first of course. I think MiniMig 68020+AGA will beat the Natami to market but won't be nearly as powerful. The Natami developer boards will have a 68060 socket giving good compatibility before the N68k is ready and for testing (has mmu). A low frills motherboard with a 68040/060 socket (buyer provides CPU) would give good compatibility and descent speed. You could do a small fpga for the Amiga chip set and ColdFire for I/O + PCI + PCI RTG gfx card, PCI ethernet card and PCI usb card. The difficult part is always the software and drivers for these types of projects. They usually end up taking way more time and effort than expected.
-
I'd be happy with 68040 performance.
In that case an FPGA Arcade Replay board seems like it'd be a better bet. Last time Yaqube posted an update he got SysInfo results of 0.54 x A4000 w/ 25MHz 68040 - I'm sure that can be improved on further with more work and/or with a rev.2 of the board with a faster FPGA or other changes such as faster memory subsystem...
But by all means, go ahead and try Coldfire too, be interesting to see the results with AROS given that far less of the code would need trapping/emulation than with unmodified AmigaOS
-
But by all means, go ahead and try Coldfire too, be interesting to see the results with AROS given that far less of the code would need trapping/emulation than with unmodified AmigaOS
Exactly... this idea of mine is specifically for AROS68K as I expect that in the coming years AROS68K will be making the biggest progress since 68K is the platform most loved by amigans and it has probably the biggest number of users and devs. Some extra performance would be welcomed, I believe, for the future growth.
-
There's nothing stopping anyone from porting AROS to the coldfire right now except a lot of work and no real market incentive to do so. Currently AROS m68k-amiga is only partially complete and unoptimized in many areas like the native chip set graphics driver, so its currently slower than AmigaDOS 3.1.
While the m68k work is wonderful and is helping AROS to mature, I don't think it will remain much of a focus after its "done" (as in being a decent replacement for kickstart 3.1 ROMS) because the other architectures are getting all the benefits of its work, and other AROS improvements like the ongoing gallium work (supporting OpenVG and OpenGL hardware acceleration) are more likely to be worked on and targeted for ARM and x86 based hardware.
-
There's nothing stopping anyone from porting AROS to the coldfire right now except a lot of work and no real market incentive to do so. Currently AROS m68k-amiga is only partially complete and unoptimized in many areas like the native chip set graphics driver, so its currently slower than AmigaDOS 3.1.
While the m68k work is wonderful and is helping AROS to mature, I don't think it will remain much of a focus after its "done" (as in being a decent replacement for kickstart 3.1 ROMS) because the other architectures are getting all the benefits of its work, and other AROS improvements like the ongoing gallium work (supporting OpenVG and OpenGL hardware acceleration) are more likely to be worked on and targeted for ARM and x86 based hardware.
We'll see... I haven't been meaning to start any of this before AROS68K reaches a certain point where it is usable enough.
I think you're wrong. OS 3.x has many limits and while AROS shares many of them, it's open source nature could provide decent push for the classics and their users and devs. Especially if new 68k hardware arrives, be it Natami or something else.
I think that AROS has more sense for 68K then x86 or ARM. However, it remains to be seen what kind of performance and compatibility it will achieve on 68K hardware.
-
So, to summarize, we're talking about a V4 Coldfire with its own memory used in an accelerator installed on legacy Amigas running AROS68K (suitably modied to run on a Coldfire processor). Is this correct?
-
So, to summarize, we're talking about a V4 Coldfire with its own memory used in an accelerator installed on legacy Amigas running AROS68K (suitably modied to run on a Coldfire processor). Is this correct?
In a word, yes.
Usage? Hobby.
Why make it? To provide a hardware solution for AROS 68K. Running AROS68K natively on a V4e Coldfire would provide a noticeable improvement over even the fastest 680x0. Only apps affected by 68K/CF incompatibility would be affected and would run at 030 or 040. But, with a max of 4 GB DDR RAM, a PCI graphics card(Matrox still makes new PCI cards and they'd be willing to provide documentation, but alternatively older Radeon or GeForce cards could be possibly used, especially if supported under Gallium) and fast disk would it matter much? I think there is no 68K application that would not run EASILY on such a configuration.
Elbox Dragon was supposed to be priced at 350 euros, according to their website.
-
In a word, yes.
Usage? Hobby.
Why make it? To provide a hardware solution for AROS 68K. Running AROS68K natively on a V4e Coldfire would provide a noticeable improvement over even the fastest 680x0. Only apps affected by 68K/CF incompatibility would be affected and would run at 030 or 040. But, with a max of 4 GB DDR RAM, a PCI graphics card(Matrox still makes new PCI cards and they'd be willing to provide documentation, but alternatively older Radeon or GeForce cards could be possibly used, especially if supported under Gallium) and fast disk would it matter much? I think there is no 68K application that would not run EASILY on such a configuration.
Elbox Dragon was supposed to be priced at 350 euros, according to their website.
I would really like to know more about what Elbox was planning. I just downloaded some technical data from Freescale and I'm having trouble seeing how a MCF5474 could be implemented in an accelerator. The Coldfire CPU has some common instructions it shares with the 68K but the interfaces are radically different. The MCF5474 is a much more integrated product. Not quite an Soc but close.
-
To clarify one part of this discussion, the ColdFire cannot be made to run all m68k code by trapping unimplemented instructions because it has some instructions which overlap m68k instructions. In order to have decent performance, something like CyberPatcher would have to be run on all loaded m68k code before execution.
Here's a good overview of the differences between m68k and ColdFire:
http://www.microapl.co.uk/Porting/ColdFire/cf_68k_diffs.html (http://www.microapl.co.uk/Porting/ColdFire/cf_68k_diffs.html)
-
I would really like to know more about what Elbox was planning. I just downloaded some technical data from Freescale and I'm having trouble seeing how a MCF5474 could be implemented in an accelerator. The Coldfire CPU has some common instructions it shares with the 68K but the interfaces are radically different. The MCF5474 is a much more integrated product. Not quite an Soc but close.
There are some pictures of Dragon here from 2006...
http://tdolphin.org/amikrak/amizaduszki2006.php
I wonder if they'd be willing to sell the design if it still exists?
-
There are some pictures of Dragon here from 2006...
http://tdolphin.org/amikrak/amizaduszki2006.php
I wonder if they'd be willing to sell the design if it still exists?
Interesting! Looks like it relies on RTG. What, if any, Amiga legacy components are supported?
-
Interesting! Looks like it relies on RTG. What, if any, Amiga legacy components are supported?
I'm trying to find some more info about it...
-
I'm trying to find some more info about it...
I re-examined the photos you referenced and looked at Elbox's website to gather further information.
The base for the 1200 Dragon system is a replacement bus board similar to their Mediator but with a processor slot and an AGP video slot. An Lattice FPGA is visible on the bus board.
I assume that connection to a 1200 motherboard is similar to a Mediator 1200.
There is little visble on the CPU card except for the two DDR memory slots visble on the back of the CPU card.
The Coldfire processor mentioned is the MCF5475. This is slightly different than the MCF5474 I've seen mentioned in relation to the Atari Coldfire Project.
One thing that becomes apparent is that the Coldfire's main interface with other components is via the PCI bus.
This approach (which suits the Coldfire's inferface) is not similar to other 68K based accelerators.
In order to use this processor a heavily customized OS would be needed.
I'm not sure why some of the photos show AmigaOS 4.0 splash screens. To the best of my knowledge AOS4 makes no use of an Amiga's 68K processor (running all code on the PPC processor).
If I can dig up any further details I'll post them.
Jim
Edit - Looking at the design of this processor, I don't see how it could be incorporated into an Amiga as code that directly accesses legacy hardware locations would not function correctly.
-
I re-examined the photos you referenced and looked at Elbox's website to gather further information.
The base for the 1200 Dragon system is a replacement bus board similar to their Mediator but with a processor slot and an AGP video slot. An Lattice FPGA is visible on the bus board.
I assume that connection to a 1200 motherboard is similar to a Mediator 1200.
There is little visble on the CPU card except for the two DDR memory slots visble on the back of the CPU card.
The Coldfire processor mentioned is the MCF5475. This is slightly different than the MCF5474 I've seen mentioned in relation to the Atari Coldfire Project.
One thing that becomes apparent is that the Coldfire's main interface with other components is via the PCI bus.
This approach (which suits the Coldfire's inferface) is not similar to other 68K based accelerators.
In order to use this processor a heavily customized OS would be needed.
I'm not sure why some of the photos show AmigaOS 4.0 splash screens. To the best of my knowledge AOS4 makes no use of an Amiga's 68K processor (running all code on the PPC processor).
If I can dig up any further details I'll post them.
Jim
Edit - Looking at the design of this processor, I don't see how it could be incorporated into an Amiga as code that directly accesses legacy hardware locations would not function correctly.
The CPU slot is designed to take a PPC / 68K processor.
-
I was juts looking at some of the V5 Coldfires that can be found in certain printers...
They go as high as 540 MHz!!! Even emulated, any 68K apps would FLY! Man, this would be a killer CPU to test AROS on. I wonder is there any way to get these chips but not having to deal with Freescale directly?
-
I was juts looking at some of the V5 Coldfires that can be found in certain printers...
They go as high as 540 MHz!!! Even emulated, any 68K apps would FLY! Man, this would be a killer CPU to test AROS on. I wonder is there any way to get these chips but not having to deal with Freescale directly?
What printers are they found in and are the processors socketed or soldered directly to the boards>
-
What printers are they found in and are the processors socketed or soldered directly to the boards>
HP LaserJet series is one example...
Here's one... V5 @ 540 MHz (http://www.shopping.hp.com/product/printer/LaserJet/1/storefronts/901731) - go to specs page.
I was thinking of possibly "raiding" broken HP printers for these V5s :roflmao:
-
Some more info on V5e...
supports DDR2 RAM(V4e only DDR)
has onboard Wi-Fi on some models(correction - can come with W-Fi interface, needs ZigBee Wi-Fi board).
I'll try to get an example through HP channels(or some other vendors).
-
Some more info on V5e...
supports DDR2 RAM(V4e only DDR)
has onboard Wi-Fi on some models(correction - can come with W-Fi interface, needs ZigBee Wi-Fi board).
I'll try to get an example through HP channels(or some other vendors).
Yes, but is it a BGA that is soldered directly to the board? We would have a lot of trouble salvaging those.
-
Yes, but is it a BGA that is soldered directly to the board? We would have a lot of trouble salvaging those.
I don't know, but I know a person who works with printers and I have asked him to find out if I could buy V5e through him(since he services printers and has contacts at various companies), along with any documentation/developer's tools. I also asked about motherboards... I should have answers in a day or two.
I think a 540 MHz V5e would be great to have. :)
That's probably more then enough for DVD playback and encoding.
-
I don't know, but I know a person who works with printers and I have asked him to find out if I could buy V5e through him(since he services printers and has contacts at various companies), along with any documentation/developer's tools. I also asked about motherboards... I should have answers in a day or two.
I think a 540 MHz V5e would be great to have. :)
That's probably more then enough for DVD playback and encoding.
From a technical aspect, its interesting, but if it requires to much work to get 68K code running I'm wondering if there's an advantage over MorphOS' JIT interpreter.
-
From a technical aspect, its interesting, but if it requires to much work to get 68K code running I'm wondering if there's an advantage over MorphOS' JIT interpreter.
Well, this would be a fun project aimed entirely at classic hardware and aimed for AROS68K only.
But... if it's 540 MHz passive cooling, then greater speeds might be possible with fan cooling. Also, it supports DDR2 RAM(more then 4 GB RAM is possivble with V5e)... this would be a pretty decent computer in any way. Add AGP graphics and it'd be great for upgrading 68K systems(though I suspect it would have to be a towered system for it to fit). Don't know, maybe a standalone board which would fit inside any Amiga + FPGA makes more sense?
V5e is an enhanced V5e core. Unfortunately, there's very, very little info about these even on Freescale's webpage. That's why I asked about documentation. Even so, a V5e is fully superscalar and could be fully pipelined. At 540 MHz, it should run above 060 speeds even in 68K emulation mode.
-
Well, this would be a fun project aimed entirely at classic hardware and aimed for AROS68K only.
But... if it's 540 MHz passive cooling, then greater speeds might be possible with fan cooling. Also, it supports DDR2 RAM(more then 4 GB RAM is possivble with V5e)... this would be a pretty decent computer in any way. Add AGP graphics and it'd be great for upgrading 68K systems(though I suspect it would have to be a towered system for it to fit). Don't know, maybe a standalone board which would fit inside any Amiga + FPGA makes more sense?
V5e is an enhanced V5e core. Unfortunately, there's very, very little info about these even on Freescale's webpage. That's why I asked about documentation. Even so, a V5e is fully superscalar and could be fully pipelined. At 540 MHz, it should run above 060 speeds even in 68K emulation mode.
I appreciate your enthusiasm, and I'd urge you to explore this idea fully.
My only reservation, as I've sort of stated before, is that if emulation is required then solutions we already have may work just as well (or better).
-
I appreciate your enthusiasm, and I'd urge you to explore this idea fully.
My only reservation, as I've sort of stated before, is that if emulation is required then solutions we already have may work just as well (or better).
I cannot be more specific on emulation because there's no info on what instructions are added/omitted from V5(e) and what's the difference to 68K or prior CF chips. None that I could find...
Also, there's no C68Klib for V5 and V5e cores... I wonder if it is because they're more compatible with 68K or there's no demand for it since V5 and V5e are only sold to big hardware manufacturers. We'll see..
-
This project seems like a pipe dream to me (though I'm always open to surprises!), but if you're going to upgrade the Amiga with a processor that needs an emulation layer in the end anyway, why not go for something other that Coldfire? The Atom series have built in Intel graphics, as far as I understand, which seems like a huge advantage. Of course, then it'll be Intel Inside :)
Regarding monster accelerators in general, I don't understand why it isn't done the other way around. Like, a PCI card with the Amiga specifics on it (implemented in FPGA?) and the host computer would slave as a peripheral interface and 68k emulator.
By now, people might consider directing me to WinUAE or similar emulators, but ultimately, WinUAE isn't as responsive as a real Amiga, which is pretty much the only reason I still have an A1200 on my desk. Relatively small delays in keyboard/mouse input and sound/video output add up and detract from the experience I'm looking for.
-
This project seems like a pipe dream to me (though I'm always open to surprises!), but if you're going to upgrade the Amiga with a processor that needs an emulation layer in the end anyway, why not go for something other that Coldfire? The Atom series have built in Intel graphics, as far as I understand, which seems like a huge advantage. Of course, then it'll be Intel Inside :)
Regarding monster accelerators in general, I don't understand why it isn't done the other way around. Like, a PCI card with the Amiga specifics on it (implemented in FPGA?) and the host computer would slave as a peripheral interface and 68k emulator.
By now, people might consider directing me to WinUAE or similar emulators, but ultimately, WinUAE isn't as responsive as a real Amiga, which is pretty much the only reason I still have an A1200 on my desk. Relatively small delays in keyboard/mouse input and sound/video output add up and detract from the experience I'm looking for.
Again, this would not be directed at AmigaOS, but AROS68K. I wouldn't even be talking about this for Os 3.x because it's too much of a hassle for not much speed up.
Emulation layer would be needed for those apps/games that call 68K specific instruction that are absent from CF. With the V5e core, even those apps would probably run far faster then on real 68060. On V4e core, they would run somewhere between 030 and 040 speeds.
For apps compiled on CF and newly written apps, they would run completely native on CF and at full speed.
But the key point here is that 68060 costs a LOT of money, while CFs are dirt cheap. And they enable modern peripherals, DDR RAM, ATA, even Wi-Fi.
This is only an idea currently.
-
Again, this would not be directed at AmigaOS, but AROS68K. I wouldn't even be talking about this for Os 3.x because it's too much of a hassle for not much speed up.
Emulation layer would be needed for those apps/games that call 68K specific instruction that are absent from CF. With the V5e core, even those apps would probably run far faster then on real 68060. On V4e core, they would run somewhere between 030 and 040 speeds.
For apps compiled on CF and newly written apps, they would run completely native on CF and at full speed.
But the key point here is that 68060 costs a LOT of money, while CFs are dirt cheap. And they enable modern peripherals, DDR RAM, ATA, even Wi-Fi.
This is only an idea currently.
Yes, Coldfire is cheap and it would add a PCI interface and USB ports (as well as some other feature I haven't reviewed yet). The emulation (or JIT interpretation) would have to function on all 68K code and not just for missing instructions, but also for instructions that operate differently (on Coldtfire than the 68K).
It might be hard to get the V5s, so don't give up on the V4s yet.
I'd love to see this combined with a FPGA emulating the Amiga chipset.
-
I'd love to see this combined with a FPGA emulating the Amiga chipset.
Me too... I'd prefer it to be an acc. card(towered 1200 or 4000) because of price, but if it is not to be for this or that reason, a standalone motherboard with FPGA could be made.
But I'd like to avoid a standalone option, because it would be pricier, competing with NATAMI and while it would probably be somewhat cheaper, we do not need 2 very similar products with a similar price on this very small market.
-
Me too... I'd prefer it to be an acc. card(towered 1200 or 4000) because of price, but if it is not to be for this or that reason, a standalone motherboard with FPGA could be made.
But I'd like to avoid a standalone option, because it would be pricier, competing with NATAMI and while it would probably be somewhat cheaper, we do not need 2 very similar products with a similar price on this very small market.
Actually, it would be a fourth system in a limited market. First the Minimig, then the FPGA Arcade, then the Natami, and finally this system.
So you're right, it would be better to keep the price down (by avoiding a FPGA).
-
The 68060 is already about the same MIPS/MHz as the V4 ColdFire with smaller caches, no link stack, etc. The 68060 can do more per cycle than the V4 ColdFire. Multilplication, division, shifting is all faster on the 68060. The 68060 has useful instructions that are missing on the ColdFire. Granted, the ColdFire has some useful instruction additions also. The N68k has everything except clock speed. None of the instructions are missing, ColdFire additions are included, other instruction additions are useful, multiple instructions per clock are possible, large caches, link stack, predicated branches, byte and word instructions are as fast as long, bitfield instructions are fast, large instruction prefetch, etc. The V4 ColdFire is nothing special. It's on par with a very fast 68040 with larger caches and a few other enhancements. The V5 ColdFire is a different story. It's more like a 68060 from what little information I could find on it. It would very likely be faster than the N68070 will be in fpga. The ColdFire does need optimized code and would be harder to get max performance from than the N68070 as currently planned. It's easy enough to say, just compile new code for it, but that's where a lot of the problem is. Compilers generate poor code especially on the 68k. I have a library that started out at 67648 bytes and I have optimized down to 39824 bytes so far. I think 1/2 the original size is possible although I'm optimizing for speed and not size. Before you say that this must have been some poor C coders, I'll tell you that this piece of work was done by a fairly famous pair of brothers (in Amiga land) who now work for Hyperion. I hope there PPC optimizing is better because the PPC is not nearly as forgiving of crap code.
Or RISC vs CISC lol
Acorn Archimedes had the same issue, and people all said 'whatever' 'what happens when you need to divide?'
Truth was when you all paid 1000s for crapp 7mhz A2000s and then played a 16 colour game called Virus at 10-15FPS the Archimedes did it in 256 colours and 30+ FPS in 1987
RISC is better, and a Coldfire v4 + AROS specific kernal recompile + UAE = Rocket Ranger running 100%.
Why do people have to make it so difficult. AROS Coldfire for legal Amiga apps written in guidelines, AROS+UAE for legacy/games stuff.
It's not like MorphOS does it any better, or OS4 come to that ;) At least Coldfire is dirt cheap unlike way OTT priced PPC boards to run OS4/MOS
-
Actually, it would be a fourth system in a limited market. First the Minimig, then the FPGA Arcade, then the Natami, and finally this system.
So you're right, it would be better to keep the price down (by avoiding a FPGA).
I wouldn't consider Minimig or FPGA arcade as competitors to Natami or my proposed CF machine. Sure, there is some common ground between them, but my idea is more of a next-gen 68K like Natami.
If I cannot get this my idea for under 400-500 euros, I will not do it. Primarily because then, IMHO, it becomes too expensive to be called hobby(even so, I'm sure some people might still want to buy a machine like that) and it would be too close to natami to justify it for me personally.
-
Or RISC vs CISC lol
Acorn Archimedes had the same issue, and people all said 'whatever' 'what happens when you need to divide?'
Truth was when you all paid 1000s for crapp 7mhz A2000s and then played a 16 colour game called Virus at 10-15FPS the Archimedes did it in 256 colours and 30+ FPS in 1987
RISC is better, and a Coldfire v4 + AROS specific kernal recompile + UAE = Rocket Ranger running 100%.
Why do people have to make it so difficult. AROS Coldfire for legal Amiga apps written in guidelines, AROS+UAE for legacy/games stuff.
It's not like MorphOS does it any better, or OS4 come to that ;) At least Coldfire is dirt cheap unlike way OTT priced PPC boards to run OS4/MOS
Actually, if you look at the benchmarks, MorphOS does do better in a lot of areas. X86 definitely has more horsepower to run 68K emulation, but in most other areas MorphOS has an edge.
http://www.lukysoft.cz/?page=benchmarks
And since Coldfire is a CISC, I suspect that RISCs like ARM and PPC might outperform it.
PPCs are expensive, but ARM and Coldfire are not so we'll just have to see.
-
I wouldn't consider Minimig or FPGA arcade as competitors to Natami or my proposed CF machine. Sure, there is some common ground between them, but my idea is more of a next-gen 68K like Natami.
If I cannot get this my idea for under 400-500 euros, I will not do it. Primarily because then, IMHO, it becomes too expensive to be called hobby(even so, I'm sure some people might still want to buy a machine like that) and it would be too close to natami to justify it for me personally.
Personally, I'd hope for an even lower price as 400-500 euros strikes me as a little high.
I could see that if it did incorporate a small FPGA, but if not I'd hope to see it for as little as half that figure.
-
Personally, I'd hope for an even lower price as 400-500 euros strikes me as a little high.
I could see that if it did incorporate a small FPGA, but if not I'd hope to see it for as little as half that figure.
Atari Coldfire is 599 euros(they have a expensive FPGA oboard), so you are right...
My goal would 300-350... But I have insufficient info to base that on any real life data. Especially the V5e price.
-
Atari Coldfire is 599 euros(they have a expensive FPGA oboard), so you are right...
My goal would 300-350... But I have insufficient info to base that on any real life data. Especially the V5e price.
If the only way to get V5s is to salvage them and have the processors re-balled this could get expensive.
The V4 still might be an easier to obtain option.
-
Actually, if you look at the benchmarks, MorphOS does do better in a lot of areas. X86 definitely has more horsepower to run 68K emulation, but in most other areas MorphOS has an edge.
http://www.lukysoft.cz/?page=benchmarks
And since Coldfire is a CISC, I suspect that RISCs like ARM and PPC might outperform it.
PPCs are expensive, but ARM and Coldfire are not so we'll just have to see.
MorphOS is no better than OS4/AROS in the context of my post. ALL use UAE to run legacy stuff like Rocket Ranger.
So OS + Emulator requirement is present on all 3 for REAL Amiga functionality.
My point about ARM or RISC was the removal of instructions to streamline the chip performance is exactly what ARM v1 did in 85 prototype and 87 retail machines. 400 MIPS is more than enough to emulate OCS or ECS and if you are writing a specific version of AROS for Coldfire and using something like Starscream to emulate 68000 then it is a non-issue.
We need to get off PoS PPC hardware that is overpriced AND underpowered. There is only an issue with getting KS/WB to run on Coldfire, if you are writing an OS version of AROS for it there is no issue whatsover.
-
MorphOS is no better than OS4/AROS in the context of my post. ALL use UAE to run legacy stuff like Rocket Ranger.
So OS + Emulator requirement is present on all 3 for REAL Amiga functionality.
My point about ARM or RISC was the removal of instructions to streamline the chip performance is exactly what ARM v1 did in 85 prototype and 87 retail machines. 400 MIPS is more than enough to emulate OCS or ECS and if you are writing a specific version of AROS for Coldfire and using something like Starscream to emulate 68000 then it is a non-issue.
We need to get off PoS PPC hardware that is overpriced AND underpowered. There is only an issue with getting KS/WB to run on Coldfire, if you are writing an OS version of AROS for it there is no issue whatsover.
You're mistaken if you think we in any way disagree. I like my current PPC system because it is low cost and while I look forward to G5 Mac support I can't really justify the cost of new PPC hardware.
ARM would definitely be an improvement. They've already developed 2Ghz ARM processors, the current A9s should be good for 2.5Ghz, and I expect to see higher performance out of later introductions like Nvidia's Denver Project.
And yes, X86 emulation does seem to work fine. If you've got legacy apps its hard to argue with the performance advantage. I just pointed out those benchmarks because they point out pretty clearly that MorphOS does a fairly good job at 2D and other non CPU related tasks.
In the last few months I've been a pretty vocal advocate of moving to ARM.
Now Coldfire, the main thing that worries me (besides compatibility i ssues) is that its getting rather old and the fastest available version is the 266Mhz V4. That's a solid improvement over a 50Mhz 68060, but I'm still not sure it makes sense when compared to ARM or X86 (both of which can outperform this).
Anyway, lets see if there is some way to obtain V5es. If so (even in small quantities) this could offer the additional performance that would help justify this project.
-
If you're breaking 68k compatability anyway - why not go for something that's available, fast and even cheap? If it's fast enough it's just a matter of emulation to get legacy software to decent speed while running recompiled / native code much faster still.
As much as I love the 68k family I totally fail to see the point in investing into dead ends with large price tags.
-
It is proven that is possible to write programs so that they run both systems 68k and coldfire.
Old programs needs a emulation layer, but new programs are possible to run without it. It is diffrent question what would developers do, what kind of effort would be to write program to run both, coldfire and 68k cpus
-
It is proven that is possible to write programs so that they run both systems 68k and coldfire.
Old programs needs a emulation layer, but new programs are possible to run without it. It is diffrent question what would developers do, what kind of effort would be to write program to run both, coldfire and 68k cpus
It would be rediculous to make acellerator board which must use emulation. Better to bake softcore in fpga like Natami.
-
It would be rediculous to make acellerator board which must use emulation. Better to bake softcore in fpga like Natami.
They would run OS and recompiled apps natively(+ those not calling missing instructions)...
Natami will be very expensive and if I could get V5e cores, slower.
A cheap, fast, modern peripherals enabling 68K acc. board would make sense... I think.
Imagine running V5e at 600 MHz, a few gigs of RAM, a AGP or PCI graphics card + (S)ATA controller, USB 2.0 and possibly even Wi-Fi. All that on classics for less then half the money NATAMI would probably cost you.
-
Imagine running V5e at 600 MHz, a few gigs of RAM, a AGP or PCI graphics card + (S)ATA controller, USB 2.0 and possibly even Wi-Fi. All that on classics for less then half the money NATAMI would probably cost you.
You're grossly underestimating the complexity and costs of the design, development and production of such a HW. You can't just plug the CPU on some board and have it magically running. The limited numbers of boards you'd have to make would bump the price skyhigh. You're not the first one to make this mistake.
I fail to see the point of this anyway: It makes much more sense to run the whole thing inside a commodity HW. There's no way you can beat the bang/buck ratio with a custom design.
-
Given that both elbox and olie have both tried and given up
-
Given that both elbox and olie have both tried and given up
For AROS68K? I think they have not tried...
sure, this would be a complex project. But at this stage it's just an idea.
Depending on whether I'd find anyone interested in helping and on some other factors as the availability of the V5e core and the price, I might just try and do it :)...
If not, I'll revert to a 6502-based project.
I consider this primarily an educational project for myself.
-
If its just an edu project for yourself then go for it.
If this idea is for a commercial project to run a new branch or Aros then wouldnt bother, there is no advantage that can see
-
While I think you might have fun making a coldfire port of AROS, it seems to be limited to plain old PCI bus for the graphics. Under AROS x86 with the nouveau driver there is a performance increase going from PCI to AGP to PCIe support. It looks to me like ARM cortex devices would be more modern HD multimedia friendly than the coldfire because they can interface internally to their graphics subsystems and not run through a slower external bus interface, though I suppose someone would have to benchmark the two using similar code to be sure.
-
It is proven that is possible to write programs so that they run both systems 68k and coldfire.
It will be proven when someone will show a working solution... Until then...
-
@WolfToTheMoon
The only reasonable way to start is to get hold of a CF V4 developer board and get AROS running on that first, _then_ you can come back and talk about doing all the other things you've mentioned.
-
@WolfToTheMoon
The only reasonable way to start is to get hold of a CF V4 developer board and get AROS running on that first, _then_ you can come back and talk about doing all the other things you've mentioned.
That would be a valid idea, but I can't find one on Freescale's site. Do you know of any?
BTW- If you can get to France, these two courses look interesting.
http://www.mvd-fpga.com/training/en/files/formations003831A.pdf
http://www.mvd-fpga.com/training/en/files/formations003382A.pdf
Correction -First development board found
$850 for evaluation board for MCF547X Coldfire Microprocessor
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M5475EVB&fsrch=1&sr=1 (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M5475EVB)
Freescales direct sales system erroneously pairs this up with a PPC processor that wouldn't be applicable for this board.
I still have to find out if this board comes with a processor (but it seems likely).
The MCF54455 would probably be a better processor to use. I haven't found an evaluation board fort this though.
http://cache.freescale.com/files/32bit/doc/data_sheet/MCF54455.pdf
I can get samples of the 266Mhz MCF54455 from Freescale, but starting a project with these is daunting.
OK, evaluation board for the MCF54455 (also $850)
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M54455EVB&fsrch=1&sr=2
-
It can be done, how ever its a matter of money.
But what about the Dragonball?? There you can have everything in one unit. Its old, but still..
For 68k and coldfire compatibility there is this http://www.microapl.co.uk/Porting/ColdFire/cf68klib.html
-
It can be done, how ever its a matter of money.
But what about the Dragonball?? There you can have everything in one unit. Its old, but still..
For 68k and coldfire compatibility there is this http://www.microapl.co.uk/Porting/ColdFire/cf68klib.html
Nice reference, interesting company. Although I'm still curious as to what a 68340 is (in the chart in their FAQ).
Looks like Coldfire could be used to work with some 68000 code, but the interpreter still doesn't handle instructions that operate differently on Coldfire.
BTW - Dragonball is slowww..
And is EOL (not available).
-
Alot of those expensive do-it-all printers are actually running linux and have harddrives.
If your friend services them you may want to look at a mainboard and use it as your platform. However you may be missing a decent gpu... They do run LCD-touch screens but the resolutions are low.
-
The best thing we found out is that seems that Freescale haven't given up on Coldfire family.
This V5e core is a complete mystery. Hardly any info about it but it is plain that it is not a simple derivation of the V5 core(since V5 goes up to 333 MHz, but V5e has a 540 MHz version, leading me to speculate it may be a significant upgrade to the base V5 core or maybe even a different manufacturing process/technology). It may lead to a V6 core Coldfire sometimes in the future. According to their plans that were presented 8-9 years ago, a V6 core should have been out by now, but obviously things have not be progressing in a manner they anticipated. Still, if V6 core gets launched, that would mean a potential 800 MHz 68K compatible, with possible USB 3.0 support, SATA, PCIe...
-
@WolfToTheMoon
The only reasonable way to start is to get hold of a CF V4 developer board and get AROS running on that first, _then_ you can come back and talk about doing all the other things you've mentioned.
Just buy an Atari cf board and get it working there first.
-
What is the price of those CPUs? Unless they are dirt cheap, I don't see the point.
If you want to resurrect an old project how about the G3 PPC card instead?
-
What is the price of those CPUs? Unless they are dirt cheap, I don't see the point.
If you want to resurrect an old project how about the G3 PPC card instead?
ColdFire CPUs are dirt cheap... in fact, you could probably sell an entire acc board with a V4e Coldfire, DDR RAM and PCI GPU for the price of one 68060 CPU.
-
If you want to resurrect an old project how about the G3 PPC card instead?
For AOS4/MOS?
Yes, there are dirt cheap PPC accelerators out there for old Macs but it will never happen for Classic Amigas because Hyperion will probably never sanction such a project. It would be too big ofa a threat to the Acube and A-eon partnership.
As to MOS, that should be discussed with the MOS team but I doubt they would sanction it either.
So, pretty much the only choice now for classics is either 68K(OS 3.x) or Coldfire(AROS68K) acc boards.
-
Run th CF68Klib in supervisormode, then most kind of 68k SW/OS should be possible to run on af CF cpu
-
ColdFire CPUs are dirt cheap... in fact, you could probably sell an entire acc board with a V4e Coldfire, DDR RAM and PCI GPU for the price of one 68060 CPU.
Yes Coldfires are cheap. About a quarter the price of a 68060, and I can get '060 50s for under $50. I don't think the accelerator boards would be quite as inexpensive as you've estimated, but they should undercut 68K accelerators and would be a lot lower than PPCs.
-
Run th CF68Klib in supervisormode, then most kind of 68k SW/OS should be possible to run on af CF cpu
The problem with CF68Klib, if you check the documentation, is that even in supervisor mode it doesn't trap instructions that run differently on the Coldfire than they do on the 68K.
I'm sure there's a way around this, but while CF68Klib looks promising, it may not be the only answer.
-
The problem with CF68Klib, if you check the documentation, is that even in supervisor mode it doesn't trap instructions that run differently on the Coldfire than they do on the 68K.
I'm sure there's a way around this, but while CF68Klib looks promising, it may not be the only answer.
The best bet is probably something like a simple tracing JIT translator where most instructions translate 1-to-1. You could do it mostly "in place" by scanning block by block and rewriting any offending instructions, and replace Bcc, JSR, JMP etc. with traps if you can't show they point to "safe" (already JIT'ed) code, then you jump to the code. If/when you trap again, you continue JIT'ing and patch the instruction that brought you there back to its original.
As an example, lets assume this completely bogus example sequence:
MOVE.L D0,-(SP)
SOME_BROKEN_INSTRUCTION
RTS
You'd decode all three instructions, then rewrite it like this:
MOVE.L D0,-(SP)
BSR some_free_location (unless SOME_BROKEN_INSTRUCTION is long enough for you to be able to "emulate" it inline, in which case you have it easy)
RTS
some_free_location:
[code to emulate SOME_BROKEN_INSTRUCTION]
RTS
The biggest problem is if SOME_BROKEN_INSTRUCTION is too short to provide enough space to branch elsewhere, in which case you have two choices: Resort forcing a trap or rewriting following instructions too. The latter quickly makes things trickier as you then have to deal with rewriting branches etc. that may point to the later instructions that you move.
You pay the additional cost of the JIT process, but once critical paths have been JIT'd, it'll run at near optimal native speed. "Near" because you get the extra overhead of potentially having extra branches to account for "patch sites" where there was no space in the original code to plug in the modified instructions, unless you go to the potentially significant extra trouble of rewriting the whole thing.
Note that this is not foolproof. Self modifying code etc. or code that intentionally jump into the middle of an instruction could still cause trouble and is much harder to deal with.
The JIT could be very fast, as for any instructions deemed "safe" it'd just need to recognize them and move on to the next instruction, and recognizing them could be done with a very small, compact decoder since it could discard large groups of instructions as safe with a few simple bit masks.
-
I have some info on the V5e...
The guy I contacted informed me that the entire motherboard from the HP laserJet that contains the V5e @ 540 MHz can be bought for about 500ish $ thru his service. I'm still trying to find info on whether I could get any V5e documentation.
-
...Note that this is not foolproof. Self modifying code etc. or code that intentionally jump into the middle of an instruction could still cause trouble and is much harder to deal with....
Man, I'd almost forgotten about that practice (self modifying code). Anyone resorting to that should be bitch slapped.
The JIT could be very fast, as for any instructions deemed "safe" it'd just need to recognize them and move on to the next instruction, and recognizing them could be done with a very small, compact decoder since it could discard large groups of instructions as safe with a few simple bit masks.
Having seen what the MorphOS team managed to do with JIT for 68K code running on PPCs I'd have say you've got a point. Since many of the instructions would not require modification, this should work fairly quickly.
-
I have some info on the V5e...
The guy I contacted informed me that the entire motherboard from the HP laserJet that contains the V5e @ 540 MHz can be bought for about 500ish $ thru his service. I'm still trying to find info on whether I could get any V5e documentation.
Well, at least we know they're available. Removing them from the boards and re-using them is nightmarish task, but not impossible. And the printers may be available used, refurbish, or broken allowing salvage of V5es from those sources.
Although I wouldn't discount the idea of using V4s just yet. They're available, low cost, and run at up to 266Mhz. As has been pointed out, JIT translation of 68K instructions to Coldfire should be aided by the similarities in the instruction sets.
-
here are some becnhmarks... a V4e Coldfire running at 200 MHz on a MCF5484 evaluation board vs CT60-100-25(68060 @ 100 MHz!) and Hades 060 atari clones.
http://img402.imageshack.us/img402/3604/kronos2.jpg
More info can be found HERE (http://didierm.pagesperso-orange.fr/ct60/ctpci-e.htm)
As you can see, the Coldfire V4e did rather good in most tests.
-
here are some becnhmarks... a V4e Coldfire running at 200 MHz on a MCF5484 evaluation board vs CT60-100-25(68060 @ 100 MHz!) and Hades 060 atari clones.
http://img402.imageshack.us/img402/3604/kronos2.jpg
More info can be found HERE (http://didierm.pagesperso-orange.fr/ct60/ctpci-e.htm)
As you can see, the Coldfire V4e did rather good in most tests.
I was actually surprised to see the 68060s doing as well as they did in comparison. That early Coldari posting is fascinating. Thanks..
-
Having seen what the MorphOS team managed to do with JIT for 68K code running on PPCs I'd have say you've got a point. Since many of the instructions would not require modification, this should work fairly quickly.
Exactly - for m68k on PPC it's a massive amount of work, and even more work to get it fast. For M68k on Coldfire a lot of it should be no-op's (though reading up on it, there *is* a lot of stuff that's common in Amiga code that will need JIT'ing - such as ROR/ROL, arithmetic on bytes or words, DBcc etc.) - just map and figure out if it's a "safe" instruction, if so decode enough to know the length of the instruction and skip; if not, check if it's one that can be replaced in-line, and patch or worst case patch in a branch and use a small-ish set of functions to generate the appropriate replacements...
If you want to be fancy, you can later deal with relocating jumps etc. and so inline all the modifications (which would even if you wanted to let you do "proper" tracing the way modern Javascript JIT's does, and take advantage of the larger cache on the ColdFire to trace longer instruction streams and unroll loops and auto-inline other functions).