FPGA Replay Board

[mikej]

That doesn't sound good.  Were there any changes to these board designs or components from the last working set?

No, and same component supplier. Different batch of ARM chips though.
/Mike

[mikej]

Hope it isn't a faulty batch, or it will be more delays.

I may have been unlucky in the first couple I tested. On one the ARM seems to have died, and the other has a bad power controller. These can both be easily replaced.

Board 3 without the bootloader runs perfectly and passes all tests. I will leave it on soak test and fiddle with the loader. I have identified a few issues with it...
/MikeJ

[mikej]

Good news, the bootloader has been corrected to work reliably now - or at least seems to. The problem was the flash wait state was not set up as the revC errata (1) and these newer chips are a little slower than the original. The main code uses this waitstate so it ran ok.

Some boards have a dead 1.2 supply and this does look like a duff part. At least this is easier to swap.
/MikeJ

[mikej]

Sounds like typical production woes... keep at it Mike!

Thanks Jim. Nothing unexpected - especially with Chinese suppliers. I deal with this sort of thing in my day job, but it's even less fun when it's your own toy.

"* So boards without the new bootloader works out of the box but without the features of said option?"

The revised bootloader code works on both old and new boards. It hasn't been shipped yet as it is part of the new firmware. The change is to correctly set up the internal memory controller as a result of an errata.

"* This new batch of ARM cpus only has slightly slower flashmemory write cycle? not slower flashmemory read accesstime?"

it's still in spec - just the old chips worked with the faster setting. It's only really read that's interesting from the flash in our case

"* Does the dead 1.2 V supply mean that you have to check and replace this on all boards?"
All power rails are checked on each board as part of the test suite. If it's out of spec the regulator is replaced.

"* How is the DDR memory self calibration going?"
Done, works like a charm.

"Whats VNC2?, If I recall it correctly, the ARM cpu is the USB-host and sends this to the FPGA via i/o. I like the everything-on-one-board-solution Perhaps an option would be to handle other USB devices by just forwarding the raw data and let the Amiga side deal with the configuration of endpoints etc."

This ARM cannot be used as a USB host. The VNC2 is an optional module which fits on the board instead of the PS2 connector and provides two USB host ports, and all the software muscle to drive them. It speaks mouse/keyboard SPI back to the FPGA which feeds it into the Amiga core.

"What I would like is to be able to just plug the board via USB ethernet to the local network and run with it, without messing with any pc-2-sd-2-arcade-repeat. Firmware updates would be just a matter of pressing a key. "

You can with the ethernet adapter on the daughterboard.

Firmware updates for the FPGA are as simple as copying the file on the SD card.
For the ARM code you push the menu button while powering on the board, and run an update program on your PC. The two will talk, the ARM flash is reprogrammed and you are good to go.

You can also update the bootloader this way too.
If you mess it up, there is a link on the board to reload a default boot loader.
/MikeJ

[mikej]

You'll almost certainly have to write the code for this too (assuming that it can actually be flashed in place)
 
http://www.ftdichip.com/Products/ICs/VNC2.htm

I have written all the code for the mouse/keyboard bridge already.
The VNC2 can be updated from a USB stick, and I need to add this before release.
Otherwise, you need to use the programmer - there is a connector on the module.

http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=118&title=VNC2-Debug-module
/MikeJ

[mikej]

The VNC2 runs the entire USB stack, the ARM is running the menu system and file IO to the SD card.
/MikeJ

[mikej]

Well because the FPGA i/o goes straight to the PS/2 data+clock is available, one could use them as D+/D- and with the right core you can bang USB right there.

yes, but the electrical levels are wrong - ideally you still need an external phy. The VNC2 is cheap and means reduced software effort.
For high performance the normal USB and Ethernet PHY/MACs hanging off the processor databus are the way forward. It is already running with the USB stack.

Board testing continues, I've replaced a few of the 1.2V regulators without any trouble and the boards work fine.
/MikeJ

[mikej]

