High and Dry

It is quiet on the ql-users list lately except for 2 individuals who are keen to see another production run of Q60s. D&D systems have said that a run could be arranged if there were at least 10 interested people.

It's good news that dedicated QL hardware can still be produced. But in some ways it is disappointing that it is exciting to be hearing about a build run of hardware designed at least 10 years ago! Nothing has changed in the Qx0 motherboard since then. Even though the display resolutions make the system obsolete as it becomes harder and harder to acquire CRT monitors, The 1024x512 reolution does not display on any of the so far tested  TFT monitors. What is needed is a 1025x765 display or an 800x600 display. This requires the development of a new chip for the mother board. The problem is that no one knows the board specifications apart from the designers Claus and Peter. Software could be cobbled together from the drivers that exist in SMSQ/E for other QL incarnations but no one else knows the hardware parameters.

They left the QL scene several years ago in dispute over the SMSQ/E licence thereby abandoning their customers and supporters many of whom had spent sizeable chunks of cash on their hardware. It is such a pity as the display is the key weakness of the Q60 in the longterm. Such a pity

Boot Files

The ql-users forum has recently been discussing boot files again. 25 years on from the launch of the QL one might think that the definitive word has been spoken on the correct construction of a SuperBasic/SBasic boot file. Not so. The enormous flexibility of the basic programming languages on QL systems and the differing characteristics of the existing hardware configurations and emulators means that confusion still reigns because there is no one set standard merely enormous flexibility to have a personally configured boot.

For example with original hardware and the JM rom, one of the commonest roms in use, one has to complete the installation of system extension libraries by resetting Superbasic through the loading of a secondary boot file for the launching of applications as otherwise the applications cannot see the extensions. For JS roms and above this is not essential. But there are still advantages in breaking down the boot into separate entities. 

Quanta Magazine for October and November

Quanta are properly in colour now. A great dollop of colour has markedly enhance Quanta magazine. And its 60 pages long with excellent content. Programming the use of Ver$ by Dilwyn Jones. How to start chess games from Launchpad, Chaos Theory and Duck Shooting. An excellent issue. Well done John Gilpin and Dilwyn Jones. I am looking forward to the updates Quanta web site with content management, hopefully soon.

Hot Swappable IDE CF card devices for the Qx0

It is said that hot swapping compact flash cards using IDE to CF adapters is not possible on the Q60. Most IDE CF adapters are not hot swappable anyway. Some are and tend to be more expensive and may not be suitable for the PATA type IDE drivers in smsq/e.

None the less, I believe there is a simple way to adapt these cheap non hot swappable CF adapters to hot swap by mounting the CF IDE device in a removable 3.5 inch hard disk caddy!

Ok the caddy needs to be opened to access the CF card unless you have a caddy with an easily removable face plate.

Obviously do not remove the caddy and CF card while accessing files on the disk inside. When the device is reinserted either with a new CF card or the same you must remount the IDE device with a Win_Drive command to tell the system that there is a fresh IDE device to be used, otherwise it will not be recognised. And thats all there is to it. I have been trying this on my Q60 for some weeks now and not noticed any corruption of the CF cards data.

USB WIZ

This has appeared as a topic of discussion on the ql-users list again. The last time was in 2007. The device looks as if it is useful. All that is really needed intially is an application to communicate with the device using its inbuilt protocols. Future development might include SMSQ/E drivers for the device to integrate access to the file systems. There are 2 aspects to this project that I wonder about. Firstly since 2007 I have had some time to think about what I might do with a USB device and it seems there is little use for it at the moment given the limitation of writing drivers for all possible bits of hardware that may be connected. Secondly - memory sticks. There the problem is that they will be of little use unless a FAT32 device driver is written for SMSQ/E. Having spent some time looking at applications to read and write from FAT formatted disks I am not at all hopeful that this can be done due to the complexity of the data structures on PC disks and that the data is reversed compared with data organisation under QDOS.

36 or 40?

What is the maximum length of a file name under QDOS or smsq/e? The official answer is 36 characters. I discovered that QLiberator had this embedded in it this afternoon when I tried to link into a compiled program a file with a filename of more than 36 character. When I reduced the length of the file name to 36 character it compiled file. Wait a minute I had a legal file on disk with a name length of more than 36 characters!!  This file could be viewed, edited, copied and moved etc with the QPAC2 files thing! Earlier I was trying to get the length of a few files using the TK2 FLEN function, and guess what, it balked at file names of more than 36 characters although these were seen as legitimate file names by the file thing of QPAC2. Confusing it is but it seems in some circumstances that 40 characters is OK. This gives a file name of 36 characters plus 4 for the primary device : Win1_ or flp1_. But these device names are 5 characters not 4 due to the underscore. That makes the maximum file name length leaving aside the primary device 35 characters not 36. Tell me if this is so. If it is yet another QDOS secret uncovered.

Hard Disks, QLToday and Tony Tebbie

Some more on hard disks. I came across an article in an old copy of QL Today that I had forgotten about. Volume 10 Issue 2 August/September/October 2005, page 34. The author, Derek Stewart recommends partitioning QWA partitions to 512MB size. This is in contradiction to the standard advice of using no more than 256MB sized partitions. I think he may eventually have to revise his advice as while SMSQ/E will seem to read larger partition sizes the problem lies in the 16 bit limit of the number of files. I have used 512MB hard disk once. It was fine until the space occupied came to more than 256MB then files did not get written to the disk.
Sadly this article from one of the experts perpetuates the myth that you can only get 3 usable QWA partitions from a disk, in fact 4 is possible, just not with makepart_exe.


The latest QL Today is out - hurrah. Its a bit thinner now having shed its English distribution end as it needs to be postable from Austria without being too expensive. There is an extensive and interesting article from Tony Tebbie about the creation of the QL which make you wonder how it was ever functional and why some of us are still fans. Besides this there were 2 interesting listings. Not yet on the QL Toady web site. I am off to find some OCR software as life is too short to type all these things in.

Finally QL Heaven is still hearing about the financial angst between traders. Have the traders helped keep the interest in the QL alive for the rest of us or have they hindered the development of QL Nirvana. Its an interesting question. Some undoubted have been both a help and a major hinderance. For example in the opinion of some, the builders of the Q40, who launched this successor hardware but made continued development  dependent on open source for smsq/e. Yet the originators of the current crazy licence smsq/e licence did the scene no favours either. Almost despite the licence there has been substantial development of smsq/e and in fact it is possible to download the sources, modify if you wish and compile the latest version of smsq/e for any configuration of the QL except for QPC2 (commercial secrets there) for free! Madness!

Tony Tebbie's article has given me the idea of looking back at a few more what ifs. Another promise, if I get the OCR I will post more listings here to sane typing fingers.

QWA Hard Disk Secrets

One thing that has irritated me is that the MKpart_exe supplied with the Q60 is unable to make more than 4 partitions on a hard disk. As each partition can be a maximum of 256MB this makes for colossal wastage of available hard disk space. The final irritation is that the 4th partition has to be set to the remainder of the disk regardless of the size of the remaining space. If there is more than 256MB left this makes for a dangerous partition for smsq/e which due to the 16bit addressing scheme and 65535 file number limit seriously runs the risk of bad things happening on this partition.

There has been little or no information regarding the format of the QWA partition structure up to now. And there is absolutely no information in the public domain regarding the partition table structure apart from what I am about to tell. Firstly lately this site

http://www.qdosmsq.dunbar-it.co.uk/doku.php?id=qdosmsq:fs:qlwa

has publish detailed information regarding the QWA disk structure of the QXL.win file.
According to the information I have from reading raw QXL.win files it is accurate.
Secondly a little rummaging around on the first sector of my Q60 hard disk has revealed this : the partition table of the Q60 is on the first 512 byte sector of the hard disk. No real suprise there. It contains an identifier in the first 4 bytes which is $6002. The remainder of the sector is 0 except for 4 partition table entries. The entries start at position $01C6. Each entry is only 12 bytes long. The type of partition is identified by the first 4 bytes which are 1QWA. The next 4 bytes are the start sector of the partition and the last 4 bytes are the length of the partition in sectors and thats it.

The postion of the partition table is not movable within the sector. The first entry has to commence at $01C6. Table entries are editable with a program such as WinEd and so the last partition with its daft size set by MKpart_exe  can be edited to a maximum of 256MB.

