»

[polyp2000]

Stumbled across this interesting thread over at aros-exec forums.

http://aros-exec.org/modules/newbb/v...forumpost71583

perhaps there is still a possibility for a coldfire based accelerator ?

N.

[Iggy]

http://amigaworld.net/modules/newbb/...e=flat&order=0

"it runs as a 68k Amiga at about ~74mhz or so"

Not particularly impressive.

Port AROS68K to Coldfire AND recompile other software and this might be useful.
Then emulation (of the 68K) would only be necessary for some software (what could not be recompiled).

[Heiroglyph]

But if you have to recompile to get any real speed out of it, you might as well recompile for a faster CPU.

Coldfire isn't worth the effort these days IMHO.

[XDelusion]

If that's the case then I'm happy with my 80Mhz 060 and OS 3.1 running with Magellan II. Aros is lacking too many basic features that an OS needs (I think if it as Gem with eye candy), plus it would be dog slow under such speeds.

Originally Posted by Iggy

http://amigaworld.net/modules/newbb/...e=flat&order=0

"it runs as a 68k Amiga at about ~74mhz or so"

Not particularly impressive.

Port AROS68K to Coldfire AND recompile other software and this might be useful.
Then emulation (of the 68K) would only be necessary for some software (what could not be recompiled).

[Cod3r]

I can tell you a bit about the project. In fact I can tell you everything about it. I'm the guy who did it.

In regards to speed, I did it really fast and in my spare time. In raw performance it may not be so impressive but if I was going to optimize it could be much faster.

Having a job takes away from the time to tinker on it.

But I agree that porting over 68k Aros to run on ColdFire would be beneficial.

Also note that the ColdFire V4 chip is running at 200mhz and the emulation is a little less than half its speed. If it were a faster chip the emulation would also be faster.

[number6]

@thread

same topic on AW

That should save some duplicate explanations.

#6

[utri007]

I belive that Elbox get A OS running with their Dragon accelerator something like 030 50mhz speed, mean no emulation just somekind of dragon.library?

They demoed it several times in Poland. http://www.elbox.com/news_06_11_11.html

That would be something, to get Dragon run A OS code without emulation, but much faster than Elbox did. It is also proved that it is possible make exe that can run natively both 68k and coldfire.

[psxphill]

Originally Posted by utri007

I belive that Elbox get A OS running with their Dragon accelerator something like 030 50mhz speed, mean no emulation just somekind of dragon.library?

They demoed it several times in Poland. http://www.elbox.com/news_06_11_11.html

That would be something, to get Dragon run A OS code without emulation, but much faster than Elbox did. It is also proved that it is possible make exe that can run natively both 68k and coldfire.

Elbox never released dragon because they couldn't get it working. Carefully choosing specific software to demo doesn't count.

Their demo was probably based on hand patched executables. Who is going to do all of that work to get every piece of software working?

Realistically the Amiga future is either fpga, arm or x64. Even the SEC 68000 versions that clock really high are a little pointless, they could at least build a 68030 if not a 68060. PowerPC is dead and gone.

And while you might argue we don't need fast processors as AmigaOS ran on 7mhz, go try it. Your web browsing experience will be very poor indeed. Software has grown to need a lot more processor power than was available even 10 years ago, which was 10 times faster than the fastest Amiga. Web browsing on the Amiga sucked in the 90's and it's only got worse.

[matthey]

Originally Posted by utri007

That would be something, to get Dragon run A OS code without emulation, but much faster than Elbox did. It is also proved that it is possible make exe that can run natively both 68k and coldfire.

