A while ago I’ve sent pre-production QL-SD ROM samples to a few testers and now Dilwyn Jones has written a review of his, read it here. Thanks Dilwyn!
Unfortunately I don’t currently have much time for QL stuff and what little time I recently had I’ve invested into making a NTSC compatible QL-VGA. But before this quiet phase I had another fun project in the making, which might be of interest: I created an SMSQ/E version that boots directly from QL-SD ROM without having to boot QDOS first. For this to happen I created a new boot loader that employs the software bank switching feature of QL-SD ROM to initialize SMSQ/E bit by bit. This way SMSQ/E occupies 3 to 4 of the 8 available OS slots.
One of the more technically challenging aspects was that I wanted the boot loader to be compatible with stock GoldCards, i.e. it contains a minimal amount of dead code and data that fools the GoldCard ROM into accepting it as a genuine QDOS ROM! Good thing I analyzed the GoldCard ROM some years ago…
But it’s not all good news, the resulting SMSQ/E only boots correctly 80% of the time, in all other cases it hangs initializing the IPC co-processor. And thus what started as a fun project devolved into a debugging nightmare and I’m still none the wiser. Only after booting QDOS once it starts to work again, so QDOS must do something during boot that SMSQ/E does not… but I haven’t found out what it is, so the project remains in this unsatisfactorily halve-finished state.
Apart from that the hardware seems to have proved itself. There will probably be one more minor tweak to the CPLD code to read the currently selected OS slot, but apart from that things appear to work splendidly. However, I currently don’t have the time to go into production right now. Also, manuals need to be written, maybe 3D printed enclosures evaluated because it IS much more sexy with an enclosure, etc.. I guess all this will happen later this year. As I noted in a previous post, QL-SD ROM is at least designed to be much easier to be build compared to the original QL-SD, so availability once production has started should probably not be an issue.
Speaking of production, there is a batch of 9 internal QL-SDs waiting to be sold. Once the QL-VGAs are updated I will send them to Rich for putting the online.
After many happy customers Alex from the US was not impressed with the quality of QL-VGA’s picture quality and looking at what he sees this was completely understandable:
It was soon clear that he owns one of the relatively rare original US NTSC QLs and QL-VGA was never tested with one of those. My working theory was that it should work well with it as long as one does not use the JSU QDOS variant that switches the QL into NTSC mode. Unfortunately the assumption turned out wrong, because what I have never seen documented anywhere is that US QLs use a 15.10489 MHz main crystal instead of the usual 15MHz, thus increasing the pixel clock from 10MHz to 10.0699MHz! There is also a daughter board connected to the crystal that is missing in European QLs, but this is just an oscillator circuit presumably to improve the slew rate of the clock signal.
Now QL-VGA was designed to cope with variations in clock frequency as not all QLs are built equally anyway, but 10.069MHz was way out of the band I designed for and thus it fell back to the default 10MHz frequency, resulting in the aliasing of the QL pixel clock and QL-VGAs pixel sampling that can be seen in the picture above.
Fixing this was fairly easy, but then I got ambitious and also wanted to implement full support for the NTSC modes of the QL. So here are a few facts I found out:
US QL facts
The basic “NTSC mode” is also available on European QLs that use the later CLA2345 variant of the ZX8301 chip, the CLA2310 is missing this feature. It can be enabled by setting bit 6 of the MC_STAT register at $18063. This is independent from the mode 4/8 setting, so a JSU QL actually has 4(!) different and distinct display modes.
JSU QLs boot in NTSC mode, which means that the vertical display resolution is reduced to 192 lines. The F1/F2 window is moved up to be in range of the lower resolution:
When the QL is booted using F2 the QL stays in this NTSC mode and it will never leave it, no matter the colour depth. So there you have a 512×192 4-colour mode and a 256×192 8-colour mode. Both with a refresh rate (and thus poll frequency) of 60.05Hz.
Selecting monitor mode using F1 switches the QL to the normal 256 lines modes, albeit with a slightly higher refresh rate of presumably 50.43Hz due to the faster pixel clock. Issuing a “mode 8” command, which is commonly associated with “TV mode”, will however stay in monitor mode and thus result in the normal 256×256 8 colour resolution.
It’s actually very difficult to get a 15.10489 MHz crystal, the nearest I’ve found is 15.36 MHz which I ordered and then used to run some tests (it works but the QL will hang later in the boot process). Only later I remembered that I’m a master of FPGAs (not really) and those have PLLs that can be tuned to almost any frequency. So I actually created an FPGA project that outputs almost the desired frequency (15.104167 MHz) and tested it with that:
All worked well and thanks to the multi-ROM facility of QL-SD ROM I could easily boot the JSU ROM and verify that it work well, too.
Final verification with actual US hardware is pending as Alex is waiting for a suitable JTAG adapter to update his QL-VGA, but I’m now fairly confident I have removed any kinks left, now really making QL-VGA the best solution for the video needs of all QLs. Once that final verification has been done the remaining boards will be updated and put on sale, after which I might make another production run if demand warrants it.
I get asked a lot about the state of my new QL-SD, so here’s an update. The new external QL-SD variant (henceforth called “QL-SD ROM”) went through a lot of revisions:
This series also exemplifies my progress as a PCB-designer. I’ve never formally learned to create PCBs, so it’s all learning by doing. With QL-VGA v2 I made my first 4-layer PCB and that experience in turn enabled me to create the final variant on the right, “QL-SD ROM tiny”:
(the case will probably not be part of the final product, but I will offer the files as always).
One of the main features of QL-SD ROM, besides the two MicroSD slots of course, is its 512kB big flash memory. It can hold 8 different QL operating systems (called slot 0 to slot 7) and is bank-switched by software with slot 0 being the default on power up. Switching to another ROM is as easy as entering “ROM_SWITCH 5” into Basic. Also, there is one “Forces ROM 7” switch that can be enabled in case something is wrong with slot 0 so the QL doesn’t boot anymore.
All slots can be re-programmed using a new Basic extension, so updating the QL-SD driver or flashing a new operating system is as easy as typing “ROM_FLASH 2,ram1_minerva_rom” into Basic!
Hardware and software is pretty much finished, so I have sent two units to beta testers and I’m eager to hear what they have to say. When they are satisfied and don’t think major changes are needed a larger batch can be produced.
One of the problems with this new variant is how to get the initial operating systems on it in the first place. It cannot be programmed to the flash before it’s being soldered to the board. One way is to put normal ROM chips into the QL and enable the “Disable OS-ROM” switch on the board. This way the QL boots with the internal ROM and one can load everything needed for the flashing from floppy disc. Afterwards one has to switch it back, remove the ROMs from the QL and test the whole board… this takes a lot of time and I already know that I will loath the process very quickly. So you can see how dedicated I am to producing this by the simple fact that I even developed a special flashing station to bootstrap the process:
The Raspberry Pi’s GPIOs are connected to the QL-SD ROM and then basically emit the same pattern a QL would emit when it flashes the device. I actually had to program the software two times because the first version was written in Python and the Python GPIO libraries are incredibly slow (like “5-10 minutes per board” slow). So I rewrote it in C and that does the whole job within 40 seconds.
But I wanted big SDs!
Yeah sorry, no democracy here. I’m in love with the small form factor and the mechanical stability it provides. I did however buy a cheap MicroSD to SD adapter to test it and it works perfectly fine, so people can still enjoy large SDs with this device. Only one will fit of these as the slots are too near each other, but you can still use the second slot with a MicroSD card.
When the tests are finished and everything is alright I’ll have a look at making a first run. I just have one request, please restrain from contacting me personally to be informed when it goes on sale. I’m happy that you are interested but I just get too many requests of this kind. I will publish updates in all relevant channels and this being designed to not be too cumbersome to produce I hope I can make enough for everyone.
As a developer I wouldn’t exactly say that I thrive on pressure but it certainly is an important element in getting stuff done. QPC2 v5 has been in the works for over three years and I wanted to release it for almost as long, but there has always been this one more bug to fix or this one more feature to add to constantly push it back. Besides, writing software is kind of fun, releasing is not. To release software means updating manuals, creating installers, changing web-pages, and after the release hearing all the things that are wrong with it. In the past this would have been a payed for upgrade, giving at least one more incentive, but now that QPC2 is free this went out of the window, too.
On the other hand it’s sad to spend all those many hours, literally hundreds of them, and not make it available for other to enjoy. So I set myself a release date for today, January 24th 2021, which is not coincidentally exactly four years after the last release. I released QPC2 v4.05 on the 3rd birthday of my daughter and today is her 7th, how time flies!
By the way, QPC1 went on sale in 1996, so this is QPC’s 25th year!
So, what’s new? Well, the question is more, what stayed the same?
These are the number of lines changed, by year. 2013 was the initial transfer into the Mercurial versioning system and in 2017, the start of v5 development, we see quite a lot of activity with over 21000 lines changed. This was the time when I rewrote almost all of QPC’s remaining Assembler parts in C. Of course rewrite means that although it’s a lot of work, for the user everything pretty much stays the same. But having the code in an easier to handle language allows to make more complex changes later on.
Direct3D screen driver
The previous screen driver was based on DirectX 3, the one that was current when Windows 95 was still a thing. And, Microsoft not being Apple, it actually still sort of work 25 years later. But support for it became worse and worse over the years, mainly because graphic drivers have to do their part, too, and no manufacturer still cares for these old APIs. What sealed the deal was that my new laptop didn’t do pixel interpolation anymore for DirectDraw surfaces, making the result look really ugly and me very annoyed.
So after dragging my feet for a few years I finally made the plunge and rewrote the whole driver for Direct3D 11. Direct3D is an awfully complex and daunting beast and not really meant for the kind of usage I need for QPC, but it eventually worked fabulously and I couldn’t be happier with it.
DOS device (Windows file access)
Having the DOS device written in C opened up many venues for improvements without going insane by having to write it in x86 assembler. One of the most noticeable changes is that it now supports QemuLator style EXE headers, a choice that also took me many years to decide on. But with this feature the DOS device is now a first class SMSQ/E device that can actually be used in place of a WIN container.
Another feature is that file extensions by default are now translated to PC format, meaning the last “_” in a filename becomes a “.”. This way files can be used equally well from both within Windows and SMSQ/E. Not everybody might like this, so it can be disabled.
When I bought myself a ZX Spectrum 128 I was intrigued with the sound quality of the old AY-3-8912 chip and wanted to support this in QPC, too. The question was how to best provide an API that can abstract the hardware away enough that QPC’s virtual chip can equally well be accessed as one attached to a PAR port or a native solution.
For the QL there was the QSOUND board with the same chip, which wasn’t a huge commercial success and only experienced little circulation. But at least it was a native solution, so I took the existing API and tried to stay as compatible as possible. Not 100% compatible because QPC implements two AY chips for a total of 6 sound channels and two machine code functions needed an additional parameter to support this, but the rest is exactly the same. I also wrote a player application called AYPlay for some common sound formats. It’s included in the QPCDemo.win file.
Unfortunately documentation is a bit lacking at this point. The original QSOUND Basic commands as documented in the QSOUND manual should work though (try typing “explode” into SBASIC…). There is also a new and original QSOUND device that can be used to stream data to the chips. AYPlay uses this device for example. And AYPlay can also be used to create the data stream necessary from all supported formats, with that music can also be played using a simple COPY or SPL command.
This is the first QPC executable that is actually digitally signed. This might help some people with corporate PCs because due to security concerns it becomes more and more difficult to install unsigned binaries in some environments. Problem is that this costs actual money and must be renewed every year. We’ll see if further version will still have this.
The floppy driver has been rewritten and got a write cache to drastically improve write performance.
QPC_QLSCREMU now works both ways. Previously it could only transfer writes to the old 512×256 QL screen to the high resolution/colour screen. This was a problem for applications that mixed direct screen writes and OS writes. Now writes to the big screen are reflected back to the old QL screen, too, making the emulation perfect.
There are slight improvements to the BEEP implementation. This was triggered by fellow QL user Lee Privett, who unfortunately didn’t live to see this very delayed release. Still, this one is for you, Lee, rest in peace.
QPC2 now is not compatible to Windows 95 anymore! Say it ain’t so! XP is needed at least, but even that is so old that you shouldn’t really use it anymore, at least not on anything that is connected to the internet.
QPC comes with the new SMSQ/E 3.37, which was also released today. It’s important to know that the two need each other, SMSQ/E 3.37 is not compatible to earlier QPC versions anymore and vice versa.
If you made it this far you can finally download the new version here. If you enjoy it, consider making a donation or at least tell the world how great it is 😉
Merry Christmas everyone! The first batch of QL-VGA v2 has been produced and sent out today! Here’s the picture the factory has sent me for validation:
The connectors are missing as I’ll just solder them in myself, this shouldn’t take too long. Then only the FPGA must be programmed before a final test can happen, all in all much more manageable compared to v1 production. Not too bad for a pure software guy (despite this board looking fantastic IMHO it’s good to remember that I’m noway near an electronics professional, but at least stuff usually works…).
This leaves the question of distribution. I’ll try to get a contingent shipped to Rich from RWAP to be sold on SellMyRetro. Of course Brexit makes stuff a little bit unpredictable, but he could at least serve the UK marked if not more. If anybody else is also interested in international/EU distribution or has a tip for me in this regard, drop me a line.
As mentioned last time, I’ve designed a new QL-VGA version that is a lot more complex than the simple “hat” I designed for v1, but will hopefully be a lot easier to manufacture.
I’ve ordered the board early September and they arrived a few days later. Unfortunately JLCPCB, my go-to prototype house, while having an incredibly good cost/value ratio, can only populate parts they have in stock and at that date the FPGA was not available. Damn, but OK, I let them make the boards without the chip and at the same time ordered some from their sister company LCSC as you get a shipping discount when you’re ordering a board at the same time.
The boards arrived fine. The chips arrived in Germany, too, but then DHL somehow lost them. For some time I was still hoping that they will turn up, but as of today, one month later, they are still lost. In China the FPGAs are affordable, about 4€ each, but shipping usually takes a long time or is rather costly. Outside of Chine the chips are a lot more expensive, with a price range of 15 to 50€(!), and initially I didn’t really want to spend that much on an unproven board that of all incompetent people I mostly designed myself!
A few days later I found one chip in Spain, just 5€ plus 2€ shipping, hurray! Bought it immediately. Two days later the guy wrote “sorry, I have to cancel the sale, I don’t find the chip anymore!”. What the…?
OK, I give up, I order some more in China and just wait it out. Found some good offer on AliExpress and… that was 10 days ago and they haven’t even shipped them yet! What the…? Damn, before I’m getting completely cranky I gave up once again and ordered some from Mouser in the US, at 15€ apiece, but at least they arrived this morning, only 4 days later!
Oh joy, one month after I got the boards I finally have a chip to go with it! So, quickly solder it in, program the power supply to 5V/100mA and… hm, current regulation kicks in. OK, one short burst with 200mA in case 100 is not enough… nope, likewise. Damn, apparently there is something seriously wrong with my beautiful board! 🙁 After some head scratching I checked the chips against the CAD data and what’s that? One chip is soldered in 180 degree rotated! Quickly check the order but no, I specified it correctly, so while I am usually very happy with JLCPCB this time they screwed up.
Fortunately this is just an SPI EEPROM with lowly 8 pins, so easily fixed. And then… it works! It fucking works! First time! My most complex board ever just works! This is a kind of happiness most people probably cannot comprehend but I was literally jumping through the house, fighting the air with my fists.
So, at long last, here it is:
So, what now? Well, first a lot more testing of course and eventually find a board house that can manufacture it in greater numbers. With all chips on it, preferably oriented correctly! Hopefully this will work out OK, too, as it will be another first for me…
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.