Signal levels can be set with FPGA configuration, and if not one can fix that externally. Less electronics than another MCU.
Two 3,3V level signals that forms a differential signal together shouldn't be that hard to accomplish. Ofcourse it won't be 100% to specification but that hasn't hindered Amiga fans before

You need an external pull-up still, and it would not be standards compliant. The VHDL to run the USB would take about 5% of the FPGA, but you would still need an on-board micro to run the USB stack for ps/2 mouse and keyboard.

/MikeJ

[mikej]

The previous answer to game pads was "The current core is very close to the original hardware, so only 9PIN digital.
There are analog inputs on the ARM which can be used in future.
The USB adapter adds keyboard and mouse, and can be extended to all sorts of stuff in future."

Correct - although hubs are supported in the current code.

[mikej]

I expect it will be easier to add support for the USB gamepad specification in the funky programmable 16-bit-USB-stack-on-a-chip than USB networking - it's probably very similar to the keyboard / mouse specification - a collection of button presses and analogue (signed 8-bit?) signals for the joysticks.

yes, very easy at the USB level - just need a new handler for that device and send back the raw data to the fpga with a different header type.
The problem is how to handle it at the FPGA end. Currently, the mouse and keyboard are converted into amiga looking mouse and keyboard, so no driver required. The same could be done for button keyboards etc.
/MikeJ

[mikej]

Well ideally there would be a way of mapping everything, so the analogue sticks could be used as a mouse or digital/analogue joystick. keys/dpad could be used as mouse/joysticks (and obviously keys). Mapping a button to up to make jumping easier etc. But I know that would be a lot of work & I'd rather have the bare minimum than wait ages.
 
I'm not sure how standardised the buttons are on pads, I think all the buttons on ps3 pads are actually analogue. So even though they are HID, you might need to hard code stuff.
 
Even if the dpad was the joystick and every other button is mapped to fire then it would be pretty awesome.

The PS3 controller protocol is pretty well understood, so it could certainly be done without too much trouble. Hopefully somebody will pick it up when the code is pushed out.
/MikeJ

[mikej]

Hi,

Two silly questions/OT..

Is it possible or will it be possible to run Atari ST(E)/falcon core on FPGAA?

What platforms to implement will be available when the FPGAA will be finally released and ready to buy?

//BTW - we're just after great Pixel Heaven party in Poland. You can take a look at some hardware porn from PH.13 here.

Thanks!
K

Yes, the Atari core is the reason I build this board in the first place.
Final parts for production test rig arrived today (should have done this before but ....)
Busy replacing the defective power regulators.
We are working on the new menu system now and tidying up code.
/MikeJ

[mikej]

Is there any chance of Yakubs (sp?) RTG code fitting in the main FPGA even without the daughterboard? Just wondering if we'll have RTG support out of the box as it were.

Andy

Yes, the main board supports RTG. The soft CPU has some compatibility issues so until these are resolved the 68060 on the daughterboard is required.
Hopefully this will be improved.
/MikeJ

[mikej]

That's good to know, any more news on the board bringup itself or it just the usual slog through issues at the moment?

Andy

Looking good, test hardware complete and running. Replaced regs on 10 boards and they are under soak test at the moment.
/MikeJ

[mikej]

What's a soak test?

http://en.wikipedia.org/wiki/Soak_testing

[mikej]

I created the post because the schematic is made up of pictures such that a search is not possible. And scrolling 9 huge images takes time. Re-searching for those datasheets also tend to take its time. I think some of the chips are already EOL so perhaps those datasheets will only be of use to existing FPGA Arcades. Even the critical XC3S1600 FPGA has a "not for new designs" note which just emphasize the importance of chip implementation agnostic HDL-code. Unfortunately this may mean that future version may have to use hard to attach chip packages.. .

None of the chips are EOL, and are now available cheaply in volume, which is not true for newer devices. I'll put a package of datasheets on my website as reference.

The development libraries abstract many of the board details from the core developers. I've started to roll this out to people. The idea is you don't need to know how the clock generator works, you say in the .ini file for your core give me this frequency etc.
/MikeJ