Monthly Archives: February 2015



Bummed out because you cannot connect your Amiga to the screen you want or enjoy your Amiga fully digitized ? Me too !

That is why I remade this adapter, hopefully keeping the Amiga alive for some more years to come 🙂

The picture is not perfect of course, but it is pretty damn close. The adapter will strech out the picture with a factor of 2, this could perhaps be avoided but will add to the complexity and timing and will not be handled with this prototype (believe me I have tried, but failed).

It is tested with an Amiga 500 and Amiga 1200 PAL computer. I cannot guarantee that it will work with Amiga NTSC computer, but I would be somewhat surprised if it did not work with some small tweaks. I implemented a button that can scroll the picture (from the source) horizontally and vertically. This way it is possible to handle situations with overscan and other strange things you could do in the crazy old days. It is also possible to shrink the picture horizontally (does not work with all monitor or TV sets) with the same button. This adapter should also be able to convert data from other sources, like old video machines and other retro computer that is sending out analog RGB data in 15Khz horizontal update frequency. But again, this has not been tested.



I must admit that this project is a bit complex. It has both analog signals and very high frequency signals (almost Ghz). There are also a lot if digital signals that will generate a great deal of noise. For the conversion part I decided to go with two ICs from analog design. One will work as a combined serial to parallel converter and analog to digital converter and the other one as a parallel to serial converter (HDMI transmitter). Since this adapter will also need to convert video it will need an extra device in the middle for this work. These ICs exist, sure, but those tends to be very expensive and difficult to work with. I chose the more fun approach, namely to instead go for a FPGA together with an SRAM working as a frame buffer. The two chips from analog design are state of the art ICs, highly flexible and configurable. They are also, sorry to say, very expensive. Together with the costly FPGA and the large and fast SRAM the BOM quickly becomes a little pricy. But who cares, its fun, right 🙂 The main bottleneck in this project is the FPGA. The number of logical elements and the memory is more than enough, but it is not able to work as fast as I would like. For example, to manage the conversion the non-stretch way is very, very difficult (I have tried many times with different approach). But if you only read one pixel and display it twice, it is very manageable as you can see. What you really want for these applications is DPRAM. But unfortunately those kind of memory is for projects where budget is not a big issue, like the guys at NASA 😛 This project has its limitations though. It does only support 16 bit color, which is a shame really. But it will simply be too expensive to support 24 bits or more. Also this board draws a lot of current. Actually too much for the Amiga specification on the used port. However the old Amigas tends to handle the power abuse better than new ones. That is why I only use this adapter with Amiga 500. It is better to use external power which can be connected to the board. The VGA port that you see is meant for debugging. It is possible with a switch to get either VGA or Amiga RGB signals into the system.


MCU software

The MCU software for this project is very easy. I do not need to explain anything here really. Simply put, the MCU will talk i2c to the two ICs from analog devices and configure them. It is possible to do manual configuration with the use of the UART port though terminal program and a straight forward ascii protocol. MCU will also handle button press, gpio pins and so on.

FPGA software

The FPGA software is the tricky part in this project. The main thing here is writing and reading from the SRAM memory and handle input and output from and to the FPGA (see top.v file) “simultaneously”. The FPGA uses a reference clock that you can see in the schematics running at 37,125Mhz. This clock is PLL’ed to the frequency 148,5Mhz (which is exacly x2 of the 720p pixel clock) and this PLL is the heartbeat for the FPGA. To make a long story short, the FPGA has 4 states where it does stuff. Basically there is one state that it is reading pixel data from SRAM, 2 states that is outputting pixel data to ADV7511W and 1 state that is writing pixel data (if a new pixel is available) from AD9984A to SRAM. In other words, there is only one state that is reading but two states that is outputting data, hence picture is stretched by a factor of 2. When the FPGA gets a pixel from AD9984A it will store the pixel data to a variable and set a flag that a pixel is ready to be written. The FPGA will then wait for the appropriate state and write the pixel to the sram at the correct address.



Language – C
Compiler – GCC ARM Embedded
Development platforms – CooCOX IDE


Language – Verilog
Compiler – Lattice Diamond
Development platforms – Lattice Diamond


Hardware components

MCU: STM32F030K6T6
HDMI transmitter: ADV7511W


I made the design using 4 layer PCB (impedance dependent, stack setup is important for high freq. pcb). The board was manufactured using a fab called PCBCart (the inductors can be bypassed).




Input: 288p @ 50 Hz or 576i @ 50 Hz
Output: 720p @ 50 Hz / 60 Hz
Maximum colors: 16bit, 65536 colors
Power input: 5V (Switch: External or Amiga)

Power consumption

1. Rail 1.8V AD9984A : 223 mA / 401,4 mW
2. Rail 3.3V FPGA, MCU, SRAM : 135 mA / 445,5 mW
3. Rail 1.8V AD7511W: 45mA / 81 mW

Heat Dissipation from LDO voltage regulators:  Approx. 1W.
Total power consumption: Approx. 2W.


Design Software: Proteus 8 Professional
Debugger and flasher: SWD, ST-Link (MCU)
JTAG, MachXO2 Breakout Board (FPGA)
LICENSE: Creative Commons Attribution-ShareAlike 4.0 license


So is the picture better than original A520 adapter and composite or RF?
YES, I would say that it is much better, at least on the monitor that I used !
Also there is no delay, since AMIV does not buffer anything (almost).

Is the picture better than just using scart from Amiga ?
I do not know, I have not tried the scart way. Scart would probably deliver pretty good picture quality (for the TV set that supports Scart that is).

Is the picture better than using some cheap Chinese Scart to HDMI adapter?
I would be careful to claim such a thing. I honestly do not know. But many of them have unwanted artifacts and other visual problems, some also have a bit delay (I’ve heard).


source code and gerber files
3d model