FPGA Replay Board

[AJCopland]

Sorry guys, appreciate the patience. I have had some hassle with the day job, but still moving forward....

Don't worry, it's not a complaint
I spent all day almost gnawing my hands off in frustration that I couldn't get home and hack on one of my "spare time" projects so I understand.

[gaula92]

I'm home in 4 days and then off for a week (moving house, so not really relaxing).  Any chance of the core update then?

C'mon, MikeJ! Give this young recruit something to play with! He always tells you when he's going home. You'll make him very happy!

[Darrin]

C'mon, MikeJ! Give this young recruit something to play with! He always tells you when he's going home. You'll make him very happy!

LOL.  I think he never sends it to me because my wife is paying him not to.

[freqmax]

@Darrin, Conspiracy! *drums*
(from the Wifeminati)


Does the USB handler in the FPGA Arcade handle USB Ethernet adapters good enough to present an API that assembler code on the 68k side can make use of to establish TCP/IP connections?

[mikej]

@Darrin, Conspiracy! *drums*
(from the Wifeminati)


Does the USB handler in the FPGA Arcade handle USB Ethernet adapters good enough to present an API that assembler code on the 68k side can make use of to establish TCP/IP connections?

Not really no, the VNC2 is directly connected to a low level handler in the FPGA which converts it into keyboard/mouse protocol. It could be extended of course. Remember there is a real ethernet / usb chip on the daughterboard.

In other news testing is ongoing. The batch look to be assembled well, few minor things to correct but nothing major. However the boot loader just does not run on the ARM at all, it is very odd. My first though was the chips were fake, but the internal ID code matches the device marking. Debug is ongoing.
/MikeJ

[Darrin]

In other news testing is ongoing. The batch look to be assembled well, few minor things to correct but nothing major. However the boot loader just does not run on the ARM at all, it is very odd. My first though was the chips were fake, but the internal ID code matches the device marking. Debug is ongoing.
/MikeJ

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

[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

[Darrin]

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

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

[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

[Johan Samuelsson]

Yes yes!!

[ChaosLord]

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

[BusinessManagerMode]

So you must spend 1 hour of labor testing every single board that works perfectly?

And you must spend 6 hours of labor testing every single board that does not work perfectly?

And I assume you have a 10% failure rate?

Or do u have one of those C64 30% failure rates?


Learning these types of things from my own experience is very stressful to me.  But learning these types of things from your experience is fun, relaxing and enjoyable.

When I used to buy floppy disks, I always had a 2% failure rate or higher.  Crappy disks would be a 5% failure rate.   Once I had a box of disks with something like a 50% failure rate.

With DVDs I always had around a 20% failure rate, which was really annoying.  But once they burned, they lasted forever and never failed.

My hard drive failure rate is uhmmm... I never ever ever had a hard drive fail on me, no matter how old it was or how much I grinded the head.  Except one drive: A Western Digital Green drive 1.5TB which was used in an external BlacX thingy.  So it spent most of its life OFF.   It was on for a few hundred hours of very mild use then just gave the CLICK OF DEATH and died.

When I sold C64's we always had a very high failure rate of 20% to 30%.  I think that was in 1983.  I sold hundreds of them and testing all those returns was really annoying to me.  Yikerz.

[Coolhand]

My hard drive failure rate is uhmmm... I never ever ever had a hard drive fail on me, no matter how old it was or how much I grinded the head.  Except one drive: A Western Digital Green drive 1.5TB which was used in an external BlacX thingy.  So it spent most of its life OFF.   It was on for a few hundred hours of very mild use then just gave the CLICK OF DEATH and died.

funny, only drive i've ever lost is a WD green 500gb, infact I got it working again -accidentally- by smearing some thermal compound on the logic board - maybe it fixed a dodgy via or cold solder joint.

I wouldn't recommend people do this however:D but if there's stuff you need off it, then a replacement logic board might be worth a try.

[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

[freqmax]

* So boards without the new bootloader works out of the box but without the  features of said option?
 * This new batch of ARM cpus only has slightly slower flashmemory write cycle? not slower flashmemory read accesstime?
 * Does the dead 1.2 V supply mean that you have to check and replace this on all boards?
 * How is the DDR memory self calibration going?

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.

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.

[JimDrew]

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

[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