First to implement AAA chipset?

[matthey]

There are a few people working on 68k softcores separately and AFAIK they are all adding some extra instructions beyond 68000 and even 68020, but I don't see much point in adding Coldfire support to a system that is going to have its CPU inside the FPGA, unless there is some Amiga software already written that needs certain Coldfire instructions.  Or if adding Coldfire instructions will allow new software to be written more easily than could be done with 680x0 instructions alone.  As for starting a poll to convince the FPGA Arcade inventor of anything, I would say no.  I have not seen anything written by MikeJ that indicates he is limiting the use of the Replay board in any way and anyone can modify what is loaded into the FPGA to do anything they want.  Just don't expect MikeJ to do it for you if you want something different than what he is offering.

Adding Coldfire instructions would allow libraries of Coldfire software (often more modern than 68k code for things like audio or video processing) to be used on the Amiga. Some developers may be attracted to cheap development platforms for Coldfire or even use the whole board for small production imbedded systems or kiosks. These instructions are useful on the Amiga providing a speed up and better code density (especially mvs and mvz). What is the cost to add 99% compatibility with another processor? Just the logic needed to add 7 simple instructions (bitrev, byterev, ff1, mov3q, mvs, mvz, and sats) that are processed in similar ways to existing 68k instructions. The Natami Team has also looked at other simple additions like allowing address registers in EA fields which might not cost any logic, a dbcc.l instruction and bcc instructions using bit 0 of the branch address for longer branches or static branch prediction (my choice), a compression method for long immediate values, etc. I would expect 5-10% better code density, a nice speedup and easier programming. Compilers like vbcc and gcc already have Coldfire support that just needs to be turned on for some benefit. It's easy to be short sighted but if some developer ordered several thousand of an fpga based board because of a little more effort to support more than games, it could help bring the price down for everyone.

The NatAmi team can fit a larger FPGA, true, but their device is already significantly more expensive than the Spartan3e. I believe getting a low cost and mass production is more important at this point.

I think the cost is going to be more important in this economy. The fpga Arcade should easily out sell the Natami. If they were much cheaper or I was much richer, I would buy several as Christmas presents . I will probably buy a Natami and fpga Arcade. I will wait for either the 68060 expansion board or Coldfire support in the fpga processor though.

I used to design 3D graphics hardware. I have a lot of respect for the designers working on NatAmi, but with this FPGA they will do well to match the performance of a 10 year old GPU.

I agree, but this is not so bad. There are some pretty powerful gfx cards that are 10 years old and the AmigaOS doesn't have much overhead when using them. I want gfx support that is well documented and easy to program which I am willing to trade for some speed.

For me, the aim is to get a highly accurate, high performance 68020 grade processor which high resolution, high bit depth screen modes (with a few hardware tricks thrown in).

I'm glad we've moved from the 68000 to the 68020. It's much more powerful and easier to program. It would be better yet with Coldfire instructions .

[freqmax]

Adding Coldfire instructions would allow libraries of Coldfire software (often more modern than 68k code for things like audio or video processing) to be used on the Amiga. Some developers may be attracted to cheap development platforms for Coldfire or even use the whole board for small production imbedded systems or kiosks.

Makes sense!

I agree, but this is not so bad. There are some pretty powerful gfx cards that are 10 years old and the AmigaOS doesn't have much overhead when using them. I want gfx support that is well documented and easy to program which I am willing to trade for some speed.

Less is more, and a slim design might be a value on its own. Especially if one makes a laptop version. Think 10 hour laptop, because the Amiga uses less power than a PC.

One could also ask, what do we really need?, when OCS/ECS/AGA is covered, 99% of the software should work too.

I'm glad we've moved from the 68000 to the 68020. It's much more powerful and easier to program. It would be better yet with Coldfire instructions .

As a bonus the FPGA 68020 isn't limited to 68020 speed. Some previous benchmark shows FPGA-Arcade will beat a A4000T setup.

[amigadave]

Famicon is not an Amiga system.

I think he was asking about an additional core that could be used in the FPGA Arcade Replay Board instead of the MiniMig core, as the intent of the Replay board is to allow re-implementation of many different systems, including Arcade systems.

[Forcie]

Just to clear some things up.

