FPGA Replay Board

[mikej]

Yes they do, just not releasable yet. I've had the ST/BBC B and most of the arcade games running on it. The ARM software is completely re-written now.

1000 is still small numbers, Xilinx etc will not deal with you directly unless you are much bigger than that.
/MikeJ

[mikej]

Some good news. All the components are in place now and I'm paying the bill.
The last parts should join the PCBs within two weeks, and I am hoping they can get them built before the China spring festival holiday. I should get boards by end Feb.

This is a big step forward as I can now remotely order and build as many as I want. This will also mean the daughterboard can go directly into volume production.
/MikeJ

[mikej]

The main part of the Amiga core is Minimig derived, but rapidly diverging.
I have had some contact with Boing4000 and will incorporate any fixes which are common.
/Mike

[mikej]

The main part of the Amiga core is Minimig derived, but rapidly diverging.
I have had some contact with Boing4000 and will incorporate any fixes which are common.
/Mike

I've merged in the latest changes (mainly audio fix) and I'll ship a board of to Boing4000 for development.
/MikeJ

[mikej]

In audio.v
Changelog:
"//              Silences audio channel when replen is 1 - fix for Gods jump noise."
I haven't verified the fault or fix yet. The link to the code is posted slightly earlier in this thread.
I'm going to send you a complete WIP snapshot as soon as it is stable.
Cheers,
Mike

[mikej]

The problem was that, in GODS, certain sound effects left a high pitch sound playing after they finished. It also happened in other games.
MMrobinsonb5 from http://www.retroramblings.net fixed it. It was supposed to be a temporal fix until a better sigma-delta filter was implemented.
More on it here:

http://minimig.net/viewtopic.php?f=7&t=516

It's a long thread, but the last pages have very good information on the problem.

Thanks for that, very useful.
The Replay core may not suffer this problem, we have a 24bit DAC hanging off the FPGA. If the error is a result of the delta-sigma converter then I won't see it.
I'll run some simulations and see if the silence change is necessary.
Boing can run some tests on the Replay core when he gets the board.
Best,
Mike

[mikej]

I really hope so...

[mikej]

In a word yes.
I need to sync up with Jakub exactly how we merge our code together.

Lots of boards are arriving shortly - they are being assembled now but the big China holiday is close which could mean a delay to end Feb.

I have new bootloader for the ARM SW which lets you re-flash over USB - holding the menu button when powering on puts it in this mode.

For the cores they are just files on the SD card. For development I use a download cable connected to the JTAG header. The ARM will re-init the board and file system if the chip is reprogrammed, so I can build and test very rapidly now without taking the SD card out.

Most of the IO is new and generic, including the full colour OSD, audio/video interfaces and PS2 (which is now controlled by a tiny soft micro-controller).

I am also modifying the menu system so firmware options are loaded from an ini file - this is necessary for multi-platform support (and the Atari ST is next)....

Finally I have a USB adapter which is soldered on in place of the PS2 connector. This has a VNC2 chip and adds one internal and one external USB port. Hubs, mouse and keyboard are currently supported. This is working on the dev board and the real PCB should be here tomorrow.

/MikeJ

[mikej]

Does this mean that if you saved anything on a virtual .ADF floppy on the flashcard those contents will be lost at re-init?

No, nothing lost!

[mikej]

Is it possible for my beta board to get the hardware updates aswell ?

//Espen

Yes - but removing the PS2 connector is a bit tough. If you have a good soldering iron you can try cutting the connector off then pulling each pin out in turn.
Or, you can return the board to me for this update.
/MikeJ

[mikej]

Has there been any damage or failures when connecting or disconnecting devices when the FPGA Arcade is powered?

No, the PS2 ports have a resistor between the FPGA and the connector which limits the current. This is a necessary to get 5V toll (sort of), but has the side affect of protecting the FPGA a bit. There are protection diodes on the video interfaces as well.

[mikej]

Or use solder tin sucker for removing the solder :-)

Possible, but it's a six layer board and it's tricky to get it hot enough.
I cut the pins, remove each one in turn by heating the pin and pulling it with pliers, then when cleaning the hole up with solder wick.
/Mike

[mikej]

yaqube, when do you expect the daughterboard to go into production?

March.

[mikej]

I haven't been able to find any prices on this.  From the estimates I have seen online, it's going to be a lot more expensive than a regular MiniMig, right?

The price I saw somewhere was something like 600 Euro, is that correct?  That would work out to over $800 CAD for me.  Yikes!

The aim is just to recover the costs. The base board without svhs/composite target is 199Euro + VAT. I need to do the maths of the final production cost and tax / exchange rates, but it's looking promising. As volume increases the price will come down a little.

The daughterboard (sans processor) is going to be cheaper, but I don't have production pricing yet as the spec is still slightly up in the air.
/MikeJ

[mikej]

@ChaosLord:

Result of BusTest on the FPGA Arcade base board with original firmware (not the new one) :
Commande 'BusTest fast chip rom'
BusSpeedTest 0.19 (mlelstv)   Buffer:     262144 Bytes, Alignment: 32768
========================================================================
memtype   addr       op         cycle     calib         bandwidth
fast      $01138000  readw     350.6 ns   normal       5.7 * 10^6 byte/s
fast      $01138000  readl     523.8 ns   normal       7.6 * 10^6 byte/s
fast      $01138000  readm     421.8 ns   normal       9.5 * 10^6 byte/s
fast      $01138000  writew    350.4 ns   normal       5.7 * 10^6 byte/s
fast      $01138000  writel    520.4 ns   normal       7.7 * 10^6 byte/s
fast      $01138000  writem    424.7 ns   normal       9.4 * 10^6 byte/s
chip      $000B8000  readw     350.6 ns   normal       5.7 * 10^6 byte/s
chip      $000B8000  readl     524.1 ns   normal       7.6 * 10^6 byte/s
chip      $000B8000  readm     421.8 ns   normal       9.5 * 10^6 byte/s
chip      $000B8000  writew    350.1 ns   normal       5.7 * 10^6 byte/s
chip      $000B8000  writel    520.7 ns   normal       7.7 * 10^6 byte/s
chip      $000B8000  writem    424.7 ns   normal       9.4 * 10^6 byte/s
rom       $00F80000  readw     350.3 ns   normal       5.7 * 10^6 byte/s
rom       $00F80000  readl     524.1 ns   normal       7.6 * 10^6 byte/s
rom       $00F80000  readm     421.7 ns   normal       9.5 * 10^6 byte/s

Workbench 3.1 and PAL HiRes Interlaced 640x512 256 Colors installed on a 999MB HDF File used for test.

Kickstart 3.1 and Chipset AGA, 68020 at 50MHz, 2MB Chip and 59MB Fast ram, 4 floppy drives activated.

For Alien Breed 3D 2 aga, it's playable at 50MHz speed (like on a real 030/25MHz Amiga), it's smooth at 99MHz.

Thanks, Faranheit

The old core does not have cache/pre-fetch running as is not using the dedicated memory channel for RTG. It will be slow ....

[mikej]

Although there is only one physical DRAM interface, the current core uses it as a single random access memory. As long as the address(es) are in a separate physical bank inside the memory it is possible to effectively do several reads at the same time. So, for the display controller it can bust read memory at the same time as the CPU without impacting its performance.

A clever memory controller will automatically open as many banks as possible at the same time, so by careful address mapping of chip / fast regions we could speed things up.
/MikeJ