Thats all for now but there is more to come on hard disk partitions.

QL Quill Adventure Creation System

A copy of this on microdrive cartridge just went for £38.00 on ebay. That is more I think than new. Who would buy this. I remember the version for the Sinclair Spectrum from many years ago. While it was OK it was limited to text only. What do collectors do. Do they have black box QLs as these are the only systems that can read the microdrive cartridges. The tape in the cartridges must be 20+ years old, so it won't last forever. Buying microdrive software cannot be thought of as a longterm investment.

If anyone knows what collectors do with this sort of stuff let me know. Are there standalone microdrives that plug into USB ports on PCs for transfer of the data. Should I expect a swathe of new text adventures released into QL Heaven

Quanta Magazine August/September

This hit the carpet the other day. So whats new in Quanta world. Well its colour now. There were colour screen shots - the first ever in the Quanta magazine! Here are some clips of some of the pages.

 

 

The content was quite good as well. Two new freeware programs from Dilwyn Jones site some updates to other software, a bit of intellectual stuff about chaos theory and some practical stuff on how to transfer files to emulators. All in all a good edition. If anyone reading this is a lapsed Quanta memeber, now is the time to resubscribe. Just go to their site and follow the instructions : Quanta Web site

Thats all for now

What is This

So what is the difference between these 2 plug in boxes. The one on the right is a TK2 ROM from CARE Electronics, while the one on the left is unmarked except if it is opened there is a ROM with a sticker on it stating that it is a Toolkit 2 ROM. This box has an amateur finish, and the soldering is amateur. I have done better myself. Is it a prototype or did they sell TK2 roms like this in the 1980s. I acquired the one on the right in the 1990s. 

Short Postings

ebay : An original QL went there for £201 - thats probably more than it cost new. Admittedly it was in working order and with the complete original packing.

Quanta magazine : I have just seen a copy of a 1986 issue with an article wondering about the future of the QL as a result of the Amstrad takeover of Sinclair. Somethings change and some dont.

Thats all for now

As Promised Part 3

While Quanta Magazine was upbeat QLtoday was ebullient. Almost simultaneously in 1999 both QPC2 and the Q40 systems were launched head to head.

With what happened subsequently one almost wonders which favourite operating system was in the mind of the editor that could be accessed via on keyclick. Was it smsq/e or was it windows, or was it Linux :))

Inside there was much of interest including a reference to QL on the internet, an interest that was shared with the Quanta readers, and sadly something that might have eluded the QL community upto the present for no good reason at all. That needs to be the subject of a future post.

 

 

As Promised Part 2

An illuminating contrast 10 years on in the Quanta magazine :



International shows, articles on TCP/IP, by Simon Goodwin expressing his opinion that this will be available by the end on 1999. An article on the aurora QL replacement mother-board by one of the traders who would be selling the Q60, QL top end in 3-5 years time. The QL flight song I reproduce here with no apologies whatsoever :



A dynamic and fun time especially as the QL as originally produced by Sinclair had not been manufactured for 14 years! And because the glossy newsagent 1980s QL World magazine had gone to the wall with Maxwell in the early 1990s. QL Heaven had propelled itself onward with enthusiasm, personal contacts and belief.

As Promised part 1

In 1989 the August QL World magazine featured the mem DIY toolkit function. The revised professional publisher from Digital Precision. News of the remanufacturing of microdrive cartridges by ablex. There was a tutorial on correct superbasic programming and a Superbasic game called Link. A 30MB hard drive for the QL from Miracle Systems cost an amazing £399!

In August 1999 ten years later QL World had long since vanished partly courtesy of Robert Maxwell. QL users were now served by a new journal QL Today and Quanta Magazine. More in the next post

Still Off Topic

I will be back on QL topics soon. Had a spot of trouble getting the itouch toconnect to the home wireless network. Had a search on google and loads of cries for help there. Seems it is a common problem. Many solution suggested from resetting the entire itouch and starting from scratch, to resetting the itouch wifi settings to default settings, to WEP encrytion being a problem with itouches, to changing the network encryption algorithm, to DHS server setting incongruities, to updating the modem router software.

Well here is how I set it up after trying the simpler of the solutions from the apple site. No need to change encryption methods, or upgrade the modem router. What I did was switch off the network. All PCs , and the modem router. Next reset the itouch wifi settings to default : settings/general/reset/reset network settings. Then fire up the modem router but not any other part of the network. Once it has set itself up fir up safari which will ask to connect to the home network. Type in the WEP key in hexadecimal not ASCII. And that's it. You can now restart the rest of the network. itouch just likes to be first on the modem and home.

Enough off topic. Next time QLing in August 1989, 1999 and 2009.

Off Topic

Just got an itouch mp3 player. Is there a QL emulator app for this??

ebay latest

Have been away for a bit. On ebay there are 7 "rare" original QLs for sale. Buy it now prices range up to £199.99. How much did you pay for your new QL in the '80s? They seem to be becoming an investment. Microdrive software on sale includes the games, jabber, reversi, steve davis snooker and psion chess. While supermonitor and locksmithe are the utilities at the moment.

Another Snippet

I was thinking about the QL World magazine and about all the bits of SBASIC code published in that. Which bits were the best I wonder. Here is one snippet that I have used again and again.

