FPGA Replay Board

[freqmax]

I see that more and more people use FPGA-stuff to revive old platforms. Are the cards somewhat compatible, or will complete rewrites be needed?

Provided the number of gates (CLBs etc) that the soft-core requires is less than the available on the particular FPGA it's essentially just a matter of declaring which I/O to use and then route those correctly. A few hours work perhaps. So it's in essence just a reconfiguration issue.

However you need the HDL-sources to be able to "recompile" or synthesize as it's called. HDL-sources will survive time, platforms will not.

[psxphill]

Probably not much. The 14MHz speed would slow some games down to a playable speed but I expect the following would matter more:
 
1) Caches the same as the 68020
2) VBR in original location
3) No fast memory

There are really games on the Amiga that run too quick if you have an EC020 faster than 14mhz? I thought everything was tied to the vertical blank, so the speed only changes depending on whether you're running in 50hz or 60hz.

[matthey]

There are really games on the Amiga that run too quick if you have an EC020 faster than 14mhz? I thought everything was tied to the vertical blank, so the speed only changes depending on whether you're running in 50hz or 60hz.

Yes, there are Amiga games that run much too fast although most are old games for the 68000 and early AmigaOS. Sometimes timing problems are because of bugs like failing to call graphics.library WaitBlit correctly.

[gaula92]

Now, I know it's a one man project (with some help from other core developers), but I'm socked to see we're in the same place we were more than a year ago: no way to buy the board (I have mine, but I mean mass production) and outdated core with a lot of compatibility problems.

I'm starting to fear this isn't going anywhere. It seems to be the same with most FPGA implementations, and it's sad because it's the best alternative for Amiga hardware nowadays: no aging hardware and classic amiga compatibility.

So far:

-Natami never got past some prototype boards distributed among the developers. Supposedly cancelled or in an undetermined suspension state. Used TG68 softcore.

-MCC-216: Can be bought, but it's a scam, using outdated Minimig core with it's sources closed. It's compatible with something near 40% of Amiga 500-era software. Materials are awfull and aesthetically it's horrible. Avoidable device at all cost. It's developers have been promising a closed-source 68K implementation to make it more compatible, since...2010. Yeah. It's sure to happen next century.

-Turbo Chameleon64: has a good Minimig port, thanks to the efforts of MMrobinsonb5, but it's still having a lot of compatibility issues due to the TG68 implementation.

-The original Minimig 1.1 board, designed by Dennis van Weeren and mass-produced by Acube Systems, is the best Amiga I ever had, even if it's limited in so many ways as having "only" 4MB of RAM. Real 68K on-board guarantees an almost perfect compatibility rate. Clear winner here, thanks again to the extra work by Yaqube, Boing4000 and MMrobinsonb5 towards a perfect custom chipset implementation.

Now, if we analyze the situation, I'd say the main problem here (and what must have caused the hiatus in development of FPGA Amigas) seems to be the 68K implementation. TG68, even if it seems to be a good open source alternative, seems to prevent further compatibility improvements in the systems that use it. I believe it's not developed any longer because it's creator, Tobiflexx, is currently enjoying more important matters in real life  

So, if I'm right, we're not seeing any new, more compatible core on the FPGA Arcade in a long time. Could developers please confirm this? There's nothing wrong with it: I can't start to imagine how complex a 68K softcore implementation must be!

thanks

[Darrin]

-MCC-216: Can be bought, but it's a scam, using outdated Minimig core with it's sources closed. It's compatible with something near 40% of Amiga 500-era software. Materials are awfull and aesthetically it's horrible. Avoidable device at all cost. It's developers have been promising a closed-source 68K implementation to make it more compatible, since...2010. Yeah. It's sure to happen next century.

This explains why I don't see any reviews of it.  I wasn't even sure that it was an actual product despite seeing it advertised.

