The remaining stock of QL-VGA was sold in under 24 hours on SellMyRetro (wow) and I’m asked quite often for more. The thing is, all cables for QL-VGA were hand-made and making cables isn’t exactly my favorite way to spend my day. I inquired some cable companies for professionally made cables and the prices are fairly reasonable. But they have quite high minimum order quantities and shipping costs have gone through the roof because of Corona (no flights to and from China means less plane capacity for cargo. And the order is too small to ship via sea).
So I was looking around and thinking some more and decided that using a big DIN connector for QL-VGA is the way to go (the same as used in the QL) as I can get these cables at lower quantities and with much reduced shipping prices. But the big DIN connector doesn’t fit on my QL-VGA sandwich design and in any case soldering the remaining 221 joints on each board wasn’t that much fun either, so in the end I did a complete redesign as a single board:
This is the most complex board I’ve ever done: my first 4-layer board, my first FPGA board and my first Spartan 6 design. That’s a lot of firsts, so it’s entirely possible that it will not work. I ordered the boards and components yesterday, so in 2 to 3 weeks I will hopefully know more. But if it works then manufacturing it will become much easier. Finger’s crossed! In terms of functionality it will be pretty much the same as v1 for now.
I introduced a bug in QD version B.05 that when the window was configured too high to fit on the screen (either by configuration or by command line parameter) QD will corrupt the memory. Curiously the feature of per-extension highlight handling was the culprit, a very unexpected side effect, so thanks a lot to Per Witte for finally isolating the problem.
I’ve been working hard behind the scenes to release a new version of the QL-SD ROM driver. The starting point was that Urs König asked me about a mysterious heap corruption with QL-SD when using his QL/E distribution under Minerva. And mysterious it was, after stripping down QL/E’s monster boot file to a few lines a simple WSTAT command turned out to be the culprit. How can that be?
Long(!) story short, this turned out to be an incompatibility between a compatibility hack contained in SMSQ/E’s DV3 driver (on which the QL-SD driver is based on) and Minerva’s heap manager: when the first empty space in the heap was exactly(!) 384 bytes long the QL-SD driver corrupted the heap chain! This is difficult to debug because once you load a debugger the heap is too different to trigger the bug! Generally the bug is very difficult to trigger which is why it went unnoticed for so long, but fortunately with QL/E it was reproducible.
One network to rule them all
While working on the code I found a few more places where I could save a few more bytes, all in all a whole kilobyte even! So, what to do with so much space? It’s not enough space to include more card management functions (more on that later), but enough to do something I’ve been thinking about for a long time:
In one of my other 1000 QL projects I created new versions of the very famous TK2 basic toolkit and in doing so I also created the QLNET hardware proxy: this means that the highly timing critical low level QL network driver functions can be split off from the rest of TK2 so that they can be burned into a ROM while the much bigger rest of the network code is loaded from another device into potentially slower RAM.
And now with all this free space available the time has come for QL-SD to host the QLNET low level functions. Yaaay! The remainder of TK2 can then be loaded from SD without losing network support. Mind you this is only useful for original black box QLs, GoldCard and SuperGoldCard come with their own TK2, in this case the new functions are simply ignored.
SMSQ/E for Q68 comes with several CARD_xxx basic functions for working with the FAT32 host file system. As these are somewhat useful I adapted them for QL-SD and released it as an external BASIC extension. There are three new basic functions:
CARD_CREATE card,size_in_mb,filename$ Create a new empty file on the card with the desired size. The great thing about this command is that unlike files created by the PC the file is guaranteed to be contiguous, which is a necessity for usage with QL-SD. “card” is 1 for the first slot and 2 for the 2nd slot.
CARD_RENF card,”old-name”,”new-name” Rename a file on the card. Note that the QL-SD driver can not handle long filenames, so the filenames must comply with the old DOS 8.3 filename scheme.
dir$ = CARD_DIR$(card) Return the first 16 root directory entries in a string. QL-SD can only “see” the first 16 entries in the root directory, so this is a good way to check what’s actually seen by the driver.
You can head over to the updated QL-SD product page and get the new driver and toolkits. All QL-SDs produced by me shipped with an EEPROM that can be updated within seconds using an appropriate EEPROM programmer. I know not everybody possesses one of those, but unfortunately I cannot provide an update service at this time. I’m hoping that this can be somewhat crowd sourced so people with the hardware can help other people out, maybe even for a fee.
Speaking of fees, I do this all for free. And it’s taken up so much time that I need to scale back eventually. But in the meantime, if you still want to support my work, check out my cookie jar. In any case, thanks for reading and enjoy.
This weekend the German ZX meeting was supposed to happen, but for some pandemic reason it didn’t. Which is very unfortunate because not only did I produce a batch of QL-VGAs for it, I also had a secret product in development that I wanted to reveal there: QL-SD ROM. Please note that everything I write about here is in early development (maybe including the name), as a matter of fact after weeks of problems and lack of time it only started working yesterday!
So what is it? QL-SD ROM is an external QL-SD variant for the ROM port. That by itself is already pretty cool I think, but has basically been done before using a carrier board and the internal QL-SD variant. No, what I’m really excited about is that this board combines the functionality of QL-SD and the ROM switcher, i.e. it also has 512kb of flash on board that can contain up to 8 different operating systems.
“But the ROM switcher already exists, too” I hear you say, “what’s the innovation here?” Well, for starters, there are no DIP switches, this is true bank switching that is controlled by software, so a few more interesting usage scenarios become possible.
And that is not all, the main difference is that the QL can reprogram the flash itself, no external hardware necessary whatsoever! I think this is a first. Where supplying fixes for the QL-SD is a pain because it involves bending pins and reprogramming an EEPROM using specialized hardware, this QL-SD variant can update the OS or its driver using a simple BASIC command.
By default the QL always boots into slot 0 as slot 1-6 can only be selected using software. “But what if I want to boot into a different OS by default, what do I do then?”. Well, you simply flash that OS into slot 0 of course! It only takes a few seconds after all.
“But what happens if something goes wrong during the update?” you might ask. Well, there is a jumper on board that makes QL-SD use OS slot 7, which is some sort of “recovery slot” that should only be used to make slot 0 work again.
All this of course only works when the internal ROMs have been removed as otherwise the two devices would be fighting over the data bus. For people not wanting to open the QL at all there is also a “no OS” jumper that makes QL-SD leave the OS area alone so the ROM is only used for the extension slot. In this case the flash is not as useful but at least the driver can still be updated.
Well, that’s it for now. Remember, this is far from a finished product, it’s not even sure it will ever be one. But I’m currently very elated that everything finally works so I wanted you to share the joy 😉 Here are a few pictures, enjoy.
The last few weeks I continued working on the QL-VGA adapter, for once to have one myself and also because I was pretty strongly petitioned by some people. I’m not an electronics guy by trade, so this is some tough order for me. The first PCB I ordered looked gorgeous, but it was already obsolete by the time it arrived from China, in my haste I had made too many errors. I ordered the revised PCB on new years eve and a week later this happened:
I decided to stay with the readily available Cyclone II development board as it already contains pretty much all components like voltage regulators, FPGA chip, bootstrap EEPROM and some more stuff and it’s actually cheaper to get than just the chip on its own 😮
Of course the Cyclone II is downright overpowered for the task, it’s only utilized about 10%, but changing chip would be quite a huge task for basically no benefit other than the fact that having a single board solution would be a little bit more elegant in my eyes.
Anyway, my own board just adds the RGB input with level shifter, VGA output and SRAM chip. All the magic happens in the FPGA code, which is why I like FPGAs more and more, it empowers software people like me to solve real hardware problems 🙂 I designed the board upside down, so it forms sort of a compact sandwich with the FPGA base board (and as a fun exercise I decided to design the board single sided, there is not one trace on the visible side):
This time the SRAM is fast enough to allow for MODE 8, so this version is fully QL compatible and perfectly matches the 512×256 pixels to a 1024x768x60 VGA screen. The resulting signal in turn is easy to convert to HDMI, I got myself a 5€ converter which works perfectly:
In theory the board could also be connected to a ZX Spectrum 128 as this has a very similar RGB output to the QL, but I did not bother develop any FPGA code for this yet. Also, the QL code is currently PAL only, no provisions for NTFS NTSC have been made.
So what now?
Quite frankly, I’m not sure. This thing needs to be tested a lot more first, and then maybe there might be a production run. But actually shipping packages and stuff is not an activity I particularly enjoy, so I’ll see how I could handle this. But anyway, let me know what you think of my little project (comment, eMail, Facebook, whatever).
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:
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:
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:
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 😉
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>
Prompted by a customer request I have extended my QL-SD demo file with a few free QL games, 20 in total, including some that were never available for free before but for which I have the rights to release (basically the Jochen Merz catalog, thanks Jochen!).
I went to great length to try to make it as easy as possible, usually you can just select a game in the boot screen and it will run, everything is pre-configured. Even (Super)GoldCards are slowed down when necessary, still not every game will run properly on every QL configuration. The most compatible configuration is probably a QL with expanden memory but without any GoldCard.