23548 DEFine PROCedure EditFileName(y%,x%)
23556 fil$=INFO$(edch%,y%,x%,40,fil$)
23564 END DEFine EditFileName
23572 :
23580 DEFine FuNction INFO$(edch%,ypos%,xpos%,max%,default$)
23588 LOCal y$(36),loop,key
23596 IF default$="":default$=dest$
23604 y$=default$:xpos%=xpos%
23612 kx%=xpos%+(LEN(y$)*6)
23620 PAPER#edch%,white:REMark CLS#edch%
23628 STRIP#edch%,white:INK#edch%,black
23636 REPeat loop
23644 BLOCK#edch%,216,10,xpos%,ypos%,white
23652 REMark PRINT#edch%,FILL$(' ',max%);
23660 CURSOR#edch%,xpos%,ypos%;
23668 PRINT#edch%,y$;
23676 Kursen edch%,kx%,ypos%
23684 key=CODE(INKEY$(#edch%,-1))
23692 SELect ON key
23700 =9,10 :REMark ENTER/TAB
23708 IF LEN(y$)>0
23716 BLOCK#edch%,216,10,xpos%,ypos%,white
23724 Kursen edch%,kx%,ypos%
23732 CURSOR#edch%,xpos%,ypos%
23740 PRINT#edch%,y$
23748 RETurn y$
23756 END IF
23764 :
23772 =27 : REMark ESC
23780 Kursen edch%,kx%,ypos%
23788 RETurn INFO$(edch%,ypos%,xpos%,max%,fil$)
23796 :
23804 =194 : REMark backspace key
23812 letter=INT((kx%-xpos%)/6)
23836 IF LEN(y$)>1:y$=y$(1 TO LEN(y$)-1)
23844 IF LEN(y$)=1:y$="":kx%=kx%-6
23852 kx%=kx%-6 : IF kx%0 AND letter<=LEN(y$) AND letter>0
23884 IF letter>1:y$=y$(1 TO letter-1)&y$(letter+1 TO LEN(y$))
23892 IF letter=1 AND LEN(y$)>1 : y$=y$(2 TO LEN(y$))
23900 IF letter=1 AND LEN(y$)=1 : y$=""
23908 IF letter<=0:y$=""
23916 kx%=kx%-6 : IF kx%<=0:y$="":kx%=xpos%:REMark remove last charcter from string
23940 :
23948 =202 : REMark delete key
23956 letter=INT((kx%-xpos%)/6)
23964 IF LEN(y$)>0 AND letter<=LEN(y$) AND letter>0
23972 IF letter+2<=LEN(y$)
23980 y$=y$(1 TO letter)&y$(letter+2 TO LEN(y$))
23988 ELSE
23996 IF letter>0:y$=y$(1 TO letter)
24004 IF letter=0
24012 IF LEN(y$)<=1 : y$="" 24020 IF LEN(y$)>1 : y$=y$(2 TO LEN(y$))
24028 END IF
24036 END IF
24044 END IF
24052 IF letter<=0:y$="":kx%=xpos%:REMark remove last charcter from string
24060 :
24068 =33 TO 127 : REMark characters
24076 letter=INT((kx%-xpos%)/6):IF letter<=0:letter=0
24084 IF letter<0 24092="" if="">=LEN(y$)
24100 y$=y$&CHR$(key)
24108 kx%=kx%+6:IF kx%>=xpos%+(max%*6):kx%=xpos%+((max%-1)*6)
24116 END IF
24124 IF LEN(y$)>0 AND letter=1:y$=y$(1 TO letter)&CHR$(key)&y$(letter+1 TO LEN(y$))
24140 IF letter=0:y$=CHR$(key)&y$(1 TO LEN(y$)):kx%=kx%+6
24148 kx%=kx%+6
24156 END IF
24164 :
24172 =32 : REMark space
24180 y$="":kx%=xpos%
24188 :
24196 =192 :REMark move cursor left
24204 Kursen edch%,kx%,ypos%
24212 kx%=kx%-6 : IF kx%=xpos%+(max%*6) : kx%=xpos%+((max%-1)*6)
24260 END SELect
24268 END REPeat loop
24276 RETurn y$
24284 END DEFine INFO$
24292 :
24300 DEFine PROCedure Kursen(edch%,kx%,ky%)
24308 OVER#edch%,-1
24316 BLOCK#edch%,6,10,kx%,ky%,HEX("FF0000")
24324 OVER#edch%,0
24332 END DEFine Kursen
24340 :

Its a bit long. But it is a SBASIC equivalent of EDLINE$. Why bother with this then. Its easier to integrate into another program and removes one toolkit dependency.

Here is another little secrete as well. Notice line 24316. The colour number for the block command is given as HEX("FF0000"). SBASIC allows the 24 bit colour as $FF0000 but QLiberator written many years before the GD2 drivers does not accept this convention hence the use of TK2 HEX function. Drat thats another toolkit dependency but not so important as all expanded systems have toolkit2 and all 24 bit colour values require this format if QLiberated.

C Programming

Digital C might be updated. Check out the QL users forum

Quanta Magazine June/July

The latest Quanta magazine arrived today. Slightly lighter than previous copies but with 40 pages. Articles from the stalwarts Dilwyn Jones and Steve Poole. News items around games and the discovery of the lost installment of Simon Goodwins Browser program. Its now on Dilwyns site. I have given it a go here is a picture :




George Gwilt has made some changes to his programs. There are some new CDs. Dilwyn wonders if QcdeZe can be used on a Qubide2 system. I am fairly sure this is the case as I recollect that I used it when I had a working aurora system.

16k Colours with QPTR

My version of QPTR is 0.13. I have never ceased to be amazed at the resilience of this extension in the face of developments in SuperBasic and then SBASIC.

The Qliberator directive to incorporate this extension is $$asmb="location"_QPTR,0,172

I acquired the value of 172 by trial and error. It is published nowhere in any manual.



Anyway here is how to add 16k colours to the WMAN structures set up from SBASIC through QPTR. I had no idea of how simple this was until I came across an article by Geoff Wicks in QLToday in 2006, volume 10 issue 4 January to March, page 17. The article was entitled "Eleven Lines of BASIC". Nothing to do with QPTR but everything to do with the indexing of the colour built into smsq/e.

What Geoff says is this for colour index values:
0 - 255 QL colours
256 - 511 Palette colours
512 - 767 System colours (do not use!)-GWicks(sic) (Duh!)-me
768 - 1023 Shades of grey
Combine this minuscule snippet of information with the structure of the system palettes and what you get is add 512 to the index value of the system palette colour you want to use in QPTR window definitions and low and behold you have accessed the current system theme. System palettes/colours are described in QLToday volume 8 issue 2 May/June 2003 page 47.

Why was this not immediately obvious to plodders like me or how did Geoff get hold of this information so clearly and why did he not put it into context. Apply your own conspiracy theory.

Sorry no picture this time. Next time I will supply some examples of how to use this information.

Favourite Freeware QL Software

What software do you use regularly? Besides SBASIC, QD, one little bit of software that I find indispensable is StufferStore and GSH (Get Stuffer History). One thing that the QL does differently from the PC is its clipboard.

There are two clipboard equivalents. One is the stufferbuffer and one is the Scrap. The Stufferbuffer takes on line of text, length upto 32k if needed I think. It automatically picks up file names from the QPAC file requester but can also be fed lines from other programs. For example CTRL-Z in QD drops a line of code in and F10 in the SBASIC editor drops a line in. ClipScrapBoard and other clip programs also stuff lines into the stuffer buffer. The problem arises if the line you want has been over written. Perhaps you used that filename then did a few other things and now need it again, but its no longer the current item in the single line stuffer buffer.

This is where StufferStore comes in. Stufferstore when launched in the boot file runs as a low CPU consumption background task which monitors the stufferbuffer. Each time a new item is placed in the stufferbuffer stufferstore copies it into its own stuffer history, which is a SBASIC public history device. Then to retrieve the data along comes GSH. Hotkey GSH and it opens a window listing all items in the History device using the QMenu list select menu.



Select an item and there it is back in as the current item in the stufferbuffer. Copy and past several lines of a program - no problem. Store them all in the stufferbuffer from SBASIC using the F10 key. Paste them back where you want with the stufferbuffer hotkey using GSH to place each back in the stufferbuffer in the order they need to be pasted back out. Sounds complicated but is easy in practice.

As Promised

Here are some of the issues that have rocked the QLiverse in the past. I believe that what I am about to relate is factually correct but I am reliant on memory and therefore apologise in advance if I have got some of them wrong.

The first dust up that I am aware of is the 1996/7 argument over complimentary SuperGold cards awarded by the then Quanta Committee without the full knowledge of the membership.



Simultaneously here were also some beneficial rates given for advertising to some traders that were effectively a subsidy from Quanta. These problems were raised by the then editor of Quanta who subsequently resigned over the handling of these issues.

The next major fight was over the smsq/e licence where the handling of the licencing arrangements effectively left one hardware supplier who had been instrumental in triggering the completion of the colour drivers by Tony Tebby at the programming mercy of the author of the main PC emulator for the QL. A possible conflict of interest that was not resolved and therefore effectively finished native hardware development.




Then there were the cries of piracy from the author of Just Words. This confusing issue was mixed in with the above conflict but the separation of issues was not made clear until now.



There was the attempt by the chairman of Quanta to censor a public user group on the net.

There is still the running wrangle between the editor of QLToday and Quanta.

And lately there has been a public airing of dirty linen between an established UK QL trader and the owner of QLToday.

The miracle is that despite this QL enthusiasm continues. The lion in general lies down with the lamb at the QL shows but there has always been a slow leak of casualties that weakens QL Heaven.



A happier topic is needed for my next post I think!

Latest QL Today

QL today is the premier QL magazine at the moment. All has not been well with its UK distribution. This is the money trouble I alluded to in march of this year. The row rumbles on with an explanation from the accused and a commentary from the owner of QL Today. We humble UK subscribers are deftly reminded that for this final issue of volume 13 we are charity cases.

All this makes me think I should post a list of all the public fights that have battered and diminished ql users over the years. I will leave that for a future post.

Back to QL Today, contents include - actually I am not going to list them, here is the index page :)



Back to sprite troubles for now.

Sprites Again

OK here is another little snippet that I have picked up the hard way: Old style mode 4 sprite headers are 24 bytes long while new style GD2 sprite headers are 32 bytes long.
Get the offset for the mask or the data wrong and you will see some oddities even if the mask and data are in the correct place.

Back to sprites

Here is something more that I was not aware of. Mode 4 sprites often have a mask. So what is the difference between an alpha channel and a mask. I thought an alpha channel gives 256 shades of transparency while a mask only says this bit of the image is visible and this bit is not. Wrong apparently. While writing a bit of code to save a mode 4 sprite with a mask I discovered this translation in the mask:


Image Pixel ---> Mask Pixel ---> Visible pixel
white ---> white ---> white
white ---> black ---> black
red ---> black ---> green
green ---> black ---> red
black ---> black ---> transparent

Only those bits of the image where both the visible and mask pixels are transparent.

Crazy Ideas

I discovered today that with GWASS you need to have a version of smsq/e running before you can compile a more up to date version of smsq/e. In other words smsq/e is not freeware for self compilers! Is this what was intended in the licence? Shades of the microsoft world! This reminds me of a situation when I wanted to upgrade an older PC to an internet workstation by adding a PCI wireless card to connect to my broadband modem router. The PC from "PC world" was installed with release 1 of Windows XP. I had service pack 2 on CD from a magazine to upgrade the XP installation. Could I get the software for the wireless card to install and work. No way, until in frustration I connected the PC via an ethernet cable to the modem. Suddenly a raft of further windows upgrades down loaded and installed. Card now worked. Catch 22 - when upgrading a PC to add a wireless network card you need to have the latest version of windows installed. To have the latest version of windows installed you need an internet connection. To have an internet connection you need a wireless network card installed. To get the installed card to work you need the latest version of windows etc.

Anyway it seems smsq/e is now up with the big boys.

Finally here are some crazy ideas ; lets connect a microdrive to a Qx0 through a serial port. Why? Don't you have old software on mdv cartridges still. Or is there anyway to put SBASIC asleep on a key without a button being visible in the button frame?

Absolutely finally, what is the single most influential program in QL Heaven that has transformed the QL World? Answers on a postcard for discussion next post.

Another Secret

I expect every one knows this but me. I have been examining the format of mode 4 sprites. Why you say. Because I don't have a clear written description of it, even although the format was set 20+ years ago. Anyway to my surprise the line width of the sprite regardless of the visible pixel width seems to be a multiple of 4 bytes every time. Even a 7 pixel wide sprite in 4 colours which uses 2 bits to map each of the 4 colours available per pixels has a minimum line width in bytes of 4 not 2.

Why I wonder. Its a bit costly in memory in a system that was memory lite - 128k in a black box QL with about 96k available once the system had been loaded. In fact memory was so tight that some applications used the screen memory as a work area when processing data.

Anyway memory is no longer an issue. I wonder if this apparent profligate use of memory has allowed the Window Manager to be adapted to use 24 bit sprites although only 16 bit colours can be displayed.

I wonder.

Abandonware

One thing that surprises us here at QL Heaven is the fact that there are still "commercial" programs in the QL World that were written not just one or two years ago but decades ago. For example Text87plus 4 a quirky word processor is still a commercial program at a price of around £80. Who in their right mind would want to pay that premium price for an unsupported program. The author is no longer on the QL scene, does not develop software for the QL any more but will not relinquish the "commerciality" of his program. The last updates to make his program run on modern systems were done by the author of QPC2 and sold as a commercial program although there were bugs in that as well.




Other authors have been more pragmatic. Psion has allowed the free distribution of its seminal office suite both in the standalone formats and as Xchange, yet retains its ownership. I think Psion have also allowed the free copying of other software such as its famous chess program.



I can understand why someone producing new software may expect a financial reward at least initially after it is launched and while support is being provided. Examples of this are Launchpad and QPC2 both of which are currently supported.



The QL scene is littered with examples of abandoned commercial software where authors have declined to provide support yet still expect to be paid for each copy of their software in existence, even if it has to be patched by another authors program to run on existing QL systems.

It seems that new spurious copyright claims are being exploited as a means of gold mining enthusiasts. An example of this is the sale of the SMSQ/E O/S on Quo Vadis Design at £37.20. The O/S has not been significantly updated for 2 years. The previous 5 years of updating has been done by enthusiasts for free, not the original author. The O/S can be obtained for free on the original sources site (http://www.scp-paulet-lenerz.com/smsqe/) with all the necessary tools to compile and run the latest version for any QL system. Under the licence a token payment was required for distributors - this was 10 euros, even at today's exchange rate there is no way that 10 euros equates to £37.20



Authors should be required by law to demonstrate continuing copyright bt the provision of continuing support otherwise programs must be re licenced as abandonware.

Quanta news material

Dilwyn Jones, Quanta news editor is seeking QL news items for the Quanta magazine. Happy to pass on any info.

QL activity on the web

At the moment there are 7 QLs for sale on ebay, on auction with starting prices from 0.99p to £125-00 for buy it now. There seems to be a lot of QL interest although QL users, Quanta and QLToday all now seem quiescent. I recall reading in one of the QL magazines that Jan Jones book was now unobtainable. Have a looks at :

http://www.speccy.org/sinclairql/archivo/docs/docs.htm

Someone has been busy. Legal or not there is Jan Jones book amongst others in .pdf format.

Ql on the internet

Things are quiet on the ql-users list at the moment. Things are hot on ebay with more and more QLs and microdrive based software on sale and some, especially black box QLs in good condition going for good money. If only I had a stash of them.

Quanta Magazine

The latest Quanta magazine dropped through the mail box. Again full of content. The quality seems to have picked up significantly of late. Disappointingly there were two articles from Geoff Wicks, showing off his Janus faced attitude to Quanta. In one he praised black box QL users as he seemed to think a previously published article had been an attack on them because the author suggested that the key future of Quanta sustainability lay on the internet. Why he should think that black box users are internet-lite? Many black box owners use the internet. I have one. I will post a picture later. Geoff should have a closer look at the ebay sinclair QL site. Microdrive programs and black box QLs abound.

The trouble with the "Quanta debate about the future" is that the high profile protagonists positions are entrenched in cliches. That destroys all opportunity for original thinking. Thats what Quanta needs of course, not perpetual niggles.

Amusingly his article was followed by one from a "black box QL user" who uses the internet.

Shrinking Memory

100 a=RESPR(100)
110 POKE_W a,$287C
120 POKE_L a+2,$800000
130 POKE_L a+6,$70254E41
140 POKE_L a+10,$4EF80900
150 CALL a

In the beginning there were a number of memory reducing programs. Some commercial. They were needed to enable older software to run with expanded memory systems. Some can still be down loaded from Dilwyn Jones site. But they dont work on QPC2 or the Q60.

This little bit of SBASIC from Marcel Kilgus does the job. Line 120 sets the amount of memory to remain when the system is rebooted. $8000000 gives 8MB, for 4MB use $4000000 and so on.

Interest in the QL?

Who thinks there is no interest in the 25 year old QL computer. Rich Mellor has sold this week a boxed and working QL system for £155-00 on ebay as sold for £199 by Dixons 20 years ago (plus 4 blank microdrive cartridges) !!





Note the dust, not cleaned for 25 years but someone has parted with £155 hard cash for a working QL.

Spare GoldCard

No new hardware developments in QL Heaven since 2001/02. There is some quite good hardware out there - Goldcard, Supergoldcard, QXL ISA card, Qubide IDE interface, Aurora mother board, Hermes and Superhermes chips and the Q40 and Q60 successor QL motherboards. One weakness of the hardware scene is that there is no way to say upgrade memory or processor independently of changing a card. There have been various attempts to do so but have foundered due probably to the massive scale of the project attempted by a few individuals who also have families and day jobs.




Why I wonder is it not possible to upgrade say Goldcard's memory. Supergoldcard is after all Goldcard v3 with an upgraded processor and more memory. Is it possible to say replace the memory chips on a Goldcard or Supergoldcard? Has anyone tried?

Think of the QXL card, a 68040 processor and 8 MB memory designed to slot into an ISA slot on a PC. Yet at one point Miracle systems were marketing a slot converter to let a Supergoldcard plug into an ISA slot on a PC. Did anyone get one? Anyway what this observation suggests is that it is possible to convert an ISA slot to the QL expansion bus. If so could it be possible to use a QXL card with an Aurora motherboard or basic QL motherboard thereby expanding memory and processing power for these. Just a question.

Did You Know

The position of the EE pointer can be monitored without resorting to any of the QPTR or WMAN easyPTR extensions. The pointer record is in the channel#0 driver.

This may be found as follows :

chbas=PEEK_L(SVbase+120)
firstdev=PEEK_L(SVbase+68):REMark device list
:
channel0_driver=PEEK_L(PEEK_L(chbas)+4)
addr=channel0_driver : REMark pointer record is in this driver
:

ptrmove=PEEK_L(addr+126) : REMark read x+y position !!
ptrkey=PEEK(addr+49)+PEEK(addr+50)

Or slightly more robustly - this one finds all window channel definition blocks #0 being the first in the list :

DEFine FuNction Find_driver
REMark LOCal chbas,chmax,cnt,chp
cnt=0
chbas=PEEK_L(SYSBASE+120)
chmax=PEEK_W(SYSBASE+114)
DIM Drivers(chmax)
FOR chp = chbas TO (chbas+chmax*4) STEP 4
IF PEEK(chp)<>255
addr = PEEK_L(chp)
driver=PEEK_L(addr+4)
Definition_length=PEEK_L(addr)
IF Definition_length=defn_block
Drivers(cnt)=driver
cnt=cnt+1
END IF
END IF
END FOR chp
:
pop=0 :cntmax=cnt-1
REPeat TestDriver
IF pop>cnt/2:EXIT TestDriver
TestDriver=Drivers(cntmax)
FOR i=0 TO cnt-1
IF Drivers(i)=TestDriver:pop=pop+1
END FOR i
cntmax=cntmax-1
END REPeat TestDriver
RETurn TestDriver
END DEFine Find_driver
:
What use is this?

QL QDOS SMSQE Qx0 QPC2 Secrets

As promised. Although I do not pretend to know any top secret information only things that I have noticed or discovered myself over the years. There are some however in QL Heaven who believe in the official QDOS secrets act and have complained bitterly about it over the years. And then there is the dirty washing sometimes found on the ql-users forum and in QLToday.

Any here's one for for starters. The MOVEP instruction was removed from smsqe to improve compatibility with the 68060 processors of the Q60. But if you plan to use Text87plus4 on the Q60 you still need to LRESPR the MOVP4SMSQ60_cde extension as Text87plus4 also has MOVEP instructions.

When smsqe moved to version 3.04 or higher the channel definition block for console channels jumped in size from 304 to 432 bytes without warning.

Thats all for the moment, but more to come.

Coventry QL is 25

Simon Goodwin blew some eproms, there was a display of the history of the QL, loads of 2nd hand items, both software and hardware. Talks on the history of computing and design of electronics boards.

Steven Poole delivered a passionate analysis of what happened to home computing from its explosive inception in the 1980s to its almost complete absence now except for those left on the QL scene. Superbasic he argued was actually what made the QL a system worth continuing with. Superbasic released the power of the imagination.

Worryingly the meeting had an apparent lack of imagination amongst the attendees. Other than a sticky badge it was just another QL show with even less to show than before. So, disappointing underneath the surface. Perhaps the second day will be better. Perhaps new plans will be hatched over dinner. More later.

Software Writers

Here's a question - who are the all time most prolific software writers for the QL and systems?
Bearing in mind that I said prolific and not important the answer may be suprising. Is it Steve Poole, Dilwyn Jones, Thierry Godefroy, Simon Goodwin or someone else. With over 100 sofware versions maintained and listed on his site it must be Dilwyn Jones.

As for important - its got to be a dead heat between Tony Tebby and Marcel Kilgus.
Any other ideas out there?

QL is 25

Off to Coventry today. What on earth could the QL is 25 meeting have thats new and interesting. Will report later.

QL World SBASIC Programs or where have all the ideas gone?

Which QL World programs are worthy of the 21st century and the 25th Anniversary of the QL and deserve an update to utilise the power of the latest versions of smsqe? At the 25 Anniversary of the QL this might be an idea worth pursuing. Continuity with the past and a direction for the future.

The QL World published a lot of SBASIC and some m/c programs in its time. This is one thing that QLToday does not do so well. Are you listening Geoff Wicks? Some of the programs were useful utilities, some were games and some were downright weird.

There was a wild card file finder utility, designed for floppy disks, and might be again be useful if tweaked to do the same for hard disks. There was also a calculator. I typed both in and have used both in the past before progressing to hard disks and the extended environment. When I have time they are both on the list for updating perhaps. There were graphics programs like a contour plotter, a bit weird - what was the point. If you know - do tell. There was also a biorhythms program. Convert that one to run on a PC, make it shareware and become rich. There was a clipboard which I think was updated by at least 2 programmers. There several file browsers. Did anyone ever complete SNG's browser? There were many more> this is one topic that Quanta could usefully revisit for its members as well as QL Today. More useful than the sniping that often goes on at QL Today

Anyway which were your favourites and could they be usefully updated for today. I ask only because the ideas seem to have gone.

Finally I need to dig out some more snippets of code from any handy source and also any QDOS/SMSQE/QPTR secrets that I have stumbled across over the years for future posts.

Some History

I found this. I think it makes fascinating reading 15 years on
at the 25 th aniverasry of the QL.

At the end TT says the future depends on your(our) responses. In
retrospect were they correct?



A BRIEF HISTORY of SMSQ
Le Grand Pressigny, FRANCE - Tony Tebby

"Incompatibilities & Improvements, Bugs & Features"

"Was It All a Terrible Mistake?"  I knew right from the
start I should not do it, but so many people were asking for
SMS to come out from under its covers that, in early 1992, I
outlined a strategy (with Miracle Systems and Jochen Men) to
make a "QL compatible" version of SMS available.

The outline was quite simple. A QDOS compatible SMS kernel
existed (and had been in regular use since 1990). A complete
set of SuperBASIC procedures and functions existed. A
complete set of (extended QL style) device drivers for the
Atari ST series existed as well as "portable" disk, serial
and parallel port drives for other hardware. There was an
environment which supported QLiberator compiled programs.
All that was required was the core of a SuperBASIC
interpreter.

Following the success of the Gold Card, Miracle Systems were
looking for a legitimate operating system for their (as yet
undefined) forthcoming computer and Jochen Men needed an
operating system to legitimise the QL emulator for the Atari
ST series. It was clear that it would be best to provide a
version for the Gold Card as well but as Miracle Systems did
not want to get involved in selling software, the Gold Card
question was left.

I embarked on trying to find out what Sinclair's SuperBASIC
interpreter did. It was not difficult defining what it
should do, but Jan Jones had built it on the principles of a
GIGO (garbage in, garbage out) machine. With limited ROM
space, there was no room for real error checking so Jan just
tried to make sure that whatever rubbish SuperBASIC was
asked to deal with, it carried on and did something. The
"something" was not always obvious.

While WE (QJUMP, those wonderful people at QVIEW, Jochem
Merz, Albin Hessler etc.) would never deliberately exploit
"holes" in SuperBASIC, the same was not necessarily true of
other software suppliers or contributors to PD libraries. In
addition, even WE had been known to fall through a hole by
accident.

Compatibility, therefore, meant not only reproducing
SuperBASIC as it was intended, but reproducing as many
oddities as would be necessary to execute most QL software.
The two "compilers" for SuperBASIC programs provided a
starting point. The aim was to provide a BASIC interpreter
which would provide:

1. better compatibility with SuperBASIC than either
compiler,
2. execution at least half the speed of QLiberator,
3. an environment supporting both QLiberator and Turbo
compiled programs.

Clearly, as some software for the QL will not even work on
all QDOS ROMs, total compatibility with a particular QDOS
ROM can only be provided by copying that ROM code. Even
slight re-ordering of the QDOS ROM routines (as in the Thor
XVI) can cause considerable incompatibility. At this stage,
there was no intention of providing improvements. The
"Minerva Experience" had shown the extent to which the
slightest improvements could give rise to extensive
incompatibilities. So much for intentions!

The Birth of the QXL

"They should not have done it either!"  In principle, the
implementation of SMSQ on a 680x0 processor embedded in a PC
should have been fairly straightforward. The Gold Card used
the IBM PC disk controller, the IDE hard disk interface is
not very different from the Hardcard used in the Miracle QL
Hard disk and the serial and parallel ports on the PC are
much the same as the serial and parallel ports that you find
anywhere except on the QL.

If the QXL had been designed as a card which plugged into a
standard AT motherboard (no processor or memory) and
provided with drivers to drive a standard keyboard
interface, a standard multi IO / floppy / IDE card and a
standard Super VGA card, it would have been simple.

To have done this, however, Miracle would have had to have
supplied the PC hardware (at a cost of about half the QXL
card for a single floppy / 110 Megabyte HD configuration
this would have seemed, to me, the obvious way to do it).

However, it would have meant that the machine would not have

been usable as a PC (sigh of relief) and would have ruled
out the use of portables and notebooks. In addition, second
hand PCs were widely available either free or for less than
$30.

As one of the most likely reasons for a second hand PC being
available at a very low price was that the hardware was not
quite a perfect clone, then there was no possibility of
having a version of SMSQ which would access the IO devices
directly. Also, if the QXL were to be put into a real
"working" PC, it would not only have to co-exist with its
host but would have to work through whatever low level
software (Stacker, Doublespace, Hypercache, Smartdrive etc.)
was used to improve the IO performance of the PC.

As a result, any direct access from the QXL to the PC was
ruled out and the QXL was to be hosted by a DOS program. A
logical decision, maybe, but, from the point of view of the
operating system software, it was a disaster.

Where is the problem? The PC comes complete with device
drivers for all of its peripherals all that needs to be done
is to pass data from the QXL to the PC device drivers (using
BIOS calls) and vice versa.

There are three problems with this.

1. The design of the PC BIOS does not take account of the
requirements of multitasking (it is, for example, impossible
to write something to disk while you are waiting for input
from a serial port).

2. While the accuracy of the reference manuals about the
QDOS operating system entry points left a lot to be desired,
the (in)accuracy of "reference" manuals for the PC gives a
whole new meaning to the word reference.

3. All the reference manuals (so far examined) for the PC
were written in the days of the PC and PC/XT. The PC BIOS
also dates from this period. The BIOS has been considerably,
and incoherently, changed while the manuals have been
superficially updated to take account of AT keyboards, hard
disk drives larger than 10 MByte and 3.5" and HD floppy
disks.

Take, for example, formatting a floppy disk on the PC. On
QDOS, it is a single operating system call. On the PC,
however, part Of the format operation is performed by the
application. The format routine for the Gold Card floppy
disk driver took a couple of hours to write. As the PC BIOS
does most of the work for you, it should be easy to write a
format routine on the PC.

There are a variety of DOS and BIOS calls to help you do
this: setting the device parameters, formatting and
verifying tracks etc. I have three reference manuals which
give example format programs.

I look at the first one, and think "this is very strange".
There seems to be no way in which you specify the density
and there seem to be no checks for whether the tracks have
been correctly formatted: it appears to be automatic. So I
try it. Fine, it makes all the right noises and tells me
that my DD disk has 1440 sectors. I try an HD disk. Fine, it
makes all the right noises but tells me that my HD disk has
only 1440 sectors. It try without a disk at all. Wonderful,
it formats much more quickly and tells me that I have 1440
sectors! - AU FREE!

I try the second program: this one checks the error return
from the "Format track and verify" call: it even allows me
to specify the density. I try it with a DD disk. Fine! it
tells me that there are 1440 sectors. I try it with an HD
disk. Fine! it tells me that there are 2880 sectors. I try
it without a disk: the format fails, excellent! I try it
with a bad DD disk telling that it is HD. Fine! it tells me
that it has 2880 sectors. Suspicious, I try to copy some
files to it using DOS. DOS refuses to recognise it. I try
the other two disks: neither is readable. Over to QDOS to
look at the disks: there are no sectors 1, 2 or 3 on any of
the tracks I look at. This would explain why the first
program did not bother to check the error return from
"Format track and verify": it does not verify!

On to the third program. This is similar to the other two,
but uses the old "INT 13h" BIOS calls rather than the more
powerful "DOS function 44h" calls (wonderful this DOS
terminology). This requires the use of a separate "verify
sectors" call. The verify sectors call seems to work: this
routine gets an error on every track: it is right, after
formatting, none of the tracks are readable on any type of
disk.

So, I try it myself. After a lot of experimenting with the
BIOS calls described in the various manuals, I am able to
write either DD or HD tracks and verify them. The only
problem is that I write too many sectors to a track: the
last sectors overwrite the first sectors on the track. After
a week of work, I can select the density and I can nearly
format a track.

Thinks! Microsoft can do it, I should be able to as well.
Now we start to see the problem: the DV3 floppy disk format
routine is less than 512 bytes. Microsoft's FORMAT program
is greater than 32 kbytes, almost the size of QDOS, all its
device drivers, SuperBASIC and all its procedures and
functions. No wonder all the manuals are wrong. It would
take about 200 pages just to list the MSDOS FORMAT program,
without trying to explain how it works!

Disassembling all of this program could take months. I
decide to trace the two paths of interest: 720k and 1440k
formats. It turns out that what you need to do is to poke
special values into various undocumented locations in low
memory. I note all the locations to be poked and set up a
format routine. Within this routine I poke all the required
locations, format the disk and restore all the locations to
their previous values.

Success, I can now format DD and HD floppy disks. The only
problem is that, despite my care in restoring all the poked
locations, after a format the PC refuses to recognise any
disk change until you hit the reset button. Two weeks have
passed and I still do not really know how to format a disk
using MSDOS.

Do I spend another 2 weeks finding out how to restore the
BIOS after a format operation?
Even if I succeed in making it work on my PC, will it work
on any other PC? How can anyone succeed in selling an
operating system where it takes two weeks to write a routine
using the operating system calls when it would only take two
hours to write the same routine accessing the hardware
directly?

Now we find the real cost of the QXL in development. Even
though the IO performance of the QXL is well below the
levels that it would be reasonable to expect, the
implementation of the QXL device drivers has cost between 10
and 20 times the cost of equivalent drivers for other 680x0
platforms. As a result, all the time that had been set aside
for the development of the SBASIC interpreter has been
swallowed up. For the first purchasers of the QXL, things
looked grim: poor IO performance, no SBASIC interpreter. Not
a very promising debut for SMSQ.

"You Take the High Road and I'11 Take the Low Road" The QXL
hardware strategy was not the only problem to be faced.
Miracle Systems, for reasons which should be obvious, wanted
the QXL to seem as much like the Trump Card and Gold Card as
possible, while Jochen Merz wanted an operating system which
was not just developed along the same line as the Atari QDOS
extended device drivers but one which went much further.

One man's improvement is another man's incompatibility. Now
we have the problem of developing (and maintaining) two
different variations of SMS: SMSQ, the basic QL-like version
and SMSQ/E, the extended version which is likely to diverge
evermore and more from SMSQ. Jochen Merz, therefore, decided
to supply SMSQ/E for the QXL as well as the Atari and Gold
Cards. Easy for him to decide: it was me that had to do the
work!)

More problems. It seems that computer users are not very
sensitive about how much they have to pay for their
operating system. They are, however, very sensitive about
how much other users pay! Gold Card and Atari users do
not complain about having to pay for SMSQ/E (we told then it
would be necessary back in 1990), but they do object that
QXL users get a "free" version of SMSQ with their QXL. QXL
users do not seem to mind being asked to pay extra for
SMSQ/E (at the moment the differences are fairly small so it
is not usually worth "upgrading") but they do object that
Gold Card and Atari users are not being asked to pay more.

Even worse, there are some QXL users who seem to think that
they are being provided with a specially naff version of
SMSQ to oblige them to cough up a few extra pennies for an
upgrade!

Then to cap it all, Miracle Systems produce a Super Gold
Card which looks like a Gold Card, but turns out to be
rather different. We now have implementations of SMSQ on
three distinct hardware families, seven different hardware
variants, four different display types, with four different
68000 series processors, in three (and sometimes more)
languages. So far, there are more possible combinations than
there are users.

To avoid the necessity of producing a different version of
SMSQ/E for each user, SMSQ now uses a module structure which
has been borrowed from the Stella (Stella????) operating
system. This allows operating system modules to be selected
(or ignored) as the system is booted. In principle, a single
version of SMSQ could be delivered which would autoselect
the right modules for any hardware combination. In practice,
each hardware family (Gold Card, QXL and Atari ST/TT)
requires its own special loader, so that it is not worth
incorporating all the modules in each version.

Just as the number of users starts to take off, so does the
number of variations. Jochen Merz ships a copy of SMSQ/E
to a Gold Card user: the next day there is a message "SMSQ/E
does not work with the XXX keyboard". Not surprising, the
XXX keyboard uses a patched version of the JS ROM. The cure?
Another keyboard driver module for the Gold and Super Gold
Cards and another language module (the keyboard tables). The
net result is one new user and four new variations. Counting
variations is soon going to be like counting marbles in a
cookie jar.

"'Till Death us do Part"  In the days of easy divorce for
reasons of mutual incompatibility, it is surprising to find
so many QL users wedded firmly to the old software packages
of the "use it at your own peril" style. Then I started the
evaluation of SBASIC, Miracle Systems sent me a bundle of
diskettes (about 10 Mbytes worth) of the type of software
that they thought might provide a test for the compatibility
of SBASIC.

I started looking at these disks on the Atari ST with JS and
the E level drivers. After resetting the Atari ST for the
tenth time without having found any software which even
started to work, I gave up and tried using a Gold Card.

After a day or so, I found two programs that could be
executed, played with and removed without crashing the
system. All the rest either crashed right at the start,
could not be made to do anything sensible, or could only be
removed by resetting (I began to understand why some users
have been asking for a quick reset). I have been told that a
lot more of the software would have worked if I had set the
memory size to 128 kbytes, but if you are going to reset you
machine to 128 kbytes use one program and then reset again,
there is no point at all in using SMSQ: you might as well
stick with QDOS on your old faithful QL. Seriously, does
anyone use this type of software anymore?

The first compatibility tests were very encouraging: all the
programs which crashed on a JS QL crashed with SMSQ. It
seemed that we had obtained better than 95% compatibility.
Moreover, one of the two programs that worked on the QL
worked with SMSQ: the figure was up to 98% compatibility.

"New Lamps for Old"  One of the best ways of checking the
originality of software is to investigate the bugs. If two
items of software perform the same functions correctly, one
could be a copy of the other, or they could both be written
to the same specification. If, however, two items of
software exhibit the same bugs, it can be assumed that one
is copied from the other.

There are very few "first level" bugs (bugs which prevent
the system functioning correctly under "normal" conditions)
in QDOS. Because of the GIGO policy and the desire to limit
error checking to a minimum to maintain efficiency, there
are a much larger number of "second level" bugs (where the
system misbehaves when passed incorrect parameters or data
structures) and even more "holes" (where calling a system
function with deliberately incorrect parameters has a
reproducible if bizarre effect).

During testing of SMSQ and SBASIC, a large number of second
level bugs were uncovered in the JS ROMs. Many of these
showed up also in Minerva, none in SMSQ or SBASIC. From time
to time, users have uncovered a number of second level bugs
in SMSQ and SBASIC. All of these were entirely new and have
no connection with old QL ROM bugs: SMSQ and SBASIC are
entirely original!

Streamlining code has the effect of removing, altering or
introducing holes. It is not surprising, therefore, to find
that many of the holes that are exploited by some common
software, have either disappeared or been altered in Minerva
(giving rise to complaints of compatibility problems).

One such case is the xx.xxxxx SuperBASIC vector which is the
same in all QL ROMs. This vector is intended to be used with
data structures set up by the SuperBASIC interpreter. This
has three defined paths controlled by the value of one byte
(0, 2 or 3). Someone discovered that it could be made to
produce a bizarre effect if the passed a value of 1 in the
control byte. The resulting code fragment (which takes
longer than using a legitimate call) has been incorporated
into a utility, which has found its way into a large number
of programs for the QL. The streamlined Minerva code no
longer had this hole so a large amount of software stopped
working on Minerva. The Wizard did not manage to find the
real villain in the code, but succeeded in restoring
"compatibility" by setting a register to a value which it
would not normally have with SuperBASIC. This, in turn,
altered another hole and introduced different compatibility
problems.

In SBASIC, however, the hole never existed. Once the villain
code had been identified (a week's work) it was, therefore,
a simple matter of detecting the villain case and emulating
the hole directly. It was a waste of time and effort, and it
slows down SBASIC, but that's what it's about, isn't it?

The boundary between a bug and a hole is a very fine one and
if some software relies on a bug in the QL ROM do I need to
reproduce this bug? Unfortunately, the answer is sometimes
GRRRRRR YES.

Twice recently, I have received reports of "bugs" that have
appeared in the string handling in recent versions. These
"bugs" have been introduced into SBASIC to improve
compatibility with SuperBASIC (there are still three "bugs"
in SuperBASIC string handling which are not emulated in
SBASIC). Neither of these users was aware of that the bugs
existed in SuperBASIC: SBASIC is now being used where
SuperBASIC never went before.

"Whose Fault is it Anyway?"  One rather tetchy letter
complained that SBASIC was very fragile by comparison with
SuperBASIC: using a well-known piece of commercial software:
"SBASIC crashed". This was misdirecting the blame. As the
software was invoked correctly by SBASIC and as it never
returned to SBASIC, SBASIC could hardly be to blame.

This well-known SuperBASIC extension started off by trying
to identify a fragment of the QL ROM, and, when it could not
find any QL ROM code (there is none in SMSQ), it jumped to a
completely arbitrary location. BANG. The cure: I re-wrote
the extension and incorporated it (with improvements) in
SBASIC.

In fact, SBASIC is more robust in this respect than
SuperBASIC: error trapping is much more thorough (and
forceful). If it had happened in a daughter SBASIC: it could
simply have been removed with no harmful side effects.
(Perhaps I should implement a keyboard "restart" for Job O.)

Another difference between QDOS and SMSQ which might give
the impression that SBASIC is more fragile than. SuperBASIC
is the default error handling: QDOS carries on but SMSQ
stops to allow a debugger to be started. If the job is
already being monitored by a debugger, there is no
difference. In the normal state, however, allowing a job
which has produced illegal instruction or address errors to
continue could easily result in widespread damage to the
system data structures, possibly resulting in the loss of
part or all the data on a hard disk. SMSQ is, therefore,
much safer, even if jobs appear to stop more often.

Many programs compiled with the current version of Turbo are
wonderful examples of this. At the start of these programs
we find some code which sets a location in memory to O.
Several times later on, the value in this location is moved
to register A2 and then there is the instruction to move the
contents of address O (A2) to 04, D2 is compared against the
new value in D4 and then there is a conditional branch.

    MOVE.W     (A2),D4
    .......    .......
    SUB.W      D2,D4
    BLT.S      ......

On the QL the MOVE sets D4 to 3 so the operation of the code
is dependent on whether D2 is greater or less than 3.

On Atari STs modified for the old QL emulator, the MOVE sets
D4 to 24,622. The behaviour of this Turbo code will,
therefore, be significantly different on these STs as the
operation now depends on whether D2 is greater or less than
24,622.

On unmodified STs with a patched version of the JS ROMs, the
MOVE will cause a "bus error" which QDOS ignores and so
execution will continue without changing the value in 04. 02
is, therefore, compared against an unknown value: this will
give yet different, and rather unpredictable, behaviour of
Turbo programs.

On unmodified STs with SMSQ, the MOVE is trapped and these
Turbo programs just stop. It is possible to set a special
"Turbo mode" (PROT_MEM O) which emulates the QL ROM access
by setting 04 to 3 and continuing. The behaviour of Turbo
programs on these STs is, therefore, the same as on a QL:
SMSQ is more compatible with the QL than QDOS!

"I See no Ships"  While SMSQ with SBASIC marks a great
improvement in performance and capability over the old QDOS
ROMs, this has not been achieved without creating a few
problems. The original SMSQ and SBASIC had very few
intrinsic bugs, but many incompatibilities. Unfortunately,
it is one of the facts of life of computing that making any
changes to a existing software borders on vandalism. The
neat structure of the original conception begins to crumble
and soon each little "fix" risks introducing a host of new
problems. Fixing each one of these introduces more. It is a
tribute to Jan Jones original SuperBASIC conception that
during the early days of "active development" when new
features were being added every day, the ratio of changes to
bugs introduced was better than 10:1.

SBASIC is a much more complex piece of software which has
the disadvantage of being required to emulate all the
quirks of someone's first attempt at writing a BASIC
interpreter. It, therefore, starts off being not very neat
and it is prone to degenerate more quickly. SBASIC's ratio
of changes to bugs introduced is closer to 5:1 - small
enough to be convergent, but too large for comfort.

Fortunately, the bugs introduced from version 2.11
(experimental SBASIC) through version 2.25 (the first
"release" version) to version 2.42 (current at time of
writing) have usually been smaller than the ones they
replaced.

Although some compatibility problems with some hardware
variations remain to be resolved and there are one or two
program which still refuse to function with SMSQ, the
original aims for compatibility and performance have been
well exceeded and SMSQ is now establishing itself as a
living replacement for QDOS.

So, is SMSQ/E at last stable? The answer must be no. As more
and more people start using SMSQ/E there are more and more
requests for improvements (i.e. decreasing compatibility).
SMSQ/E has now passed the point of no return: there are more
requests for improved capability than for improved
compatibility. The current versions of SMSQ/E are at least
as reliable as any QL ROM version and are getting as close
to 100% compatibility as is possible while providing better
performance and more facilities.

SMSQ/E is a commercial product and as such needs to meet
users demands. If users require changes, and it is
commercially feasible to provide them, they will get them.
SMSQ/E cannot, however be developed in all directions at
once.

For software development, a 16 MHz 68000 based Mega STE (1
MIP with 2 Megabytes of memory running under SMSQ/E (my
"standard" configuration) is more than a match for a
"standard" 50 MIP 32 Mbyte workstation. A TT or a QXL on a
good 486 machine is more impressive still. The Gold and
Super Gold Cards have the same standards of raw performance,
but suffer from limited display capabilities, poor keyboard
and IO.

How much more is it reasonable to do with SMSQ which, by its
need for compatibility with a 10 year old computer, is
locked into a 10 year old design? Is there enough interest
in the type of operating system concepts pioneered by QDOS
to make it worthwhile producing a completely new system? The
future depends on your response.

A Snippet of Code

Here is a snippet of SBASIC that came from QL Today and is in the words of the author indispensible. There are many such bits of code. What are yours.

ffnm$ is a variable containing the complete file name ie Win1_SBASIC_Myfile_bas
This has been changed from the original listing as there is also a resident extension that also uses filename$ - the original variable used.

27280 DEFine FuNction Directory_Name$ (ffnm$)
27290 LOCal ch,d$(36)
27300 ch=FOP_DIR(ffnm$)
27310 IF ch<0 THEN
27320 d$=""
27330 ELSE
27340 d$=FNAME$(#ch)
27350 IF d$>""
27360 IF d$(LEN(d$))<>"_" THEN d$=d$&"_"
27370 END IF
27380 CLOSE#ch
27390 END IF
27400 RETurn d$
27410 END DEFine
27420 :
27430 DEFine FuNction Drive_Name$ (ffnm$)
27440 LOCal d$(36),ch
27450 d$=""
27460 ch="_" INSTR ffnm$
27470 IF ch>0:d$=ffnm$(1 TO ch)
27480 RETurn d$
27490 END DEFine
27500 :
27510 DEFine FuNction Pure_Filename$ (ffnm$)
27520 LOCal ch,d$(36)
27530 ch=LEN(Drive_Name$(ffnm$))+LEN(Directory_Name$(ffnm$))
27540 d$=""
27550 IF LEN(ffnm$)>ch : d$=ffnm$(ch+1 TO LEN(ffnm$))
27560 RETurn d$
27570 END DEFine
27580 :
27590 DEFine FuNction Extension$ (ffnm$,separator$,mxln)
27600 LOCal ch,c,ext$,f$
27610 REMark mxln is the maximum length of extension permitted
27620 REMark usually '_' or'>' plus 3 characters
27630 REMark separator$ is '_' (QDOS0 or '.' (PC)
27640 f$=Pure_Filename$(ffnm$) : REMark remove drive and directory
27650 ext$="":REMark extension string
27660 ch=LEN(f$)-mxln+1
27670 IF ch<1 THEN ch=1
27680 FOR c=LEN(f$) TO ch STEP -1
27690 IF f$(c) = separator$ THEN
27700 ext$=f$(c TO LEN(f$))
27710 EXIT c
27720 END IF
27730 END FOR c
27740 RETurn ext$
27750 END DEFine
27770 :

Launchpad 2.09

Arghh! Had a bit of insomnia last night and was on the QL at 3am. Broke Launchpad 2.09. How? By playing about with the MyQL settings to try to get Launchpad to start at the position on screen I want. What happened - setting the display to full screen size caused Launchpad to occupy the whole screen over riding the configuration. Fair enough. Now if I use the resize and move window tools I could place Launchpad in the size I want and where I want and get it to save this configuration, or so I thought. Nooo.The resize tool only works in one dimension - vertically but not horizontally! Ok. Change the screen size back. No that does not work either. Trapped with an oversized wrong positioned Launchpad. Arghh! Out with the backup of the harddisk and recover a previous configuration file. It would be nice to know the structure of the configuration file. Is it in the manual. Best to have a look. I still like Launchpad, but I have now reverted to 2.06 as it worked.

Any chance of the author seeing his way to a Launchpad 2.10 with these bugs fixed? If so let me know as I also have further sugestions for improvements.

Launchpad 2.09 vs Ghostscript

Why does launchpad always open its window in the top left corner of the screen. Is there any way to get it to start where you want it on boot? Does anyone know apart from disassembling the code to hack its window startup routines. Not elegant but I might do it.

Its a great program. Useful and colourful once some high colour icons have been added. Scores amongst my top ten most useful programs, but it is irritating that it cannot be made to start at another point on the screen.

Another gripe about another program is the Ghostscript QL port. The set up and usage instructions are virtually useless in my opinion. Anyway the portee does not want to admit that he compiled into the code his own directory structure. Very clever, not. If you don't like it the way it is, he says compile it yourself, I have supplied the sources he says. Yes, true but not in a easily usable way. No wonder few in the QL user world have admitted to using this bit of bloatware. The other laugh about it is that the author moans publically about the config blocks used in some QL programs, as he prefers environment variables, which can be used just as easily in QL Heaven. But here he is promoting software with an eclectic collection of printer, file conversion and graphics drivers all compiled together higgelty piggelty with odd names into the Ghostscript executable. What a joke. I should also add that parts of the ported Ghostscript are effectively broken as not all of the functionality work as specified in the supplied linux instruction file. Anyway if anyone wants to set up and use Ghostscript as there as still some things it can do usefully, let me know as I can help, having been there and done that. By the way it is a good source of Adobe fontfiles that can be converted to Proforma fonts with the Progs utility.

Finally the Launchpad manual is great. Thanks to Dilwyn Jones for the program.

How many graphics programs

Here is a list of some on my hard disk in no particular order, mainly but not exclusively GD2:

24bit_col
Grabber
Photon
UnGif
OpenWorld
BMP2PIC
CJPEG
DJPEG
PHOTO
pqiv
CoCo
QCP

Obviously there are more. Which do you prefer?

QL SuperBASIC the Definitive Handbook

A copy of Jan Jones book has just gone for £21-00 on ebay. I think Quanta used to sell their reprints for around £10-00.

QBasic

Something about software as promised. QBasic is a thing designed to be used with QD to parse, QSAVE and liberate the SBASIC file being edited in QD. If this is gibberish I guess you don't use a QL in any form. Have a look at Dilwyn Jones site. Just type Dilwyn Jones and QL into Google and click on I'm feeling lucky. I promise nothing bad will happen to you or your PC.

SBASIC is the basic language for modern QL systems but can also be retro fitted to older systems which have SuperBasic built in. SBASIC and SuperBasic are probably some of the most important bits of software for QL systems and one of the reasons the QL has not passed on to QL Heaven. Both are powerful enough to allow the development of major applications such as Turbo, the Editor, Launchpad and Liberator. As such they continue to be an educational tool in programming and a source of new development for QL systems. Enough background.

QBASIC does what it says on the box and I now can't do without it. I find this amazing because what it says it does does not seem that interesting. After all you can compile with Qliberator quite easily without QBasic. But adding the luxury of a seamless IDE which then reduces development time considerably makes the feel of the process completely different.

One or 2 quirks with QBasic. The parser is not as smart as the SBasic parser. It does not spot incorrect line numbering, so that if when editing a program, copying and pasting lines you end up with 2 line numbers the same, QBasic and Qliberator will hang but not crash. You can remove line numbers but that makes data statements difficult. If the basic file contains a corrupt character, that is a non printable character, QBASIC will refuse to compile. Fair enough, but other than halting it gives no indication of what has gone wrong. The only way to find out quickly is to load the file into the SBasic editor which quickly locates the line or lines with a MISTake marker.

Setting it up is easy, just configure it using menu config and LRESPR it in the boot. Then either hot key a startup command string for QD to tell it to use QBASIC or launch it through Launchpad which will also pass a command string. I prefer Launchpad as I can have 2 icons one for QD with QBASIC and one for QD with SBasic yet the same QD program file but each QD configured through the command line for the job in hand. Neat

Hot keys now there is something that is significantly complex and powerful on QL systems.

Thought for the day. Is it possible to put a program to sleep on a hotkey but without creating a button in the button frame, or anywhere else. Off to the EE (extended environment) manual.