I wouldn't call trapping 1/2 the 68k instructions on a ColdFire as "running native". It would destroy performance and thus the reason why Cod3r made an emulation layer. It's probably the same idea as OxyPatcher/CyberPatcher/MuRedox does for FPU instructions before they are trapped. It no doubt is easier to emulate the 68k on a ColdFire because of it's architectural similarities but the slow speeds and handicapped performance of the ColdFire make up for any advantage. Motorola/Freescale decided that the 68k can't compete with the PowerPC so they have been crippling it ever since the 68060 outperformed early PowerPCs. Freescale would rather develop weak sauce scaled down 68k like ColdFire micro-controllers and pay ARM licensing fees for an inferior product than use a little initiative to come up with an innovative and modern 68k design. It would be easier to run ColdFire code on a 68k processor. Not counting MAC or FPU instructions, there is only 6 or 7 instructions to trap at the user level and the emulation could be put in the CPU libraries. Freescale/Motorola did put MOV3Q in the A-line so no more 68k Macintosh emulation, REMU/REMS is not fully compatible with the DIVS/DIVU instruction and the ColdFire stack is 32 bit aligned instead of 16 bit aligned so there are "problems". The best bet for 68k and ColdFire native is probably in a new fpga CPU and possibly an ASIC after that. I have been working on a new ISA called 68koolFusion. The current evaluation documentation has BYTEREV, BITREV, FF1, SATS, MVS, MVZ, REMU and REMS. MOV3Q is weak and we found better ways to have the best code density in the industry (should easily beat ARM with Thumb 2 and CF . Some CF instructions have different encodings or mnemonics though. BYTEREV and BITREV are mnemonics for the new PERM instruction, FF1 is a mnemonic for BFFFO and REMU/REMS weren't compatible with the 68k as is. MVS, MVZ and SATS are encoded the same as the CF. That's as close as you will get to running "native" 68k and CF code.

http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf

@Cod3r
Nice work. The CF is weak but it does have 2 advantages and that's the built in hardware support (SoC) and price. I wondered why the Natami didn't use the CF for the hardware support considering the price and use the fpga for the main processor and Amiga chipset emulation. The CF could be used like a simple sound DSP also. SMP would not be easy to add but the Amiga has always been about coprocessors . The fpgaArcade offloads some of the work and processing to it's ARM processor but the CF would be more familiar to Amiga programmers even if it's a watered down 68k microcontroller for the hardware. Add an fpga of Cyclone III size or bigger for the 68k and chipset emulation with basic hardware support like ethernet, USB and PCI through the CF and do it for less than $500 U.S. and you might have a winner. There is fpga code for 68k processors and the AGA chipset available to enhance and put in the fpga.

[XDelusion]

Very cool! I know it is slow, but very cool none the less!

And yes, I'm sure with more work, things could be fleshed out, improved upon, and sped up, but it always requires time, help, and patience, and that is sometimes the tricky part.

Sorry, didn't mean to dog your efforts.

Originally Posted by Cod3r

I can tell you a bit about the project. In fact I can tell you everything about it. I'm the guy who did it.

In regards to speed, I did it really fast and in my spare time. In raw performance it may not be so impressive but if I was going to optimize it could be much faster.

Having a job takes away from the time to tinker on it.

But I agree that porting over 68k Aros to run on ColdFire would be beneficial.

Also note that the ColdFire V4 chip is running at 200mhz and the emulation is a little less than half its speed. If it were a faster chip the emulation would also be faster.

[Cod3r]

Originally Posted by matthey

I wouldn't call trapping 1/2 the 68k instructions on a ColdFire as "running native". It would destroy performance and thus the reason why Cod3r made an emulation layer. It's probably the same idea as OxyPatcher/CyberPatcher/MuRedox does for FPU instructions before they are trapped. It no doubt is easier to emulate the 68k on a ColdFire because of it's architectural similarities but the slow speeds and handicapped performance of the ColdFire make up for any advantage. Motorola/Freescale decided that the 68k can't compete with the PowerPC so they have been crippling it ever since the 68060 outperformed early PowerPCs. Freescale would rather develop weak sauce scaled down 68k like ColdFire micro-controllers and pay ARM licensing fees for an inferior product than use a little initiative to come up with an innovative and modern 68k design. It would be easier to run ColdFire code on a 68k processor. Not counting MAC or FPU instructions, there is only 6 or 7 instructions to trap at the user level and the emulation could be put in the CPU libraries. Freescale/Motorola did put MOV3Q in the A-line so no more 68k Macintosh emulation, REMU/REMS is not fully compatible with the DIVS/DIVU instruction and the ColdFire stack is 32 bit aligned instead of 16 bit aligned so there are "problems". The best bet for 68k and ColdFire native is probably in a new fpga CPU and possibly an ASIC after that. I have been working on a new ISA called 68koolFusion. The current evaluation documentation has BYTEREV, BITREV, FF1, SATS, MVS, MVZ, REMU and REMS. MOV3Q is weak and we found better ways to have the best code density in the industry (should easily beat ARM with Thumb 2 and CF . Some CF instructions have different encodings or mnemonics though. BYTEREV and BITREV are mnemonics for the new PERM instruction, FF1 is a mnemonic for BFFFO and REMU/REMS weren't compatible with the 68k as is. MVS, MVZ and SATS are encoded the same as the CF. That's as close as you will get to running "native" 68k and CF code.

http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf

@Cod3r
Nice work. The CF is weak but it does have 2 advantages and that's the built in hardware support (SoC) and price. I wondered why the Natami didn't use the CF for the hardware support considering the price and use the fpga for the main processor and Amiga chipset emulation. The CF could be used like a simple sound DSP also. SMP would not be easy to add but the Amiga has always been about coprocessors . The fpgaArcade offloads some of the work and processing to it's ARM processor but the CF would be more familiar to Amiga programmers even if it's a watered down 68k microcontroller for the hardware. Add an fpga of Cyclone III size or bigger for the 68k and chipset emulation with basic hardware support like ethernet, USB and PCI through the CF and do it for less than $500 U.S. and you might have a winner. There is fpga code for 68k processors and the AGA chipset available to enhance and put in the fpga.

What I did was straight up emulation... no trapping or anything. I created a few psuedo-instructions that would allow the supervisor to activate a few native routines on the ColdFire, but that was about it.

Aros isn't aware it is running on a CF and other than optimizations I added for speed (that were called by my psuedo instructions), the whole OS basically ran on pure 68k code. The 68k emulator I wrote is called after initialization prior to loading the OS.

I agree that it isn't the fastest solution, but it works and it is clock-cycle accurate so that makes it really stable for software that doesn't work well with JIT emulation.

And ColdFire development boards are relatively inexpensive, so a complete system could easily be built under $500 USD.

[Cod3r]

Originally Posted by XDelusion

Very cool! I know it is slow, but very cool none the less!

And yes, I'm sure with more work, things could be fleshed out, improved upon, and sped up, but it always requires time, help, and patience, and that is sometimes the tricky part.

Sorry, didn't mean to dog your efforts.

Yes is is slow, but for 680x0 based system, it is not too bad. I don't have the ethernet ports or audio working yet, but like anything else it is a work in progress.

[Methuselas]

[matthey]

Originally Posted by Cod3r

I agree that it isn't the fastest solution, but it works and it is clock-cycle accurate so that makes it really stable for software that doesn't work well with JIT emulation.

I don't think your emulation can be called cycle exact. Cycle exact refers to the timing that instructions are executed on a particular CPU. It's not important on the latest 68k processors like the 68060 where it would be very bad to rely on CPU timing. Some old code relied on instructions or instruction loops to finish in a certain amount of time. The Amiga generally used the custom chips (the copper allows to wait for vertical blanks) for timing where old Atari code is more likely to need cycle exact timing of a 68000 or 68020/68030. Your emulation is potentially more compatible and simpler than JIT while being significantly faster than trapping. Not a bad compromise.

Originally Posted by Cod3r

And ColdFire development boards are relatively inexpensive, so a complete system could easily be built under $500 USD.

Personally, I would go with a cheap v4 CF and a big fpga if Freescale has such a development board. An fpga has the potential of executing 68k code more efficiently and accurately than the CF. It's also needed for emulating the Amiga custom chips. The CF could be used for AROS (with native CF apps) and for 68k emulation in a pinch or when there is problems with the fpga emulation. It's easier and faster to change and fix the C code of your CF emulator than an fpga emulation.