Why no Amiga equiv to Firebee?

[ppcamiga1]

AROS was started in 1995. Had support been strong back then, there would have been no need for OS4 or MorphOS, the competition between which caused the most fallout in the Amiga community.

MOS was started in 1999,  four years after AROS.
Amiga  Os 4  was started in 2001,  six years after AROS.
AROS devs had enough time to make a really good and compatible system.  

What was lacking back then was an understanding of how important is the open-source movement was to become.  

What was lacking back then was an understanding of how important is   porting AROS to platforms other than x86, especially 68k.

[ppcamiga1]

I know, and I agree, the Atari guys did get control of their platform earlier. However, I think you're missing my point; the reason the Atari guys got hold of their platform earlier is because they saw the benefits of open-source earlier. Amiga fans had this chance around the same time too, when AROS was announced, but largely chose to ignore the opportunity instead. That's the point I'm making.

Amiga fans chose something that works and was compatible.
It was a good decision.
We have fun with the OSes compatible with the Amiga OS, many years before AROS has become sufficiently compatible.

[Disparil]

I was never a fan of the Atari ST, but I did find the Atari Falcon interesting and would've loved to own one. Maybe now I'll get my chance, sort of.

[ppcamiga1]

The move to PowerPC was announced in 1995, the same year as AROS started, and the Amiga PPC hardware wasn't launched until 1997 (IIRC), so the momentum for the PowerPC wasn't there yet.

If only, AROS devs started from the version for 68k, maybe we have in 1996 functioning and compatible with the Amiga OS open source OS, and the PowerPC would not be needed.

Besides this, it's a common misconception that AROS = x86 Amiga. This is not the case. AROS was designed from the very outset to be platform agnostic, the x86 port just developed quicker than the others (for various reasons).  

AROS devs simply do not care about ports to other platforms, integration and testing their system with software 68k.

For example, before Jason and Toni started working on AROS 68k there was work done to port AROS to 68k Amigas, though the port wasn't maintained for a number of years (apart from AfAOS).  

I really appreciate their hard work.
They improved the AROS source code in thousands of places.
This shows how important was integration and tests with 68k software.
Thanks to their hard work in the summer of 2011 I was able to copy the original MUI to AROS 68k, and it works.
Finally, I could write software for Amiga OS and distribute it without restriction and problems.
That was the really wonderful.
If I only had such a great working system sixteen years ago.
In 1996 when I first saw AROS.
But time passes, and today is no longer possible to convince anyone to invest in software running on this system.
Really a shame.

[HenryCase]

MOS was started in 1999,  four years after AROS.
Amiga  Os 4  was started in 2001,  six years after AROS.
AROS devs had enough time to make a really good and compatible system.

No. Again, what was lacking was the support. Support in the sense of more devs, more users showing an interest, more funding up front (through bounties). All three of which would have made sure AROS progressed faster in the early years. Instead what happened was many people looked at it, said 'it's not useful for me right now', and ignored it (from what I can see). Had the Amiga community at large had better foresight, they would've seen they were missing out on a great opportunity for securing their future.

[bloodline]

HenryCase is right, AROS took the only approach it could take to achieve a viable open source AmigaOS clone, without any budget, regular developers or even support. It was very sensible for the developers to focus on using the most powerful inexpensive hardware and software available at the time, and the results speak for themselves

[Methuselas]

Instead what happened was many people looked at it, said 'it's not useful for me right now', and ignored it (from what I can see).

That's *EXACTLY* what happened. I was the last "hold-out" of my "Amiga Group". I didn't migrate to a PC until 1999 and still supported the Amiga, by buying a new A1200 in 2000 (which, ironically, was sold less than a year later) and then purchasing Amithlon, before the H&P fiasco. I've secretly paid attention to AROS for *WELL* over a decade now and in the beginning, I showed it to most of my old Amiga mates, only to have them scoff at it, as they had already been fully integrated into the Windoze world, due to gaming.

It's hard to support something when you say, "It's not useful for me right now". That's the boat I'm in with MorphOS, OS4 and AROS now. I do too much development in the 3D field that requires a Wintel box. Looking back, sadly, my friends were right...... Then again, I've always been a dreamer. Guess that's why I'm still here, from time to time.

[joska]

Does anyone know? Have the Atari guys figured out how to make an efficient emulator, or are they taking the performance hit?

I actually own and use a Firebee on a daily basis. The CPU compatibility issue is addressed in several ways:

1. The CF68KLib. This handles almost all illegal instructions. It does degrade performance to some extent. Currently it runs 68k applications about 2.5 times faster than my 60Mhz Milan060.
2. A software 68k emulator for better-than-060 compatibility when needed. This is based on the Musashi 68k-emulator and allows individual processes to run in separate emulated 68k CPUs. They share memory space with the real CPU, and all OS-calls are of course run in native mode.
3. The OS is compiled for the ColdFire, no issues there.
4. Binaries are patched (move.b xx,-(sp), LineA...) when launched.

