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?
hg churn -s -f "%Y"
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.