-Turbo Chameleon64: has a good Minimig port, thanks to the efforts of MMrobinsonb5, but it's still having a lot of compatibility issues due to the TG68 implementation.

I hope we'll see it able to access the joystick ports of the C64 host as some point.  I don't have the extender board and I don't want to keep unplugging it from the back of my C64C.  I use the IR CDTV remote control as a joystick.

-The original Minimig 1.1 board, designed by Dennis van Weeren and mass-produced by Acube Systems, is the best Amiga I ever had, even if it's limited in so many ways as having "only" 4MB of RAM. Real 68K on-board guarantees an almost perfect compatibility rate. Clear winner here, thanks again to the extra work by Yaqube, Boing4000 and MMrobinsonb5 towards a perfect custom chipset implementation.

As an OCS/ECS gaming machine it is fantastic and the turbo charged real processor does zip along nicely.

If the soft CPU is going to be an issue for the FPGA Arcade then pehaps a basic expansion board just containing a real 68020/68030 CPU might be a better solution for gamers who do not want the full 68060 daughterboard with all of the bells and whistles.

It will be interesting to see how the new core performs when it is released.

[bbond007]

-The original Minimig 1.1 board, designed by Dennis van Weeren and mass-produced by Acube Systems, is the best Amiga I ever had, even if it's limited in so many ways as having "only" 4MB of RAM. Real 68K on-board guarantees an almost perfect compatibility rate. Clear winner here, thanks again to the extra work by Yaqube, Boing4000 and MMrobinsonb5 towards a perfect custom chipset implementation.  

I know when I got my 4MB Minimig 1.1 it was not so great..

I found only about 50% of the .ADFs worked, the filesystem was limited to FAT16 and 8 character file names, there was no HDF support. With the addition of the ARM controller and updates it progressed into the impressive little machine that it is today...

Just saying that the 1.1 was not that great for the first few years either.

...

[freqmax]

What has X client/server to do with this??

[mikej]

So, if I'm right, we're not seeing any new, more compatible core on the FPGA Arcade in a long time. Could developers please confirm this? There's nothing wrong with it: I can't start to imagine how complex a 68K softcore implementation must be!

Hi,
Sorry for the late response, I have been travelling. In fact, I have just left the factory where more boards are being made. Yes, it is taking much longer than I wanted - I have been a little busy with some other work projects sadly.
This design is FCC/CE certified. It is produced in a factory where they can knock them out by the 10,000. The firmware is relatively stable and a new release is imminent.

Several other cores are already running on the board. As I do not take pre-orders and am using my own cash to fund this, I need to do it as/when I can afford. I need to be 100% sure there are no problems with the board before I make a large number hence the staggered beta program.

The CPU core is not a big issue, I can fix the remaining issues with it quite quickly. I also have my own 68K core which is moving along slowly.

/Mike

[psxphill]

Yes, there are Amiga games that run much too fast although most are old games for the 68000 and early AmigaOS. Sometimes timing problems are because of bugs like failing to call graphics.library WaitBlit correctly.

I know about the problems some 68000 games had. That is why having a cycle accurate 68000 is useful.
 