Most *applications* are running fine with the CF68KLib. Some needs to be run under the 68k-emulator, and quite a few does not work at all.

What's interesting is that the apps that don't work often does this for other reasons than the CPU. I don't know how it's like in the Amiga world, but in the Atari world there's a lot of applications that make assumptions about screen layout, sound hardware, RAM etc and when you create a new computer it's hard to get these things perfectly backwards compatible. I have a Falcon, a Falcon with a 040 accelerator and a Milan060 (Atari clone) and the problem is always the same - the previous generation of software doesn't run or run with problems.

The Firebee in it's current state is a "GEM-machine". It runs GEM applications fast and stable, about 90% of the stuff that runs on my Milan060 also runs on my Firebee.

I would love to have a fast machine with a "real" 060. But currently there it no such thing. Even when running 68k code the Firebee is faster than the fastest 060 (which I think is a Falcon with a 100Mhz CT60). And the 060 is not without issues either.

[Iggy]

Thanks joska,
That has to be one of the more interesting posts I've read recently.
I didn't expect the Firebee to perform that well.

Still, you retro fanatics probably ought to stay focused on the FPGA projects. That should have similar performance benefits with possibly better compatibility.

[joska]

Still, you retro fanatics probably ought to stay focused on the FPGA projects. That should have similar performance benefits with possibly better compatibility.

Maybe it's possible to implement a softcore "060" that outperforms a V4E. But currently that seems to be difficult. Also, the V4E does all sorts of stuff that must be replaced if you go for a softcore. E.g. it has a DRAM-controller, ethernet, PCI-controller...

The CPU is only a part of the equation. You need to support all the other legacy hardware too, and maybe even a cycle-exact 68k. If you replace the 68k on a Atari ST or Amiga 500 with a 060 you will still have compatibility problems.

The Coldfire is powerful enough to emulate a 68k in software when you need it. Combine that with implementation of legacy chips in the FPGA and you have a machine that can both be more powerful than a 060/softcore-based AND more compatible.

Don't get me wrong, the Firebee is not perfect. Far from it. Some bad decisions has been made that unfortunately keeps it from being as backwards compatible as it could have been. But the CPU is not the problem.

[matthey]

What's interesting is that the apps that don't work often does this for other reasons than the CPU. I don't know how it's like in the Amiga world, but in the Atari world there's a lot of applications that make assumptions about screen layout, sound hardware, RAM etc and when you create a new computer it's hard to get these things perfectly backwards compatible. I have a Falcon, a Falcon with a 040 accelerator and a Milan060 (Atari clone) and the problem is always the same - the previous generation of software doesn't run or run with problems.

The Amiga has a similar problem. Most application programs, even from AmigaOS 1.x, run fine on a 68060. Games from that time period are a different story. Many do not work. The most common "CPU" problems are much bigger caches and trapping of instructions without the (software) 68060.library installed. The 68060.library installed from flash for bootable floppies and CD-ROMs takes care of the latter but is not common except for 1 68060 accelerator and the Natami 060. The 68060 allows 1/2 the caches to be turned on but that's still too much for many old games. Compatibility of the 68060 with 68020+ is excellent overall. Other misc problems with old software is more common than CPU problems. I think there are fewer timing problems on the Amiga though. There were a few early games that ran way too fast on an accelerated Amiga but that is rarely a problem since AmigaOS 2.x days. C= was telling developers what not to do for future compatibility at that time. I guess some listened. We do have fixed/patched/WHDload games that solve many of the problems with old games.

I would love to have a fast machine with a "real" 060. But currently there it no such thing. Even when running 68k code the Firebee is faster than the fastest 060 (which I think is a Falcon with a 100Mhz CT60). And the 060 is not without issues either.

I wouldn't call the 68060 slow. The v4e ColdFire out clocks the 68060 by enough that it's going to be faster with ColdFire code but the 68060 can still hang with 68k code. The 68060 also benefits a lot with 68060 optimized code. Several instructions are faster per clock on the 68060 not even considering that it can execute 2 or more at a time much of the time. The ColdFire does add instruction combining/fusion and a link stack (for fast bsr/rts) which helps with 68k code. The new ColdFire instructions are useful but don't help with 68k code. The missing instructions and addressing modes are a big handicap with 68k. I would take a Natami 060 (or CT60 if I was into Atari) with 68060@100MHz any day over the CF v4e. I have a CSMK3@75MHz with 50ns SIMMs and 30MB/s sustained HD speed. The 68060 is no slouch and really has very few issues.

Maybe it's possible to implement a softcore "060" that outperforms a V4E. But currently that seems to be difficult. Also, the V4E does all sorts of stuff that must be replaced if you go for a softcore. E.g. it has a DRAM-controller, ethernet, PCI-controller...

The ColdFire's main advantages are built in hardware support and a cheap price.

The CPU is only a part of the equation. You need to support all the other legacy hardware too, and maybe even a cycle-exact 68k. If you replace the 68k on a Atari ST or Amiga 500 with a 060 you will still have compatibility problems.

Nothing faster is going to be cycle-exact. UAE Amiga users don't even use cycle exact. The fpga processors will not be cycle exact. We don't need cycle exact. It really only applies to 1 particular processor and <1% of Amiga software needs it.

The Coldfire is powerful enough to emulate a 68k in software when you need it. Combine that with implementation of legacy chips in the FPGA and you have a machine that can both be more powerful than a 060/softcore-based AND more compatible.

Well, that depends. There are very fast fpgas that could contain a CPU faster than the v4e ColdFire. They are very expensive now but dropping in price quickly. The CF series doesn't look like it's going anywhere. The v5 CF is available in large quantities with whatever bolt-ons are wanted but it's not being marketed. It looks to me like the end of the line as far as CF improving. We can probably leave away the pure 68k software emulation compatibility as the 68060 can do that nearly as well as the CF and UAE on a high end modern processor kicks everybody's ars. Let's compare the v4e CF to the fpga Cyclone IV Apollo core as will be used in the Natami. The CF solution is faster if trapping can be kept to a minimum and much cheaper. The Apollo core will probably be a little faster than the 68060 but has the potential to be much more compatible. It will have bus snooping of the caches for self modifying code and any missing instructions or addressing modes will not be a problem. It looks like the CF has the advantage early on but it should narrow quickly as fpgas become cheaper. A chip could be burnt that includes the fpga CPU, the custom Amiga chips, a 3D core, etc. that would boost the speed to CF v4e speed or above. The price would be expensive unless a large quantity was created. The Apollo core could be used for an Atari project as well. We could go in together to burn an Apollo only CPU or perhaps a chip with Apollo core and custom chips for Amiga and Atari. An fpga solution opens up a lot of possibilities. The 68k softcore was separated from the main Natami project to appeal to more potential customers including the Atari crowd. Here is some preliminary specs on the Apollo soft core:

http://www.apollo-core.com/

Don't get me wrong, the Firebee is not perfect. Far from it. Some bad decisions has been made that unfortunately keeps it from being as backwards compatible as it could have been. But the CPU is not the problem.

Some poor decisions based on marketing were made by the ColdFire designers to remove compatibility with the 68k. The ColdFire is a low end cost reduced 68k processor geared toward embedded systems. Many of the powerful advantages of the 68060 were lost. Several of the CF instruction additions do enhance the 68k in both power and code density and should be included in the Apollo soft core. I hope you pay attention to the Apollo project as it evolves. Even if the next generation Atari crowd stays with the CF CPU, we will have more in common. Not only am I involved with the Apollo project, but I have worked with Frank Wille to add CF optimizations for vasm (improves vbcc code also). It would be nice if some of you Atari CF guys could do some testing . We need better compilers for both projects and we can work together to enhance them. The latest version of the vasm assembler with the most CF enhancements has to be compiled with vbcc. The compiling instructions and source can be found here:

http://sun.hasenbraten.de/vasm/

After compiling a new version of vasm, it can be placed in the vbcc:bin directory where it will then be used by vbbc. Watch those executable sizes shrink . Contact Frank if you have any problems as he has provided great support including for Atari.

[joska]

I think there are fewer timing problems on the Amiga though. There were a few early games that ran way too fast on an accelerated Amiga but that is rarely a problem since AmigaOS 2.x days.

The Amiga had more advanced video and audio hardware than the ST. On the ST there's a lot of software-tricks that depends on a cycle-accurate 68k. So if you want to play ST-games, you need a 8MHz 68000 in many cases.

I wouldn't call the 68060 slow. The v4e ColdFire out clocks the 68060 by enough that it's going to be faster with ColdFire code but the 68060 can still hang with 68k code.

Sure, the 68060 is a good CPU, better than the ColdFire in most aspects. But there hasn't been made a 68060 this millenium. And even with the 68k emulation layer, the V4E outperforms the 060.

The 68060 also benefits a lot with 68060 optimized code.

Well, if you can compile the code for the 060 you can also compile it for the V4E with even higher speeds

Well, that depends. There are very fast fpgas that could contain a CPU faster than the v4e ColdFire. They are very expensive now but dropping in price quickly.

Yes, in the future you can almost certainly get fast enough FPGA's at a reasonable cost. But will we get anywhere if we're always waiting for the next big thing? Today the V4E is the fastest option unless you go for a completely different architecture.

The CF series doesn't look like it's going anywhere.

Absolutely true. The V4E is probably a dead-end. In the future I'm sure that a FPGA based solution would be better.

The Apollo core could be used for an Atari project as well. We could go in together to burn an Apollo only CPU or perhaps a chip with Apollo core and custom chips for Amiga and Atari. An fpga solution opens up a lot of possibilities.

Very true. Basically all you need is a motherboard with a huge FPGA and a load of connectors, and you can implement all sorts of architectures on it. But again, this is the future and not today.

It would be nice if some of you Atari CF guys could do some testing .

I just don't have the time I'm afraid.