FPGA Replay Board

[wawrzon]

Got it.

cool, tg68 is improving, and some conscious involved, have already thought its dead.

[freqmax]

The rumours of the TG68 death is overrated


Wonder what is the best modded-TG68, FPGA-Arcade68, or Natami050? or perhaps more importantly. Which ones that can be merged and make use of the benefits of its ancestors.

[espskog]

So -- how are we doing with a C64 Core ? :-)

[SamuraiCrow]

Wonder what is the best modded-TG68, FPGA-Arcade68, or Natami050? or perhaps more importantly. Which ones that can be merged and make use of the benefits of its ancestors.

I thought the N050/N070 cores were started from scratch and didn't use the TG68 core.

[AJCopland]

I thought the N050/N070 cores were started from scratch and didn't use the TG68 core.

It was from scratch.

[Ral-Clan]

I have a question - may seem naive but please bear with me:

It seems the standard FPGA Arcade running WITHOUT this special daughter 060 daughter card will already nicely behave as an AGA 68020 Amiga (essentially an A1200).

So, wouldn't it be possible for the FPGA (or future versions of the FPGA) just to run the 68020 at multiple times the speed of a regular 68020 to get speeds similar to a 68060?

I say that because in UAE, the instructions suggest that you set your emulated Amiga to 68020 CPU mode (because the 68020 is the CPU that has the best emulation coded for it - 68040/060 emulation still lags behind in development).

Even though the emulated Amiga in UAE is set to 68020, WinUAE can run your "virtual 68020" Amiga as fast as the host computer's processor will allow.  Because of this, an emulated 68020 A1200 can run much faster than an real hardware Amiga with a 68060 accelerator card.

So why not just have a faster 68020 CPU in FPGA rather than adding a real 68060 daughtercard?

[gaula92]

It's a very good question, Ral-clan, and I'd be interesting in hearing a good response, too. Why not a FAST 020 softcore instead of going the physical 060 route? (heat, fake cpu's and hard to find original parts...)
In UAE (FS-UAE in my case) it's the way to go when I want a fast CPU.

[psxphill]

So why not just have a faster 68020 CPU in FPGA rather than adding a real 68060 daughtercard?

The same reason you can't just put a 1ghz crystal in your A1200.

[matthey]

So why not just have a faster 68020 CPU in FPGA rather than adding a real 68060 daughtercard?

The 68020-68060 user mode integer instruction and addressing modes are practically the same. The 68060 and 68040 have MOVE16 but I'm not aware of any compiler that ever used it. The main difference between supporting 68060 and 68020 code involves supervisor mode, the FPU and MMU. The TG68 does not have this support and it would be difficult and time consuming to add. The reason for a real 68060 is:

1) speed
A highly efficient fpga CPU will have a hard time reaching 68060@50MHz performance (not clock speed) in an affordable fpga.

2) compatibility and stability
There is nothing like the real thing for compatibility. The rev 6 68060 is practically bug free.

3) FPU, MMU
There is no fpga 68k CPU that supports an FPU or MMU yet.

[freqmax]

So why not just have a faster 68020 CPU in FPGA rather than adding a real 68060 daughtercard?

The current FPGA Arcade, FPGA chip has a limited logic matrix as it has to handle graphics, sound, disc, memory etc.. too. There's also a limit on the gate to gate latency.

You could use a separate FPGA module as a I have suggested previously. That would give more logic matrix to work with. But leaves the latency issue which can be solved by using a manufacturer that specialize in faster variants.

You can put a 1 GHz crystal in your A1200..but buy a fire extinguisher and a miggy replacement first

[JimDrew]

The 68020-68060 user mode integer instruction and addressing modes are practically the same. The 68060 and 68040 have MOVE16 but I'm not aware of any compiler that ever used it.

There were a couple for the Amiga that did when you turned on the 040 optimizer, and all of us assembly guys used MOVE16 whenever the 040/060 was present.  Also, the Mac OS used it extensively on their 040 based models.

