I didn’t get the Replay board just to run recreations of arcade machines and computers of old, I also wanted to get my feet wet with FPGA programming and the Replay board seemed like a reasonable device to learn with. Unlike a dev-board, it also has a concrete use after I’m done learning about FPGAs.

In this post I’ll cover a few of the differences I encountered over the last few nights as I worked through the earlier chapters of a VHDL book and applied it to the Replay board.

If you’re not looking to learn a few FPGA basics with a replay board and you’ve not run out of sheep to count or sleeping pills, it’s safe to skip this post.

Up until now I’ve enjoyed playing games from my childhood using PC emulators and more recently with RetroPie on a Raspberry Pi.

I don’t recall how I happened upon the FPGA Arcade site but it wasn’t long after reading about it that I’d placed an order with Amedia-Computer France and a board was heading for the shores of the UK. Amedia are currently the only European based distributor.

I dusted off the XGameStation this weekend which has been languishing in the cupboard for quite a few years.

Last time I used it I did manage to get the command line (SASM.exe) assembler running under wine and sxprog handled programming the XGS allowing basic development from within Linux. The IDE however would not work at all in wine. Whilst the IDE is very basic and not something I’d use to code in, it is quite useful for programming and debugging the SX chips.

One option is to run SX-Key IDE in a Windows VM with the SX-Key usb programmer redirected to the VM but working within windows is no longer pleasent having used Linux for so long.

So I gave the windows SX-Key IDE another go in wine.

I finally received the Moonlite focuser from the USA after a bit of a holdup in customs. It really does look like a decent (and heavy) piece of kit. The people who called it a work of art were only slightly exaggerating.

I soldered up a DB9 cable and crimped the 6p6c connector on the other end, plugged it in, booted the Pi and told it to move via the Ekos driver and….. nothing, other than a sinking feeling.

Hardware wise the project is close to completion. The MUP Astro hat now has an enclosure that exposes the PI’s USB sockets with some rubber sealing around the edges/in-between. A 6p6c connector for the focuser, a short serial cable for the autostar handset, dual power input lines via a 6 pin connector and 3x2.5mm output sockets to power the main CCD camera (2.5mm->2.1mm cable), LX90 and dew heater.

The Astro Hat, CCD and LX90 all share the same 12v power line “A” whilst the dew heater has exclusive use of line “B” to limit noise due to its use of PWM.

Before writing a libindi driver for the focuser and temperature hardware I wanted to first test the hardware on its own. For testing the focuser DRV8805 chip I made use of the gpio command line app which provides a way to easily control the PIs GPIO pins.

On the 28th November I setup early for a full night of imaging. Within an hour and a half the scope was assembled, aligned, collimation checked and drift align complete. A couple of minutes later and the CCD and guide camera were attached and I was back indoors with a nice warm drink and focusing the main camera.

That’s when the issues began. At first I thought it was just the Olimex A20 losing its wifi connection. After multiple reboots, adding a wifi extender and trying a better dual antenna wifi adapter, the A20 stopped completely. Not a wifi issue after all.

The MUP Astro Hat PCBs arrived from DirtyPCBs just before the weekend and they look quite nicely done.

I’ve been keeping my expectations that this will actually work in check throughout this project but with PCBs in hand, I was finally starting to believe it just might work.

Reality however had other plans.

The PCB layout is now complete.

As this is the first PCB I’ve laid out and intended to have manufactured, I expect many mistakes to have been made and will be utterly surprised if it works at all, especially the switching power supply.

For a few years now I’ve remote operated my LX90 and associated imaging gear via indilib over wifi using an olimex A20 stored below the scope. With my eye on a zero image shift focuser and a lack of spare ports on the USB hub coupled with an urge to not increase the cables and control boxes even futher, it’s time for a change and a new “hat”.

After poor results trying out Ekos' Polar Alignment helper module the other night I spent a little time looking over the indilib and Ekos source code.

To recap, last session I noticed Ekos was failing to wait for the scope to stop slewing before taking the 2nd polar alignment image resulting in variations of: