First to implement AAA chipset?

[matthey]

The Natami SAGA should be a more AGA compatible version of what AAA would have been. Modern hardware and fpga's make AAA performance possible without the trade-offs. Most AAA features are in SAGA. The Dave Haynie thread talked about the similarities of AAA and SAGA. Dave likes the Natami idea better than most of the other NG Amigas.

[matthey]

What thread?

http://www.amiga.org/forums/showthread.php?p=631463#post631463

[matthey]

For pure performance and compabiltity maybe it's better to plainly extend OCS/ECS/AGA modes with higher capabilities? HAM64? or planar/chunky-24, more sprites etc.

That's what the Natami is about! Use the old ideas and scale up to todays technology where practical. Example AAA like SAGA support...

Much faster and bigger gfx memory: Gfx memory will operate at the same speed as fast memory which is faster than any classic Amiga. 256MB means you won't run out until the Natami gets 3D .

Much faster blitter: The Blitter is used for 2D gfx and blitter objects (bobs) on the Amiga which should be much faster and allow virtually unlimited movement onscreen at typical Amiga resolutions.

Fast chunky modes: The Natami should support 16 and 32 and maybe 24 and 8. These allow read and write operations with 1 fast memory access. Very common on other platforms.

HAM modes: HAM64, really? The Natami will support HAM6 and HAM8. The team looked at adding HAM10 which would visually look nearly 24 bit while only using 10 bits per pixel. However, it's not an easy format to work with and bitmap structures only have room for 8 planes of data. Dithered 16 bit looks good enough, saves bandwidth and memory, and is much easier to work with.

3x8 byte mode: Gunnar likes this mode as it gives more colors for the bandwidth. Storing each color component separately has it's advantages but is generally more difficult to work with than chunky. It may be more useful separated as HSV than RGB.

Sprites: Sprites are much the same as AGA with less restrictions (i.e. palette). Adding more sprites or colors steals bandwidth when the blitter (bobs) is much more flexible and the Amiga way.

Planar+Chunky/Dual playfield: The Natami should allow planar gfx overlayed over chunky gfx for some interesting effects. Higher colors should be supported in dual playfield mode.

HSV/YCbCr: It's not been decided but some kind of mode(s) for video (mpeg) will probably be supported. Perhaps this will be allowed as an overlay (PIP) like PC gfx cards.

[matthey]

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.

SamuraiCrow is also a Natami Team member. I agree with you about creating a SAGA standard that any fpga can use. I think there should be an enhanced 68k standard that at least adds ColdFire support. These few useful instructions are already supported in some assemblers, compilers, etc. and only need to be enabled. We came up with a few other instructions that would also be great potential 68k enhancements. I think the fpga Arcade folks see their machine as more for retro game enthusiasts that would not want such enhancements but rather maximum compatibility. I think they are wrong. I think it's possible to have excellent compatibility and the enhancements. How do we convince them? Start a poll?

"Would you like SAGA enhancements in the fpga Arcade?"
"Would you like 68k CPU enhancements in the fpga Arcade?"
"Both please!"
"Neither, I only play retro games and demand exact emulation."
"I don't care and won't be buying an fpga Arcade."
"Pancakes!"

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.

The Natami Team has been very open to suggestions on their web site and have received some very good ones from some very talented Amiga programmers. The Team is very busy right now so don't expect a huge response at the moment.

[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 .

[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.