Over a year had passed since the time I had received an updated version of SMSQ from Miracle, so I felt compelled to write a query letter to Stuart Honeyball (aka Miracle Systems) to see if I had been dropped from their mailing list. I also wanted to ascertain why I neither received the post card announcing QL Today nor a free, trial copy that so many others seemed to receive.
No explanation for not receiving the anticipatory post card; but, I did receive an offer to subscribe (free copies were sent to those who lost out on IQLR subscriptions).
While I have passing interest in “new” products, I am more concerned with “existing” products and Stuart Honeyball’s return query asking what I perceived to be wrong with the previous copy of SMSQ (v2.57). To this I responded with my short (but, significant) laundry-list of complaints:
1 After the novelty of having a QDOS compatible screen pop up on your PC, the diminished display size becomes annoying;
2 More than annoying is the atrocious WIN()_ overhead experienced; and,
3 Lack of Turbo Compiler compatibility is an annoying amazement since QDOS and SMSQ were both authored by Tony Tebby and because SBASIC is supposed to be SuperBASIC compatible.
SMSQ 2.76b
The good news is that I was sent a copy of SMSQ (2.76b) which accompanies the recently re-released version of the QXL (aka QXL2). I cannot say how the QXL2 differs from the earlier version other than coming with 8 Megs of memory for the price of the previous 4 Megs version (about $500).
I would hope that the I/O cache that was apparently developed for the Gold-Card-to-PC adapter was also incorporated; but, who knows?
The two, most noticeable SMSQ changes include the “WIN_FORMAT n” command which prevents accidental formats of a hard drive partition and the correct labeling of the QDOS WIN()_ partitions as ‘WIN’ instead of ‘DD’.
The same problems as before (listed above) persist.
GHOST BUSTERS
DrvLink (Tony Tebby) is a new [Oct. 1996], supplementary program that I received after further correspondence with MIRACLE wherein I noted my shock at their suggestion of a 100 Megs WIN()_ partition in the README.EXP which accompanied SMSQ v2.76b.
It has been my observation that larger partitions use more overhead; that is, the end user only has a portion of the partition while the remainder seems to be locked-up by the QXL for overhead — a 5 Megs partition was FULL after less than 2.0 me of data; and, a 16 Megs partition was FULL after about 6.5 me of data.
A simple extrapolation of the previously mentioned ratios suggest that a 100 Megs partition could easily gobble up 79 Megs for SMSQ overhead leaving only 21 Megs for the user! But, since it would appear that overhead use is not linear, the projected usable disk space would probably be less than 15 Megs.
The DrvLink program which was provided did indeed release the lost space on each partition, as intended. I don’t know how it fixes the problem, but it does.
I confirmed that it worked by first adding just a few files WCOPied from another source. Okay. It later occurred to me that I should “pack” the partition to ensure that all of it was usable. After being left with ZERO sectors free, I tried to run QLAMBer, and received an insufficient disk space message. I was a bit perplexed, but I quickly realized that the problem was the result of QLAMBer’s FLIST_imp file needing to be larger than before; so, I DELETEd the last file, and was indeed able to prove that all the free space on the drive was now available to the user.
DrvLink operation is simple. First, it asks if you have backed up all of your files before moving on to the next step in the program when it will try to break the barrier that has locked up the free space on the WIN()_ partition. With that caveat issued, you can proceed as you choose. I backed up WIN1_, ran the program, but later decided not to bother backing up the other WIN()_ devices.
The only problem I encountered with the other WIN()_ devices occurred when DrvLink aborted after encountering some bad sectors within a partition. So, I did back up this WIN()_ device, exited to DOS and DELeted the WIN.QXL file, re-FORMATted the WIN()_ drive, and WCOPied the files back to the WIN()_ drive, and then ran the DrvLink program.
The bottom line is that the DrvLink program works as Tony Tebby hoped it would (I presume that functional operation was uncertain and only theoretical since I believe I received the first copy of the program).
If you have experienced premature messages of “device full” then request a copy from Miracle. Presumably, DrvLink will be included with all subsequent releases of SMSQ.
REMAINING GHOSTS
Apparently, the TURBO compiler’s incompatibility will remain until Tony Tebby’s hubris is quashed and he decides to ensure SBASIC compatibility with SuperBASIC. Is this a problem? I don’t know. You have to decide how inconvenient this is for you.
The smaller screen will remain until either Tony Tebby and/or Stuart Honeyball and/or Jochen Merz realize how unhappy SMSQ users are with the product as delivered. Enlarging the usable area of a VGA display can be done in more than one way; but, the only (?) way that Tony Tebby can envision this being done is via a direct enlargement of the pixels.
Perhaps, I am naive in this matter. Nonetheless, I did offer a suggestion which should be viable; and, I will repeat it here:
First, the general 512×256 field has to be DEFAULT remapped (expanded) in a manner not dissimilar to the SVGA mode.
Second, CSIZE 0,0 is defaulted to a corrected CSIZE 1,1 whereby the height is reduced to 12/17ths (twelve seventeenths), or essentially:
CSIZE 1, 0.758824
The “height” that I suggest is based on my observation that 12 lines of SMSQ’d CSIZE 1,1 take up the same vertical space as 17 lines of DOS text. The “width” would appear to be approximately the “same” in CSIZE 1,1 as standard DOS generated text. It should not be difficult to generate and “clean up” the appearance of the font after this.
The GRAPHICS would be readily adjusted by whatever factor the general mapping area is expanded. As suggested (H=512 & W=256):
H x 1.875
W x 1.250
By letting a modified CSIZE do 90% of the expansion work, any anticipated processor overhead should be minimized or eliminated; and certainly, the bit-mapped BLOCKs can/will be simply expanding when the overall area is remapped. But, I could be wrong.
The impression I got from the correspondence received from Stuart Honeyball was that I am the only person who has complained about the diminished display generated. Can it be so? The display won’t be corrected if I am the only person who expresses a negative opinion about it.
Perhaps the presence of competing products (i.e., QUBBESoft’s “Aurora” VGA-compatible motherboard replacement in tandem with their Super Gold Card 2) will provide Miracle with an epiphany sooner-than-later and their release of version 3.nn of SMSQ with “enhanced” video display will be more than a hoped-for item.
However, if I am have been the only person to express a disappointment with the display generated, then SMSQ users will probably have to wait until Honeyball-and-company finally become annoyed with viewing the reduced on-screen font size.
HAPPY TRAILS,
AND COMPUTING, TO YOU …
[Figure: Red mountains above green valley — Sedona, AZ]