FPGA Replay Board

[mikej]

I am waiting for the replacement LDOs to arrive to verify the problem with power off has been fixed. They got delayed by the Christmas holidays, but I should have them Monday. I'll then ship the board to Yacube.

I have been working to improve timing and area in the design so the compile time is reduced.

Trust me, we are not hanging around here...
/Mike

[mikej]

It's 6 layers and you can get the size from the drawing on the website.

I'm not prepared to discuss component pricing as the board is not available (and no use) on it's own - you can't self assemble this.  

It's pretty tough to hit the price point I am offering it for in these volumes. When the manufacture moves completely to China it will be a little less.
Mike

[mikej]

Sure,
The PCB company I use is called Shenzhen Gold Sky
http://www.gsspcb.com/en/

My contact is called Lily, who is great.
The price depends a lot on volume and the design, so send them the manufacturing data and get a quote. The NRE is quite high so you need to be looking at 50+ to make the overall price good, then it gets quite cheap.
Best,
Mike

[mikej]

If I recall correctly, the Replay board has DVI output which the Apple Display should like. Anyway, I think I will buy something else which does not cost a zillion extra for the apple logo

Espen

Yes it has DVI out (which can be used with a HDMI TV input), analogue out (on the DVI connector) and sVHS/composite.
/Mike

[mikej]

If the board is displaying standard ntsc/pal on the DVI out then the sVHS/Comp can be enabled as well. For HD modes these outputs are disabled.
/Mike

[mikej]

DVI just bashes pixels to the screen (at 50Hz or 60Hz in this case).
Most computer screens will not accept the 50Hz vertical refresh rate.
However, if you plug the DVI into a HDMI input, the screen will work at 50Hz P or I (interlaced).

The Amiga core chucks out 50i or 60i which can be scan doubled to 50p or 60p.

The board is generic and my boot loader is a facelifted. The Amiga port is currently being worked on by Jakub as is based on the Minimig ARM code.

We will hopefully see some convergence of the code.
/Mike

[mikej]

Depends what the core does. The hardware has filters to limit the video bandwidth to an appropriate level for the interface.  I have the board connected to my 50" Plasma at the moment, running at both 625i and 625P

LCD TVs will look sharp at their native resolution and fuzzy at other resolutions, depending on the quality of their sizing engine. The Amiga core outputs at native resolution, so no filtering is possible. If it is scan doubling then some vertical filtering is required.

What may be possible is to run the output at 1280x720 say and scale the original picture into that window with decent filtering.

/MikeJ

[mikej]

They don't all fit!
The thinking was, if the board is in an ITX case then you have a power supply with a switch in the case. You connect to either the molex or 2 pin header and leave the on-board switch on all the time.

If it is sitting in a custom case then the switch pokes out the back.
/Mike

[mikej]

I just posted this status update :

  I'm still testing the boards. I've had a few issues which have taken quite a lot of time to sort out.  I'm waiting for the replacement regulators still, but I have a minor patch for the board which fixes the power off issue.

  The audio is up and running at 24 bit 192  KHz. I had a whole load of problems getting this to work, but it turned out to be a constraint  problem inside the FPGA. The signal quality and noise level look very good.

  The composite video output has also given me a lot of trouble. I have spent a lot of time making a good video timing generator and adding  in all the equalisation and synchronisation  pulses you need for "correct" PAL/NTSC. Still no picture. I found a minor problem with the output resistors, but  this is easily patched on the boards I have produced already. Still no joy. It turns out the video input on my LG screen is not working for some reason (and the screen is quite new).
 
The sVHS and video outputs work fine on my Plasma TV. The sVHS output looks quite ok, the composite doesn't look great but that's due to the limitations of the format.  I'll run some multiburst test patterns through it tomorrow to check the luma trap is correct.

  The main RGB video outputs and the DVI/HDMI digital output look great. The only thing remaining is the stress testing of the DRAM. I've re-written the  memory controller and added production tests so I can measure the operating margin. It looks like I have a few bugs still but I hope to finish off the testing this week.

Amiga specific stuff:

I haven't got Jakub's AGA core up and running yet. I suspect there is something different with the DRAM and I am focusing on my own board tests to sign off the hardware. I've started to re-write the Minimig core and tidy it up with Jakubs support into a VHDL version which will be easier to maintain. The 10 boards I have had produced I'll patch the svhs out on (it's a minor mod on the back of the board). I've already updated the PCB layout for a B2 board which just has the fixes for production as it's expensive to get mods done on lots of boards. The B1 and B2 boards are functionally identical.

/Mike

[mikej]

Ah Alexh, good to hear from you, you are alive still then.

As far as I am aware all the other boards running the MiniMIG core have just updated the IO and used the code as is. The MCC project (french-shark I believe on this board) has added an SDRAM controller and is using Tobias' soft core. However, he has not made the source code available, so he is not contributing anything back.

Jakub has done really well adding a lot of support for AGA and bug fixes, but the code does need a re-write to improve area and timing. Jakub and I both feel happier in VHDL so that's what I'm doing. It's a step by step process optimizing one model at a time for now. You can mix and match Verilog and VHDL. Overtime the interface between the chips will change, but the top level will still be able to be used with the original MiniMIG board at least, assuming it fits.

There is nothing to stop people taking the new code and porting it to other platforms, although it is only the C-One and MCC with FPGAs big enough for the soft-core which can run the AGA version.

Both of these are essentially closed source commercial projects, and if they do take our code they will need to push back their adaptations and improvements back under the license agreement.

/Mike

[mikej]

One other thing.
The Replay board has a set of standad IO modules to talk to the ARM CPU, input devices, DRAM, audio and video etc. One of the reasons  to modify and modernize the Amiga softcore so it can use my blocks.

This results in a design which is actually a bit easier to port to other hardware.
These blocks are also used by the other softcores making it a lot easier to get new stuff up and running.

Mike

[mikej]

Do you have some info on whether there is or will be a compatible C64 core that can read/write the SDCard ?
 
Espen

Yes, I have a working C64 core but not an accurate SID at the moment.
Work is on-going reverse engineering the analog part of the chip at the moment (see visual6502.org for details of how it is done)

[mikej]

The big advantage for me is the powerful simulation environment and the easy I can create records and complex data type to pass info around. You can do this all in Verilog, but it is a bit low level for me.

For example, in my Amiga video timing generator file is a bit longer, but easier to read, understand and maintain - in my opinion.
/Mike

[mikej]

yes, but last time I checked the c-one was bound up in some stupid non-disclosure deal which meant the source code (even though it is based on FPGA-64) cannot be distributed.

http://www.syntiac.com/fpga64.html

Daft.

So, we'll write our own SID and release it with an open license for the Replay board.

SID die shots:
http://mail.lipsia.de/~enigma/neu/6581.html
http://oms.wmhost.com/misc/

I'll be checking the binaries for other boards to see if any of our code is used....
/Mike

[mikej]

ARGH! Please tell me you don't use record types on entity ports?

Next you'll be using arrays of records of enumerated types (guaranteed to feck up almost any FPGA synthesis tool!)

sometimes, although I try and minimize it.
The synthesis tools are pretty good at it now, only get problems occasionally with overloaded functions dealing with complex record types ....
You should see what we get up to in the ASICs..
/Mike