Yearly Archives: 2019

ZX81 composite output

Recently I decided to dust off my old ZX81, the very machine that I learned programming on some 30+ years ago. It’s getting kind of difficult to find a TV that works with it, especially as I have the 1st ULA version that didn’t do the sync signals correctly. So I decided to “invest” (it’s only 10€!) into a ZX8-CCB (Crystal Clear picture Basic). It is a small additional PCB that provides an FBAS output with much cleaner signals.

The only question was the placement, in pretty much all pictures its fitted with long wires somewhere in the enclosure or in a gutted modulator. For preservational reasons I didn’t want to completely empty out the modulator but still wanted to use its output connector. So I came up with this placement that I haven’t seen before but makes for very neat cabling (using a simple PowerStrip to hold the PCB):

From the top you basically don’t see anything except the small brown cable that goes into the unused hole in the modulator housing to the connector (the original modulator connection just being unsoldered but left intact).

At first it didn’t show any picture. Even though it says that it comes pre-adjusted for the 1st edition ULA mine was apparently sufficiently different that the picture remained black. But not to worry, after playing with the two small potentiometers the screen came to life and voilà, the ZX81 now outputs a clean picture:

Example output

ZX-CCB can usually be found on SellMyRetro.

QL-VGA (part 1?)

The QL and its non-standard video interface has always been a problem, even more so since the introduction of LCD monitors. Since I got my QL out of storage a few years ago I’ve been looking for a solution. I bought all kinds of Chinese video converters, the GBS8220 for example produced a very unstable picture for me. The small black HDMI converter without a name worked a lot better, but here pixels went missing on the left side. Only a small adjustment would be needed, but the manufacturer has filed off all chip markings, making modifications even more difficult.

One and a halve year ago I tried to tackle the problem the only way a software guy like me could: with software. I took a Raspberry Pi, learned to program it without any operating system (“bare metal”) and connected it to the QL bus. The idea was to listen to any access to the screen memory and mirror an emulation of it on the HDMI output. This is what it looked like:

QL-PI HDMI adapter

It almost worked but there were problems with the address decoding GAL. With my knowledge today I probably could have solved it, but I also bought myself a Tetroid GoldCard later and it’s not exactly easy to get to the required bus signals when that is fitted, so the project was put on the back-burner.

Due to the mentioned GoldCard I also created a new version of the QL-SD device (as the original was incompatible) and for this I had to learn the Verilog hardware description language. A few months later I invested even more time to update the QL core for the MiSTer FPGA board (in progress and a tale for another time), also written in Verilog.

With this FPGA experience under my belt I revisited the display problem and tried another approach: using an old Cyclone II FPGA board plus some other chips I had laying around I managed to implement a QL-RGB -> VGA converter. It converts the 512×256 50Hz QL screen into a standard 1024×768 60Hz VGA signal that can be processed by probably every monitor in existence or further converted into HDMI if needed (the Cyclone II is too old to generate HDMI directly). This is what that looks like, a lot simpler than my previous approach:

FPGA based QL video converter

This is the very first prototype and it can actually only do mode 4: the SRAM I had in my bits-and-pieces box has an access time of 55ns. The VGA pixel clock is 65Mhz, meaning I need to generate a new pixel every 15ns. As pixels are doubled in x direction I need a new colour every 30ns. With 2 pixels per byte this means I need a new byte every 60ns. This would fit the requirement but the QL screen must also be captured and written to RAM at the same time! So currently it only works by packing 4 pixels into a byte, but this can easily be changed using a faster RAM chip.

In the end the effort paid of, the picture is pleasantly rock steady and complete:

Next step is to order some faster RAM and create a PCB for it, but now that it finally works I can start sleeping at night again, so this might take a while 😉

Forum thread

Quartus 18.1 MegaWizard problem

When importing a project into Quartus 18.1 it helpfully suggests that it can rebuild the PLL IP blocks. Problem is, afterwards the MegaWizard doesn’t want to recognise the blocks anymore. It doesn’t even show an error, it just doesn’t do anything. As somebody who has never even used a MegaWizard before that was somewhat unfortunate.

Intel apparently wants to get rid of the Altera roots and the newly written block is called “PLL Intel FPGA IP” now instead of “Altera PLL”. Problem is, the MegaWizard doesn’t know about the new name. But it can be helped, just manually alter the file “pll_wizard.lst” in the “ip\altera\altera_pll” directory. Changes are in bold:

[Basic Functions|Clocks; PLLs and Resets|PLL]
PLL Intel FPGA IP v18.1= "%t" "%w/../common/lib/megawizard.pl" --wizard:altera_pll  --early_gen:on --wizard_file:"%w/source/top/pll_hw.tcl" --familyparameter:device_family %f %o %h
<INFO>
[...]
<PINPLAN SUPPORTED="ON"/>
<ALIAS>Altera PLL</ALIAS>
<ALIAS>Altera PLL v10.0</ALIAS>
<ALIAS>Altera PLL v10.1</ALIAS>
[...]
<ALIAS>Altera PLL v18.0</ALIAS>
<ALIAS>Altera PLL v18.1</ALIAS>
<ALIAS>PLL Intel FPGA IP v18.1</ALIAS>
<ALIAS>PLL Intel FPGA IP v19.0</ALIAS>
<ALIAS>PLL Intel FPGA IP v19.1</ALIAS>
<ALIAS>PLL Intel FPGA IP v20.0</ALIAS>
<ALIAS>PLL Intel FPGA IP v20.1</ALIAS>
</INFO>

May this be of help to somebody.