I still think emulating the supervisor/user modes and some other simple added  instructions would go a long ways with the FPGA core to make it 020 compatible.  This is something I am interested in looking at when I get ahold of one of these boards.

[Kesa]

Not sure if it is what you guys are talking about but i remember Thomas(?) mentioning using an ARM chip for the Natami that will allow it to perform multiple instruction sets using the same clock speed*.

*Please don't ask me to explain it - i'm already confused...

[AJCopland]

Not sure if it is what you guys are talking about but i remember Thomas(?) mentioning using an ARM chip for the Natami that will allow it to perform multiple instruction sets using the same clock speed*.

*Please don't ask me to explain it - i'm already confused...

No, there was to be a physical 68060 on a daughterboard.
Any ARM cpu on the board was for configuration loading/setup/whatever-else.

In theory you could run non-Natami configurations on the FPGA with their own softcores, or mount another type of CPU/FPGA on a custom daughterboard. Those were just ideas that were discussed on the forums though, not something Thomas ever showed interest in.

Andy

[mikej]

No, there was to be a physical 68060 on a daughterboard.
Any ARM cpu on the board was for configuration loading/setup/whatever-else.

In theory you could run non-Natami configurations on the FPGA with their own softcores, or mount another type of CPU/FPGA on a custom daughterboard. Those were just ideas that were discussed on the forums though, not something Thomas ever showed interest in.

Andy

And this is exactly how the Replay works. The ARM controller configures the FPGA and handles the SD card in a (becoming) generic way. The CPU of your choice can be mounted on a daughterboard.

[psxphill]

You can put a 1 GHz crystal in your A1200..but buy a fire extinguisher and a miggy replacement first

I doubt it would catch fire, but it won't do what you want. It's likely that it will keep on not doing what you want after you put the 14mhz crystal back. Unless you actually want it to sit there doing nothing, but there are easier ways of achieving that than replacing the crystal.
 
MOVE16 was at least used in some of the CopyMem patches: http://aminet.net/package/util/boot/CopyMem
 
It is theoretically possible to achieve the same compatibility as the real chip, including the FPU and MMU. The speed and size of the FPGA in use will limit the performance. Potentially all the way down to zero if you can't produce a design that fits. Using microcode + a sequencer should allow it to fit, it just won't necessarily be fast enough. There is also the problem that someone has to do it.
 
A sequencer is like a cpu that is designed specifically for doing one task, which is to run the microcode. The microcode is like an emulator that is written for that cpu. As you design both in tandem and can make compromises based on exactly what you need it to do then it works out a lot faster than putting in a general purpose cpu and porting an existing emulator core. But you don't have the luxury of stringing together other peoples work, it's where the glory is though.

[matthey]

There were a couple for the Amiga that did when you turned on the 040 optimizer, and all of us assembly guys used MOVE16 whenever the 040/060 was present.  Also, the Mac OS used it extensively on their 040 based models.

I have looked at a lot of disassembled Amiga 68k code. I have not seen any version of GCC, SAS/C or vbbc generate a MOVE16 instruction. I have not looked at MAC code so perhaps CodeWarrior generated MOVE16. MOVE16 is generally not used in general purpose code because of the alignment restrictions and the fact that the cache is bypassed.

I still think emulating the supervisor/user modes and some other simple added instructions would go a long ways with the FPGA core to make it 020 compatible.  This is something I am interested in looking at when I get ahold of one of these boards.

I haven't seen a list of the instructions supported by the TG68 but I thought it was fairly complete as far as 68020 integer instructions. It has MOVEP and the bitfield instructions which are common on the Amiga. A 68k Macintosh emulator probably needs more support though .

MOVE16 was at least used in some of the CopyMem patches: http://aminet.net/package/util/boot/CopyMem
 

Sure, there are a few patches on the Amiga but MOVE16 is only worthwhile when copying data greater than several kilobytes and the Amiga doesn't copy data that big very often. MOVE16 is barely worth using on a 68k Amiga and I'm the author of CopyMem mentioned above. Linux would be a different story as it copies large amounts of memory and flushing the caches when doing so would likely deteriorate performance.