QPC2 v3 - a review

Marcel Kilgus has now further enhanced QPC2 by bringing out version 3. I still find the naming conventions confusing - it would have been much easier if Marcel and Jochen Merz had called this QPC3 I think - the number of enhancements (I won't call them improvements as this implies there was something wrong with previous versions, which there wasn't) would have justified moving to a new name. Anyway, Marcel and Jochen are probably fed up of me complaining about the name by now.

Sadly, QPC2 v3 still requires Windows...but even Marcel The Miracle Maker can't work that many miracles I suppose. The good news is that it's not fussy which version of Windows it uses (Windows 95 onward, though Windows 95 users like myself will find that there are one or two minor features we can't use such as the support for 'wheel' mice). The QPC emulator is pretty well known by now, so I won't go into too much detail about QPC2 but rather focus on the changes in this latest version.

QPC2 v3 requires SMSQ/E v2a99 or later to work. As SMSQ/E is supplied with QPC2 this is not an issue unless you try adding a QPC2 v3 to an earlier installation and forget to upgrade the SMSQE.bin file.

Enhancements can be broadly categorised as follows:

• Configuration dialog changes
• Centering of QPC display window
• Enhancements to DOS device
• Enhancements to SER and PAR drivers
• Print filter
• Power management
• Support for wheel mice (Windows 98 onward)
• Ability to execute Windows programs from within QPC2
• Original QL screen emulation in all modes

QPC2v3 still requires DirectX video drivers to work. In fact, DirectX v3 or later is needed. Windows 95 users need to install the DirectX drivers for QPC2v3 to work. This can be obtained from the Micro$oft website, and is also available from some magazine cover disks. Windows versions from 98 onwards have DirectX or equivalent built in. Windows NT4 service pack 3 onwards also includes this.

The configuration dialog you get when QPC2 is started (or if this is turned off, by holding down the SHIFT key when QPC2 is started) features a number of new and revised features and pretty useful many of them are too! When the configuration dialog is on screen, a corresponding button appears in the Windows taskbar now, which is useful if you switch to another program before completing the dialog, you can just click on the button labelled 'QPC configuration v3.00 Final...' to quickly and easily get back into the QPC2 dialog box. The config block itself has now been reorganised too. SMSQE.BIN now has a level 2 config block, so you need MenuConfig or equivalent to configure it - the old Config program will not work. The same language options are available - English, French or German - and the keyboard options also include a USA keyboard option which is often quite useful when using QPC2 on a laptop.

There is now an option to ensure that if you "stretch" the display window, the X and Y sizes are altered to keep the same aspect ratio, which helps to prevent the rather strange distorted appearance when you stretch the display sideways and the QPC display becomes narrow and short. If you switch on this option (called Keep Aspect Ratio) either in the startup dialog box or in the system menu if you wish to change the setting "on the fly" during a QPC2 session without exiting and re-entering (the System Menu is the red white and black QL monitor windows symbol in the top left of the blue QPC title bar - click once on this and select "Keep aspect ratio" item). If you get into a tizzy and end up with a weird screen shape, one way of getting things back to normal is to (i) click on the System menu to enable Keep aspect ratio, then (ii) drag the QPC border inward, it will keep keep getting smaller until it reaches its minimum size and will then be in the correct aspect ratio so that the ugly doubling of some pixels does not occur and text and stippled colours look normal once more. This isn't a fault condition of course, it was meant to work in this way. You can specify the X and Y sizes of the window (the SMSQ area inside the windows border and title bar).

If QPC2 is started in a "window" rather than full screen mode, the window can now be placed at the centre of the screen. This is especially useful if you are using it in a fairly low screen resolution (512x256 or 640x480 on a SVGA or larger screen) as you no longer need to manually drag the window to the centre of the PC screen. Although it never really occurred to me to ask for this to be included, I am quite glad that someone thought of it because it's really useful to have QPC2 start up bang in the centre of the screen. You can of course still drag it to where you want it if you want to free up part of the display for other applications to use.

Three SBASIC extensions are included to control the QPC2 window state - QPC_MAXIMISE, QPC_MINIMISE and QPC_RESTORE perform the obvious tasks of minimising, maximising and restoring window sizes.

It seems to be possible to start up multiple copies of QPC2v3, each running in its own window. If your PC supports quite a high display resolution (say, 1024x768) it can be quite amusing to start 4 or more copies alongside each other. You have to be careful, only one QPC can access any given QXL.WIN file at a time for example, but it does seem to be possible though probably not of too much use! When you create multiple SBASICs in each one you can well and truly confuse yourself without confusing QPC2 too much!

QPC2 now has a 'Power management' button in the configuration dialog, which controls whether QPC uses only as much processor power as it actually needs rather than running at full power all the time. It works by "throttling" (Marcel's description in the QPC2v3 manual!) the processor emulation. Although described as 'experimental' it seems to work rather well. Intended mainly for use on laptops to conserve battery power, it can be used on desktop PCs too to enable other applications to get more processor power when QPC doesn't need it. This power management function is not the same as the power management function of certain laptops and desktop PCs, by the way. QPC power management works on the processor emulation part, not on the computer's hardware power management system.

As the power saving mechanism on some computers (as distinct to the processor emulation slowdown of QPC's power management) might affect time-keeping updates, the mechanism for updating the SMSQ time and date re-calculates a base value from the time of the last bootup of the PC from which the QL time and date are calculated once a minute which should ensure that the system time never drifts more than a minute from the PC time. It works by taking the time of the last boot and adding the number of seconds since then, which consumes a lot less processing power than converting the PC clock to QL clock every second. All I can say is it seems to work. It's not new in fact, previous versions of QPC1 and 2 did a fairly similar thing in their time. The reason why this is necessary is that the power management facility on some computers actually stops the processor while keeping all data in memory and re-activating it later, so it is not possible to maintain QL clock accuracy while the processor is stopped, but the PC can still supply the necessary information when QPC is able to process it to update the QL clock.

The SER and PAR drivers have been completely rewritten and should be more reliable now. In particular, users with multiple parallel ports on their PCs can now define up to 4 parallel ports (PAR1 to PAR4, PAR is normally PAR1). At first, I couldn't get my Epson Stylus 880 to work from QPC with PAR set to the PC's LPT1, but if I set it to Printer instead it suddenly worked fine.

Some older versions of QPC2 had a problem with the parallel port which meant that if the parallel port closed before printing ended, printing was suspended and you had to take emergency action like open a temporary channel to the printer from BASIC or some such action to enable printing to continue. This was fixed in recent versions of QPC2 and I'm glad to say that this version does not exhibit this annoying "feature" either. My problems with printing were partly down to the fact that I needed to set the printer to 'Printer','Epson Stylus 880' in order to print via the Epson driver in Windows, but I also had some other devices attached to the parallel port - a Primax 4800 scanner and Iomega Zip drive, all daisy-chained. I had to get the latest drivers for both to get the combination of Zip drive, scanner and QPC Printer working, but once I did update the drivers all was fine. Sadly, as I updated both at the same time I don't know which was causing the problem. It was especially annoying as all worked fine from Windows, but not within QPC2v3, yet it was updating Windows software which cleared the problem. I mention this here as I was lured into thinking that there was a problem with PAR in this version of QPC2 but it later turned out after a lot of wasted time to be a combination of misunderstanding how the new PAR drivers worked (the need to use Printer etc instead of simple PAR with this particular Epson printer) and a problem with a Windows driver, and over time the new QPC drivers have proved to be rock-solid for me anyway, so don't be tempted to instantly blame QPC2v3 if printing doesn't work with your printer, look about for other problems like those mentioned above before jumping to conclusions as I did.

QPC2 should detect when a third party printer filter is installed in the QPC directory. It detects a program called qpcprint.exe, which is a printer filter program, an executable program to run in Windows. Think of it as a little program which goes between PAR on the QPC2 side and the Windows printer driver to do some pre-processing of the data sent to the printer. When the Printer facility is selected, a 'use filter' option becomes available. Printer data is thus output to a temporary file and after closing the PAR channel the qpcprint.exe filter is called with the name of the file and the name of the selected printer as parameters. This is potentially very useful with the right software. For example, some Windows printers these days are only useable with Windows. They do not have Epson ESC P2 codes or HP code sets, they are addressable only from Windows or Postscript and that's that. An ASCII to Postscript filter could in theory be placed here to enable output to such Windows-GUI only printers as printers supporting Epson or HP code sets seem to be getting rarer and more expensive. This was discussed in a recent QL Today.

Another useful feature of choosing the 'Printer' option for one of the PAR ports is that if the printer is connected via USB (Universal Serial Bus) this will let you print to a USB printer connection. Haven't got one of those on my PC to try it out though.

Marcel has made a welcome change to the DOS device. Instead of the old arrangement of DOS1 being drive C:, DOS2 being D: and so on, the DOS device now has its own configuration dialog, like the WIN device. QPC2 users are long familiar with being able to define WIN1_ as C:\QXLWINS\WIN1\QXL.WIN for example (i.e. give a full path name for each WIN drive's QXL.WIN container). A QXL.WIN in QPC doesn't even have to be called QXL.WIN, though it does make sense to use it as a naming convention. The DOS device was previously constrained by the 36 character (+ drive name) limit on SMSQE filenames, so if the file you wanted was in a folder on the Windows Desktop for example: C:\WINDOWS\DESKTOP\MYLONGFOLDER\BUSINESS.TXT (which is 44 characters long) and tried to copy this with the DOS device:

COPY DOS1_WINDOWS_DESKTOP_MYFOLDER_BUSINESS.TXT TO RAM1_BUSINESS_TXT

this may well have failed because the filename became too long for SMSQ/E to cope with. Marcel has addressed this by allowing you to specify a path for each of the 8 DOS devices in the same way as WIN. So I have defined DOS5 as C:\WINDOWS\DESKTOP\ in order to be able to access Windows files I have a habit of dumping on the Desktop. Defining DOS5 in this way (why 5? Well I have 4 drives on my PC, 2 hard drives, CD-ROM and Zip drive) enables me to use the shorter command:

COPY DOS5_MYFOLDER_BUSINESS.TXT TO RAM1_BUSINESS_TXT

For emailing files etc I define directories called SEND and RECV on my hard drive, so I tend to set the DOS devices as follows:

DOS6=C:\SEND\ DOS7=C:\RECV\ DOS8=C:\QLTODAY\

This of course lets me save directly into these directories from many QL programs, e.g. SAVE DOS8_EDITORIAL.TXT. Very useful.

Although it has long been possible to re-assign WIN drives on the fly via the WIN_DRIVE number,pathname extension, there appears to be no equivalent way to re-assign DOS drive names on the fly (no equivalent DOS_DRIVE extension for example). As the DOS device is not expected to be used as much as the WIN device, perhaps this is understandable. It is not a major complaint at all. I would, however, have liked to have a DOS_DRIVE$ function to tell me what DOS devices had been defined though. Any chance in future versions, Marcel?

Taking this a step further, Marcel has now added the facility to execute Windows applications from within QPC2. It sounds perverse and somewhat less than useful, but in fact it does serve a need. For example, I often create documents in SMSQ/E but need to check that they display correctly in a PC program if the documents are intended to be used for work or displayed on the internet. So, having defined DOS5 as above to save the file on the Windows Desktop temporarily with SAVE DOS5_TEST.TXT I can then

QPC_EXEC 'wordpad','c:\windows\desktop\test.txt'

without ever having to leave QPC2 to start the Windows application. In fact, if Windows has a program associated with a particular filename extension, it will be started if you just specify the file, in the same sort of way as File Info 2 users will be used to.

QPC_EXEC 'c:\windows\desktop\test.txt'

would start the default application for .txt files (usually Notepad) automatically. Very useful, but some care is needed as it's very easy to tie yourself up in knots with this facility when you are not 100% familiar with Windows - I have got myself into a right mess once or twice with this I can tell you!

The facility to specify 'base' directories for the DOS devices also comes in very useful if you are using QPC2v3 on a set of networked PCs. Setting the base devices to a remote PC name like \\DILWYN\SHARE\ can let you access drives in shared folders on other PCs over the network. The above name is an example of a UNC name (Universal Naming Convention or Uniform Naming Convention depending on where you come from) where the first part is a name of a computer and the second part the name of a shared facility on that computer.

I haven't had access to networked PCs to try all of this out yet, but it offers the promise of being very useful in the office when our network is fully set up, I could run a QPC2 from CD on one of the PCs, transfer files between various PCs using QPC2v3 and even print to the office laser printer or the boss's colour printer from one of the other terminals! Best part, being the only QPC user in the office, nobody would quite know what I was up to, and I could also very quickly generate little miracle programs to do specific tasks (in a word, SBASIC!)...

When QPC is run on a PC which is part of a network of PCs, it can be useful to know which PC it's running on so that a boot program can set up some appropriate actions or settings depending on which PC it finds itself running on (e.g. use local printer or remote printer). This is where a new function QPC_NETNAME$ comes in. On my PC at home, which is not networked to anything else apart from via SERNET, it returns DEFAULT, but could return the network name of that PC. Obviously, if you have no experience of network names etc this will make no sense or be of any use to you!

While it may seem perverse to discuss PC networking in a QL newsletter, the fact that QPC2 can make use of PC networking technology to some extent and the fact that many QLers using PCs might be unfamiliar with the terminology used and stand to benefit from using the networking facilities of PCs if using QPC at work for example, makes it seem beneficial to me as I'm stating it in a strictly QPC context.

Like most versions of SMSQ/E, SBASIC on QPC2v3 includes various functions to return information concerning the system it is being run on. MACHINE returns 30 to identify it as a QPC system and PROCESSOR returns the processor family identifier. Although QPC2 is strictly speaking a 68000 processor emulation, PROCESSOR identifies it as a 68010. There are no QLs or emulators using 68010 (I don't even know if there is such a processor!) so identifying an emulated 68000 as a 68010 can be quite useful for certain software.

Another change to the DOS device is that it now converts characters which are illegal on PC file systems ("*/:<>?\| and some more) to some other characters and vice versa.

While this version of QPC2 has added a number of SBASIC keywords to handle new facilities, a few have been removed. The QPC_PEEK, QPC_POKE, QPC_IN and QPC_OUT (and their variants) have been removed as they are no longer useful. Few people used them anyway.

Those who have a version of Windows later than Windows 95 can now make use of the 'wheel' on certain types of mouse. Normally used for scrolling through menus in Windows for example, these mice have a little wheel near the buttons for unidirectional scrolling. QPC2v3 makes use of this by translating wheel movements into ALT UP and DOWN arrow keypresses which causes scrolling in many QL programs, e.g. the editor I used to write this review (S-Edit by Ralf Rekoendt) uses ALT UP and ALT DOWN to scroll the text while keeping the text cursor in the same screen position, so if I was using Windows 98 or later I could then scroll through the text with the wheel on such a mouse despite the fact that S-Edit is not a pointer driven program. Sadly, although there are such things as 'wheeled mice' for Windoze 95 they don't work in the same way and so QPC2 cannot make use of the facility.

If your program needs to know which operating system QPC is running on for any reason, the function QPC_HOSTOS returns a number indicating which type of Windows is the host operating system on the PC in question: 0 for DOS, 1 for Windows 95/98/ME or 2 for Win NT/2K/XP.

A long standing problem with older QL programs is that they do not manage to correctly write to the different parts of memory used by high resolution screens, and are even more stuck when it comes to higher colour modes of GD2 systems. Although the Aurora made a valiant effort to address this by 'shadowing' the 32K QL screen area and copying this to the visible screen, and programmers such as Malcolm Lear wrote software to do this 'shadow copying' on systems where this was actually possible (the emulator concerned had to have access to the 32k screen area at the original QL screen address), it was always a fiddly job on many systems. Marcel has taken the bull by the horns and writing to the old QL screen memory area now magically appears on the screen whatever mode you are using. But, this has a number of options set using the QPC_QLSCREMU command (QPC QL Screen Emulation).

QPC_QLSCREMU -1 enables the automatic mode where the emulation depends on the last MODE call.

QPC_QLSCREMU 0 disables the emulation completely (this is the default, so in order to enable the screen emulation you have to use one of the other parameters to actually activate it)

QPC_QLSCREMU 4 enables the emulation of 4 colour QL screen mode.

QPC_QLSCREMU 8 enables the emulation of 8 colour QL screen mode.

If QPC2v3 is in a 4 or 8 colour screen mode, the emulation always uses the same mode. But if you are using the 16 bit (65536 colours) GD2 high colour mode QPC2 can actually emulate both independently - programs which write in 4 or 8 colour modes can both work and all 8 colours can be displayed. Marcel claims that "some older applications work quite seamlessly again."

"Seamlessly" should be taken with a slight pinch of salt, however, as there is a caveat. It's one way only, from the "emulated" QL screen to the "real" screen. Colours written "legally" to the screen may not be copied back from the "real" hires or high colour screen to the "emulated" QL screen area, so applications which PEEK information from the old QL screen area may have problems if using BLOCK and PRINT to write legally to the screen in one part of the program and POKE or equivalent to write faster graphics for games for example in another part of the program. The mechanism should work very well in most cases though, as few programs use a mixture of legal writing, direct writing and PEEKing information from the screen to cause such problems.

I'm not sure I understand how this works fully, so I won't add insult to injury to the author of this emulator by making false accusations when I don't know how it's meant to work. For the most part, though, most programs which expect the screen to be 32768 bytes long, in 4 or 8 colour mode and located at address decimal 131072 or hex $20000 can now run in hires screens or even in high colour modes. This facility is a godsend for those of us who have the odd older program which won't work too well on modern QL displays (I know, I wrote one or two myself years ago!). Try running Page Designer 1 or 2 in hires screens without this for example!

The drop down menu in the opening config dialog which allows you to specify the amount of memory to be "claimed" by QPC2 specifies values from 1MB to 16MB in 1MB increments. If you type in a value though it will let you specify up to 128MB of memory and down to 1MB minimum (so you can't really set it up to emulate a 640K QL for software testing purposes for example) and PRINT FREE_MEM will actually report it has that amount of memory available. With the fairly small size of most QL software I don't think I'd find much use for a 128MB memory QL system though (Q60 users could have that much memory too). This raised two questions on my system, which has only 16MB of RAM. First, would QPC2 be able to access more than 32MB of RAM which I thought was the limit for SMSQ/E (not sure what the limit is actually). More seriously, since my PC has *ONLY* 16MB of RAM, it allowed me to start a QPC2 with 128MB of RAM specified, which I expected to either be disallowed with an error, or to find that the QPC2 curtailed the value to the maximum amount of RAM available. If I specified a 128MB QPC2 on a 16MB system, I would have expected PRINT FREE_MEM to report the maximum available on a 16MB system. But despite my PC having only 16MB of RAM, QPC2 started and PRINT FREE_MEM reported I had about 128MB of RAM free. Now I am accustomed to Marcel's miracles, but...this is not strictly speaking one of his miracles I'm afraid. It's down to the Windows virtual memory. My PC has only 16MB of RAM, so if I ask for more memory for QPC2v3 than it can supply, it creates a virtual memory file. Compare this with Quill's habit of creating a def_tmp file on microdrive or disk when it runs short on space. While this is useful, it may be slow, since writing the odd MB between memory and disk is going to be slower than using memory all the time. I created a 128MB 'RAM' QPC then filled as much of it as I could. Boy did the PC become sluggish. I won't try that again in a hurry even if I did need that much memory. What with GD2 supporting a theoretical 24 bit colour mode at 4 bytes per pixel, an SVGA screen could take up to 2MB just for PE to store a single copy of the whole screen, throw in a few programs like Line Design with large graphics, Ghostscript, and so on, perhaps we are moving into the era of needing several MB of QL memory, but a 128MB QPC2 or Q60? I'm not sure...

Marcel has now added nice new shadows to PE programs. Apparently, it was a bit more tricky and time consuming to implement than he at first thought. Glad he persevered. The result is pretty attractive when you see it for the first time!

Some caution is needed with RENAME when it comes to renaming files over the DOS device. Basically, it won't let you. It seems to stem from the fact that RENAME of a QL file in SBASIC actually allows you to move a file between directories (this is probably why the QPAC2 files menu has a command called MOVE rather than RENAME) by renaming the file. DOS/Windows renames don't work in quite the same way, it is not valid to move files from one directory to another with a rename command (it can only rename files in the same directory), so RENAME will not work with the DOS device and this is intentional, not an error. To rename files with the DOS device you will need to use the COPY and DELETE combination of commands instead.

A number of minor bugs in previous versions have been fixed, but details of these can be found in a text file on the disk, so I won't go into these in detail.

Finally, the QPC2 manual itself has been updated, and is now more readable though still does not include a full SBASIC manual for example, only the bits relevant to SMSQ/E on QPC2. It would be nice if an option existed to buy a complete manual for all versions of SMSQ/E on all platforms plus SBASIC plus the old QDOS bits, i.e. a complete new QL manual. It would probably be too expensive to supply with copies of SMSQ/E sold as most users will have the QL manual and possibly copies of SMSQ/E documentation for other or earlier platforms. Therefore, I'd like to see a COMPLETE manual available either on paper at extra cost (which would also help guard against piracy of SMSQ/E) or as text or document files on disk which the users could print out themselves. There is always the SBASIC Reference Guide from QBranch and RWAP, but this is not dedicated to SBASIC/SMSQ/E alone, it covers many toolkits and emulators as well, while not being exactly cheap to buy. Perhaps there is scope for someone to take the old QL manual (which is available as a text file on disk) and add the SMSQ/E and QPC2 bits to it?

All of the changes mentioned have been shoe-horned into QPC2 without any apparent loss of speed (as long as you don't force it into virtual memory) or reductions in useability. Although I have not bothered to run any benchmarks, it feels just as fast as ever in use, if anything, slightly faster or smoother in operation than before. The only time anything becomes jerky or sluggish is when Windoze decides to write to hard disk files or perform some task in the background - of course this sluggishness is then down to Windoze and nothing directly to do with QPC2 as a result.

This might only be the first version of QPC2 v3 (aaarghh, I really wish they'd change that name) but given that my experience of domestic PCs is that some make ZX81s with RAM-pack wobble look stable, QPC2v3 is already very stable and I can count the number of crashes without too many fingers. Indeed, if I rule out scrolling upward in Quill, programming errors on my part and underlying Windows drivers or other software problem, the number of true QPC crashes is probably nil or close to nil I'd guess. I'm pretty sure QPC2 crashes less frequently than a real QL!

If you are already a QPC user, it is well worth upgrading to this version of QPC2 (contact Jochen Merz or QBranch for upgrade details). If you are not a QPC user but are a PC user this will be a very worthwhile addition to your system. Upgrading is basically quite easy - just copy the files smsqe.bin, qpc2.exe, version2.txt and register.key to the qpc2 directory which will probably be in the Windows Program Files folder if you installed in the default folder. If you use MenuConfig you'll probably find you can use it to update smsqe.bin with your old settings too!

Of course, if you are a QL system user, you will probably prefer to get a Q60 super-QL from D&D Systems rather than splash out on a PC just to use QPC2. Some features new to this version of QPC2 are described as 'experimental' and feedback is invited from users, but don't let this put you off - QPC2v3 is far and away the best version of QPC yet and probably second only to a Q60 or Q40 as a QLer's dream machine!