Author Archives: Marcel

A sign of the apocalypse? QPC2 v5 is here

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!

Never thought we’d celebrate during a pandemic, but nonetheless, happy birthday Marla!

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?

hg churn -s -f "%Y"
2013  58272
2014     73
2015    355
2016   1946
2017  21275
2018   5031
2019   8603
2020     57
2021    116

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.

QSOUND

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.

Digitally signed

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.

Misc

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.

SMSQ/E v3.37

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.

Get it

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 ๐Ÿ˜‰

QL-VGA v2 production

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:

QL-VGA v2 validation sample

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.

The long road to QL-VGA v2

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:

QL-VGA v2 first prototype

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…

Hardware from my past

After months of work I finally added a few new pages to my site. First, there is a small page describing my old QL, which was pretty unique:
My QL of yore

Related to that I updated and open sourced two extension cards I used to use, a Sandy SuperQBoard clone called the “Herbert”-card

and finally the Eprommer-II solution from Jochen Hassler.

All open sources, including schematics, design and software, ready to be built. Enjoy!

QL-VGA update

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:

QL-VGA v2 CAD design

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.

New QD version B.07

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.

Fixed version is available from the QD download page.

QL-SD driver v1.09

A heap of dung

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.

Card business

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:

  1. 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.
  2. 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.
  3. 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.

In conclusion

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.

QL-SD ROM – the early days

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.

QL-VGA, the second

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).

Forum thread