My question was related to games that run fine on an a1200, but would fail if the instructions per second was higher (whether that's due to higher clock speed or more efficient instructions).

[ChaosLord]

There are really games on the Amiga that run too quick if you have an EC020 faster than 14mhz? I thought everything was tied to the vertical blank, so the speed only changes depending on whether you're running in 50hz or 60hz.

All properly coded games are tied to the vertical blank.  Not just on Amiga but all other systems too.

Any game that fails to run on a faster CPU has a tragically awful bug.

If a game uses software timing loops then there is no way for us to fix that at the hardware level.  You would need to disassemble the buggy code and fix it.  a zillion hours of work for each game. Yuck.

If a game forgets to call WaitBlit() then there is no way for us to fix that at the hardware level.  You would need to disassemble the buggy code and fix it.  a zillion hours of work for each game. Yuck.

I actually committed the above bug once.  It was just purely by accident that it happened during a code rewrite.  But a playtester reported it to me and I declared an emergency and fixed it immediately.  So the public never saw the bug.


If a game bangs on hardware registers too quickly on fast CPUs then... AHA!
There is a sneaky way to fix that.  Just make the Amiga's hardware registers respond faster and then everything will work great!

This banging regs to fast problem happens a lot when banging Paula.  It isn't like its intuitive to know that you hafta wait a certain amount of time between pokes.  Its a really annoying problem.

It has plagued the Amiga continuously since the beginning of time.

I remember when the 030 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

I remember when the 040 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

I remember when the 060 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

So anyway whoever is working on the Paula softcore, all you hafta do is rig it so that code will work, even if the code "pokes to fast".

If you can implement that then dozens of programs will suddenly start working on faster systems.

[Methanoid]

Several other cores are already running on the board.

/Mike

Mike, we try not to pester but can you please tell us what other cores are running (and presumably will become available when the board goes properly into production)? I know I'd love an ST core as well as the Amiga one but more cores make the board of more use.

[ChaosLord]

@MikeJ

Is the FPGA chip in the FPGA Replay fast enough to generate a 1280x1024x32bit @ 60fps display?

Does it already do that?
Or is it something you could try to squeeze in with some hardcore optimized code magic?

Such a mode would burn 314MB per second of bandwidth just to show the display.

What is the theoretical maximum bandwidth of your memory chips?

How much actual bandwidth are you actually able to get out of the system so far?

I realize that the "theoretical maximum" and the "real life attainable" numbers will be wildly different, as they are with Natami.

I am asking these questions because I want to write a game that maxes out your hardware.  And I think that I will be stuck using 640x512x32-bit mode.

[Lord Aga]

Why 32 bit ? Isn't 24 more than enough ?
Just curious... I don't plan on going above 16 bit with my petty programming

[ChaosLord]

Why 32 bit ? Isn't 24 more than enough ?
Just curious... I don't plan on going above 16 bit with my petty programming

Visually 24 is just as good as 32 since they are the exact same thing visually.

But the cpu processes 32-bits much more easily than 24.  Sometimes some gfx need to be drawn by the cpu (calculated fx).

[gaula92]

I'm all for an ST core, too. Ahh.. taking my long-waiting FPGA board and have some ST fun while the stable Amiga AGA core is released would be great! Well, if it's Atari 8 bit stuff and it runs Alternate Reality, I won't be complaining either ...

[yaqube]

Is the FPGA chip in the FPGA Replay fast enough to generate a 1280x1024x32bit @ 60fps display?

Yes, the FPGA is capable of it. Moreover the memory bandwidth is more than enough to display such resolution.

Does it already do that?

Currently Minimig AGA core with RTG module (Picasso96 compatible drivers are available) can display resolutions up to 1920x1080 but only in 8-bit colour depth. Maximum resolution in 32-bit mode is 800x600.

Or is it something you could try to squeeze in with some hardcore optimized code magic?

There are plans to improve memory controller to allow more bandwidth and more colours in higher resolutions - current limitation is a consequence of original Amiga Chip RAM design (the RTG module fetches its display data from Chip RAM).

What is the theoretical maximum bandwidth of your memory chips?

166MHz x 2 x 16 bits = 666MB/s

How much actual bandwidth are you actually able to get out of the system so far?

My design has two independent logical memory channels to SDRAM each capable of 113 MB/s. One channel is used by the custom chips, CPU, AHI DMA sound channels and RTG board blitter. The second channel is dedicated to memory refresh and RTG display.

I am asking these questions because I want to write a game that maxes out your hardware.  And I think that I will be stuck using 640x512x32-bit mode.

Such resolution is problematic with VGA monitors. But my RTG module supports scan doubling to upscale 640x512 to 1280x1024 which is SXGA native resolution.