May the 4th be with you

Forgive me it has been six months since my last posting, I have been a little busy.

Project Hermes is still in development but has progressed nicely. I started my review work on the design back in March 2016 and made a few tweaks to the design. The review schematics are  here: Hermes_development. One of the principal design requirements was to make it work within the CD32 power/space/performance envelope. One are the design was struggling with a little was power. Most of the anticipated power consumption was in the 5V to 3.3V converters for all the new logic and 2xCPLDs. One evening, with some help from Ti’s WEBBENCH(R), I had a solution that nearly halved the power consumption of the card. The BOM and schematics were updated accordingly.

When you look at the circuit on page 3 (which is not sexy), you may wonder why that was a few hours work. Component selection, simulations, schematic and BOM updates take time but the task is now done. This is one of many little tasks to complete.

The biggest challenge has and still is the programmable logic. I have a preliminary design which needs a test bench to prove it. I have ‘re-used’ some concepts from other projects but very little code. A few designs I looked at for the 6800/68020 processor bus used asynchronous logic. Whilst this will work, it does have the potential to cause a metastability problem. As someone who works with high integrity hardware, the design needed to be changed to a synchronous system. To speed up the logic decode, a 28 MHz clock is generated from the 14 MHz clock provided by the CD32. This ensures I have a higher speed, time aligned, clock for the logic decode and to help reduce the need for wait states. It does not convert the design into an accelerator!

It was whilst developing the programmable logic that a clash of projects occurred, something which took time to effectively resolve.

One of the features added by the MIA CPLD was the floppy disc interface. The core design was based on the CD32 floppy design on Aminet. One of my other projects was a prototype floppy interface in VHDL for the classic Amiga. It made sense to finalise that design before incorporating that design into Hermes. The basic double density only design has been incorporated after the final compliance testing was integrated with my A1200. In the near future I plan to release the V3 floppy interface, with the highly experimental, HD support. If I can get the HD support working reliably, it can be incorporated into Hermes.

The second conflict was from my Retro Video Adaptor, another project, which looking at that page, has gone nowhere since 2013. It’s not the whole truth it stalled for good reason, it would not work reliably with 240p/288p video. The basic concept was fatally flawed. It was inspired great success achieved using these video decoder parts with non-standard video but the tricks I learnt did not work with the Amiga! Without using timebase correction on the video output, I could not get YPbPr or HDMI outputs to work reliably. It was from this issue that I initially started playing with the GBS-8200 as this has a timebase correction feature. The critical feature of the GBS-8200 is that it has a framebuffer memory to convert the 240p(NTSC) and 288p(PAL) video to a higher resolution and provide a 60Hz output at a standard resolution. Without a stable output conversion, the downstream video output can not be converted to YPbPr or HDMI. It is this issue with 240p/288p video that causes many SCART to HDMI adaptors to fail as they do not know how to handle this video system. Some will interpret 240p as 480i (NTSC) and de-interlace, thus causing fuzziness. The same goes for 288p being interpreted as PAL video. Switching off the de-interlacer greatly improves the GBS-8200 video output with 240p/288p.

Tecnobabble out of the way, how is this relevant to the long delays on Hermes?
I have been looking into incorporating an HDMI output into the design. Handling the audio is easy, I have a stereo audio ADC for that that outputs the correct transport stream, it’s just the Amiga video I need to solve. Some experiments with a small FPGA to ‘adjust’ the timing were trialled with no success. Experimenting with the GBS-8200, I have seen what a system that can re-time and re-scale the video can achieve, whilst being fully aware of the issues of motion compensation and blurring among other artefacts. It was with regret that the implementation of an HDMI interface will not be part of the Hermes design. This decision was made due to the amount of time required to implement a reliable interface. It will be better to run the two projects in parallel and maybe add this in at a later date if a solution becomes viable. I have a candidate solution which is undergoing technical evaluation.

Someone will ask why don’t I use the Vampire FPGA accelerator and HDMI core?
The HDMI output is incorporated into the CPU core design and associated FPGA. The Vampire design is a very clever implementation but currently only supports 68000 instructions, the CD32 has a 68EC020 which supports a slightly different instruction set. The other reason is that at my current development rate, adding a new FPGA accelerator the design would never be finished!!! :p

The third and final conflict was finishing the updated Amiga/Atari floppy adaptor. I’ve just sent out the purchase order for a production run of 75 units. Yes you did read that correctly, the new design has been updated to work with the Atari ST/TT/Falcon in double density mode. This was a late design addition that delayed production by 2 months whilst a new prototype was successfully built and tested.

What’s next?

I still have a few changes from my design review to incorporate, mainly to improve testability and reduce emissions. Once complete, I’ll finish tracking the PCB. The prototype PCB will be a six layer PCB, this will make it easier to track and to provide some controlled impedance signals. Experience gained from getting the existing adaptor PCBs has helped me find lower cost quality PCB suppliers and assemblers.

I’ll answer another question, why have I not just made a prototype of the design I had 6-9 months ago?

Cost. A batch of 3 assembled prototype PCBs would cost >£500. It would be a bit cheaper if I assemble the prototypes myself. I’d rather spend a bit longer doing my innate design checks/double checks before committing to a prototype.

I will try and update this blog more often. There’ll be another post shortly related to the GBS-8200 experiments.

May the force be with you!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s