The NatAmi board uses a Cyclone IV EP4CE40 device (currently). This has 39,600 LE (Flop + Logic element) and 1.134 MBit internal memory.

As explained several times before on the Natami forums and elsewhere, the EP4CE40 is only on the first handful of boards Thomas soldered together. This was because the actual FPGA we wanted to use (EP4CE55) was not available at the time and we wanted to start testing systems quickly. However, all new systems (the MX board on my desk here too) are using the EP4CE55 with 55,856 LE and 2,340 MBit memory. Expect it to be filled to the brim with logic...
So your points on affordability are even more valid, since the EP4CE55 is a bit more pricey E

Whats the point in it, when current Amiga graphic cards can out perform it ?

The main point is actually doing things the Amiga way in the design spirit of the original Amiga. While RTG graphics cards might have been a good solution for upgrading a system that never evolved because Commodore just couldn't manage it, they are still just PC graphics chips stuck to your Amiga with duct tape, software supported with ugly hacks.
Now we actually have the chance as hobbyists to rewrite a bit of history and make a proper implementation of truecolor chunky graphics as native Amiga graphics modes as well as extended planar modes. It might not mean much for the user who couldn't care less how his web browser is drawn as long as it is fast, but it sure means a lot for people who enjoy the Amiga design philosophy and want to code for Amiga just like back in the old days. The other day we had planar graphics in SXGA up and running, for example.

This is good news to hear from one of the Natami  Team members!  I hope that you (the team members working on Natami)  will not wait until it is almost ready to release, as I wrote that  releasing it now, or in the near future will have the advantage of  getting some programmers to start coding apps and games that can take  advantage of these newer SAGA features so that there are some SAGA  compatible apps and games written before the Natami is available and  when it is finally released, there will be some SAGA apps and games  available to show off the newer capabilities.

The people who have expressed interest to code for the dev systems are already on the team. If you are interested, join us

Also, though I know that too many cooks can ruin the stew, it might be  good for the Natami Development Team to accept ideas and discussion  regarding adding new SAGA features from talented Amiga developers who  are not on the Natami Dev. Team.  The Natami Team members can choose to  accept or reject any ideas they don't think are feasible, or don't  create significant benefits compared to the amount of work or resources  they require to implement.  Outside developers and hardware technicians  may also provide key information, coding, or ideas that will help the  Natami Team to complete the work on SAGA faster.

This is what the Natami forums have been used for the last few years, in case you missed it (easy to do so among the distracting Thierry rants, perhaps... )

NT

[jj]

Makes sense!
 
 
 
Less is more, and a slim design might be a value on its own. Especially if one makes a laptop version. Think 10 hour laptop, because the Amiga uses less power than a PC.
 
One could also ask, what do we really need?, when OCS/ECS/AGA is covered, 99% of the software should work too.
 
 
 
As a bonus the FPGA 68020 isn't limited to 68020 speed. Some previous benchmark shows FPGA-Arcade will beat a A4000T setup.

Makes sense ??  By that argument add and ARM, PPC and X64 support as well

[michel3105]

I think he was asking about an additional core that could be used in the FPGA Arcade Replay Board instead of the MiniMig core, as the intent of the Replay board is to allow re-implementation of many different systems, including Arcade systems.

Exactly.

Sorry if I didn't express myself clearly. I see that I've used the wrong thread, too; I should have posted in the FPGA one.

[freqmax]

Makes sense ??  By that argument add and ARM, PPC and X64 support as well

It makes sense to increase the number of instructions with ~5% from a overall compatible processor for the benefit of being able to use all the software for an additional architectecture ISA.

ARM, PPC, X64 all requires 100% instruction and design change. Coldfire is likely to not being even near.

[matthey]

It makes sense to increase the number of instructions with ~5% from a overall compatible processor for the benefit of being able to use all the software for an additional architecture ISA.

ARM, PPC, X64 all requires 100% instruction and design change. Coldfire is likely to not being even near.

Agreed. The ColdFire instructions fit as valuable enhancements to the 68k and as encodings within the 68k. The encodings are described here...

http://www.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf

New encodings for the other processors would have to be created and often don't make sense or overlap with current 68k instructions in purpose. There is software that would be able to take advantage of the new functionality right away including vasm (and as a result vbcc) and a new version of ADis disassembler that I'm working on.