Wifi Printing almost from Q68 and Qx0

 This blog has been quiet not because interest in QDOS, smsq/e and things QL has waned but because all available spare time has been used up in writing some software that allows a QL system with a reliable serial port to print to the Wifi printer here at QL heaven. The solution is similar to the RetroPrint project but is mainly software based, although a RPi is still needed for the Wifi part.

Parts required are a RPi, a null modem cable to a serial Pi hat or a serial to USB cable. The rest is software as follows:

On the RPi connect the RPi to the Wifi network, and install the RPi serial port on its expansion pins or on one of the USB ports. This can be done through the raspi-config program on an upto date installation. Then install the CUPs printer driver, good guidance for this can be found in early Magpi magazines volumes 11 and 12.

Then install the python cups bindings and next write the python software for the RPi to catch and send files transmitted via the serial port to the printer and write the SBasic to send files through the serial port of the QL. 

 

 Simple? No not really. Many document files on the QL are text, some are html and many are Quill doc files. The good news is that CUPs can handle text and html and postscript files natively, so send these with the appropriate commands and viola they print out. 

 

Quill docs are something else. There are a number of Quill doc stripper programs  but typically these lose text formatting which is unsatisfactory.

So a Quill to postscript filter was constructed based on Marcel Kilgus MPS_bas program and the result today :

 

It doesn't look like much and the formatting while acceptable is not exactly as in the original.

Anyway using this as a printing system gives quite good contol of printouts.

 

 The system is still a work in progress as CUPs has Courier, Times , Helvetica fonts built in.

EddIcon Resized

It has been some time since there was time to update this blog. That does not mean that nothing has been happening in QL heaven. Here is a glimpse at some of things happening here. A Q68 was acquired and one irritation was the EddIcon could not run on the 512x384 16 bit colour resolution screen as it only used a window 640x480. So after some devling about the innards of EddIcon here is a revamped version that has 3 window izes. The original, a medium sized window that fits in to 512x384 and a small window suitable for 512x256. Besides the window changes there have been some other changes to the interface and functionality. Sprites can now be saved out with RLE compression, as mode 64, 32 and mode 4. Mode 4 sprites can also be saved as a series of data statements to be incorporated in to QPTR superbasic. There are still some bugs in the colour handling routines so its not for release yet.

Other things that have been looked at are a simplified method of automatically creating and editing simple Qascade menus., reading and writing to FAT16 formatted CF cards on the Q60 and printing through the serial port via a RPi, Python and CUPs to a WiFi printer, a bit like the retroprint project. The difference being that CUPs handles text, HTML, and postscript. All of these modes work on the system. Quill doc files still have to be converted.

All these things might be looked at in future posts but at the moment here is EddIcon in 3 sizes.

 

QD and the QBASIC extension

There has been some confusion on the QL Forum concerning the F10 button associated "thing". QD comes with the QD/SBAS thing or it may be that this thing is part of smsq/e but however it is incorporated QD comes with it installed once the QD config block is configured to us this thing.

What the QD/SBAS thing does is to parse the SBASIC program being edited in QD and then execute the SBASIC program as SBASIC. Writing programs to be executed via QD/SBAS has a few quirks. For example if SBASIC programs are run from the interpreter of executed via the QPAC files thing, or via Qcascade if needed SBASIC windows #0,1 and 2 do not necessarily need to be explicitly opened as the program is wrapped in an SBASIC interpreter that already has these windows open. If launched from QD via the SBAS/QD thing then window#0 as a minimum needs to explicitly opened for the program.

The QBASIC extension thing is a completely different animal. When attached to the QD F10 button it will pass the program being edited to the QLiberator compiler (v3.35 and above) and either compile it or exec the compiled program directly.  The compile options to be passed to QLiberator can be modified at this stage before compilation if needed.

QBASIC is a separate extension than needs to be LRESPRed in the QL's boot program. It needs to be configured to find where QLiberator is stored on the system. QD itself needs to be configured to use the QBASIC thing, either in its config block or passed as a parameter when QD is executed as shown in the Q-DOCK program settings.

If there is a need to have both the QD/SBAS thing and SBASIC handy then an easy way to do this is to have 2 copied of QD  on one of the program launcher menu systems with one configured for QD/SBAS and the other for QBASIC.

The only was to pass a program between them is either via the scrap, less than 32k in size or as a file.

Recently QD has become freeware but the copyright status of QBASIC is not known although as an app it has no use other than as an extension to QD.

File Handlers for QL systems

A recent addition to the list of QL software file managers,  QLCommander written by Andrew of the QL Forum, made us here think of all the other similar programs also available.

There are too many to list but include former commercial programs like QTOP and CUEshell :

 The ubiquitous QPAC2 files thing:

 And programs like QcdEze for CDROMs :

And so on. It is amazing that so many of them written sometime ago adapt so well to newer emulators and hardware developments of the QL.

Hardware Renaissance?

There has been an upsurge in QL related hardware developments over the past 12-36 months (excellent) with several coming to market and several seeming to be still in development and one limited by the need to find legacy chips.

Supplied by Tetroid ( based in the Russian Fedeartion) there are new Goldcard clones, Trumpcard clones, Qubide interfaces and back planes and recently when he managed to track down some obsolete chips a handful of SuperGoldCard clones were poduced and sold. Tetroid seems to have produced so many new cloned expansion cards that the bottom has fallen out of the market in used Goldcards and other used memory expansion cards as shown by the multiple listings of a number of expansion cards including an original GoldCard, at a price reduced from that achieved previously, on ebay.

In terms of new original hardware there is the Q68. How many have been sold is not known here but as each batch seems to have been around 40 units and at least 3-4 batches have been mentioned on the QL Forum the figure could well be in 3 digits. So that is a success.

There also seems to be a direct QL clone/evolution in the discussions around an issue 8 motherboard on the QL forum. This seems to be driven by Dave and Nasta and might be on the market sometime this year. Again this seems to have generated a lot of interest.

For those still running QLs based on the original motherboard Marcel Kilgus reported in his blog that he is working on a solution to the problem of displaying the QL screen on a modern TFT monitor see.

There is also the Retro-Printer project from RWAP. This is not specific to the QL but will allow a range of retro computer systems including the QL to print to modern printers.

In addition from the author of QPC2 came QL-SD an adapter for SD cards fitted in to one of the original QL microdrive slots.

What next, will Tetroid produce some sort of an ultra gold card upgrade of his GoldCard clone, will the LAN drivers and TCP/IP stack be released for Q68 or  what? The impression here at QLheaven is that there does not seem to have been this level of new hardware activity since the Q40/Q60 of the late 1990.

Apologies to anyone whose hardware project has been inadvertently missed off this review. 

Some Strange Things About Sprites

Qdock on a Q68 512x384 resolution and 16 bit colour.

Looking at the excellent sprites supplied with Dilwyn Jones Qdock program launcher QLheaven found found one surprising thing. The mask/alpha channel of his compressed sprites were run length encoded for 2 bytes for each pixel in the mask/alpha. Was this correct?

Asking on the QL Forum about this brought responses from Dilwyn and Marcel. Dilwyn thought he had used Marcel's png to sprite converter program.

 Marcel stated that only one byte per pixel was ever needed for the mask/alpha and this was also the information in the QPTR manual. Checking the .png converter program the RLE sprites produced by it had only one byte per pixel for the alpha channel whether the sprite was in mode 32 or mode 64. The version of the png converter program here is 1.01 from 2005, but the latest version is 1.04, but has not been tested here as 1.01 works. So far so good, although where Dilwyn made his sprites with 2 bytes per pixel for the mask/alpha is a puzzle unless this was a bug introduced in to later versions of the sprite converter program!

smsq/e is not troubled by the extra data nor is EddIcon_obj the sprite editor used here, or SQRView_obj. SQRView is another program that can add RLE compression to sprites and it also outputs sprites with one byte per pixel in the mask/alpha section when compressed. On the other hand compressed sprites output from SQRView were found to have an extra trailing 4 bytes of zeros padding the pattern and a slightly different RLE compression of the mask. How strange. This was discovered using the ex Digital precision file comparing program "Compare".

 The top sprite View3c.spr was a compressed sprite produced by the .png converter program, while the bottom sprite, View3.spr compressed sprite was produced SQRView from the uncompressed version of the same sprite produced by the same .png sprite converter. As can be seen the lower sprite is 8 bytes longer. Both the are displayed correctly by smsq/e as the offsets for the pattern and mask data are correct for each sprite.

Finally the reason for this interest here is a need to shrink sprites to reduce their size for use in another project, so a small basic compression routine has been written to compress sprites on the Q68. Comparing compression with the sbasic program with the same test sprite from the .png converter things are as they should be.

Looking For Sprites and Reviewing them

A belated Happy New Year to all QLers from QL Heaven.

When there are a lot of sprites, here at QL Heaven, there are over 2500 it can be difficult to remember what each can be used for. Rather than using one of the existing sprite viewer programs which can be downloaded from here as sprites might be separated in to different sub directories to help manage sprites from different sources or having different modes or sizes, while the existing sprite viewers typically show a single directory's worth.

So here is a QuickView sprite viewer. It can be launched via FI2 using the QPAC2 files thing. The selected sprite is displayed with its size and mode in a window that adjusts fro the size of the sprite up to the maximum resolution of the screen in use.

The file name of the sprite is stored in an smsq/e History device so that if multiple sprites are viewed from differing directories they may later be reviewed together as shown below. While the folder icon on QuickView launches a QMenu file requester thing all sprites to be reviewed do not need to be seen during the one session with QuickView. The History device holds the complete file names of all files viewed while the Q68 is switched on so it is possible to view a sprite or 2, close down QuickView, do something else and then restart QuickView and review all sprites viewed by QuickView since the system was switched on.

It is still a work in progress as tools to select sprites and write to a saved file list to use in a sprite library generator program which can be found here have yet to be added, and also a wild card search of a device for all sprite files to find forgotten sprites. Although this can be mainly done with WildSearch
 

More on reading microsoft long file names on QLs

This time it was the turn of PC formatted floppy disks. Those who use smsq/e as opposed to QDOS will know that floppy disks, DD or HD formatted on a PC can be read and written to by smsq/e. What can be frustrating is that files written on the floppy by a PC can have a long file name (LFN) written on the disk by the PC but when read on the QL side under smsq/e only the DOS short file name can be read.

A long file name on a PC can have up to 255 unicode characters including spaces, while a short file name or DOS 8.3 file name has a maximum of only 8 uppercase characters for the file name and 3 characters for the file extension and that's it. Windows has a scheme to shorten long file names to 8.3 DOS names, so that all files written to disk under windows always have an 8.3 DOS file name even if they also have a long file name. Problems arise with the shortened names as if there are a series of files whose names start with the same 6+ characters then a maximum of 6 characters will be used followed by ~ and then a number. If the numbers go in to two digits then only 5 characters can be used as only a maximum of 8 is ever allowed in the name part of the 8.3 DOS name.

Typically the long file name precedes the 8.3DOS name  in the directory but just in case that does not happen a check sum is calculated from the 8.3 DOS name and stored in each segment of its long file name, to confirm that they both belong to the same file. This is important a when a file is deleted under widows the first character if the 8.3 DOS name is over written with the value of 229 to indicate that the file has been deleted but nothing happens to the long file name segments unless they are over written in a future write of a file name to the directory.

So here is what happened when QL Heaven looked at a HD floppy that had been used for some time to transfer files from a PC to a QL system.

 The first table contains a number apparent files with LFNs that do not have any file information as their 8.3 names have been erased.

Then when check sums are used to link LFNs  to 8.3 names everything is tidied up.

The process of calculating the check sum is arcane and interestingly can only produce values from 0 to 255 as there is only a single byte to hold the value in the LFN section. In directories with hundreds of files what are the odds of 2 files having the same check sum?

Here is the calculation in SBASIC.

18750 DEFine FuNction MakeCheckSum (sum$)
18760 x$=BIN$(CODE(sum$(1)),8)
18770 FOR i= 2 TO 11
18780 x$=RotRt(x$) : ans%=BIN(x$) : nxt%=CODE(sum$(i)) : x%=ans%+nxt% : x$=BIN$(x%,8)
18790 END FOR i
18800 x%=BIN(x$) : RETurn x%
18810 END DEFine

18820 :

18830 DEFine FuNction RotRt (x$)
18840 r$=x$(8) : m$=x$(1 TO 7) : ans$=r$&m$ : RETurn ans$
18850 END DEFine

When Source Code is provided

Compare in GD2 colour integrated with File Requestor SBASIC from QLWorld compiled with Turbo.

PERFECTION by Digital Precision perhaps not so perfect.

For those QL users who are using an emulator or repalcement QL motherboard system such as a Qx0, a Q68 or an Aurora based system and make use of the higher resolution screens none of the word processors, Xchange(Quill), Text87plus4 or Perfection are ideal. All now have patches that allow them to use resolutions higher than 512x256 but each has it's limitations.

On the Q68 here a word processor that handles the defacto standard QL Quill format documents is preferred. All 3 can do this. In addition the program needs to be able to accept and open a document via FileInfo 2. Now Xchange(Quill) can do this as can Text87plus4 with the correct commands supplied to FI2 to enable the process. Perfection does not seem to be able to do this. In addition the program also need to be able to adapt to a higher resolution than 512x256. Xchange can do this but only to 512x512 which is inconvenient if the screen vertical resolution is less than 512 and more than 256. On the Q68 512x364 is preferred to make full us of 16bit colour. Text87plus4 can adapt but it's user interface is awful. Perfection with the patch that upgrades it to v6a12 can adapt to almost any vertical resolution through its bespoke configuration system but it cannot open a file via FI2, unless there is a way unknown to QLHeaven hidden in its wordy manual. So here is a way to tweak Perfection to allow it to open _doc files via FI2. A startup macro that instructs it to load its configured default document must also be created as Perfections default macro. Below is the SBASIC wrapper that needs to be compiled and launched via FI2 to make it all happen :

This short program patches the desired file into perfections configuration block after a copy is made to the ram disk, to avoid inadvertently corrupting the master copy.

Obviously Sdev$ and Ddev$ would need to be changed for other systems or could be changed by a config block if one was added.

Here is the system in action :

SerNet and DEV an excellent combination to connect a floppy drive to a Q68

The Q68 uses SDHC cards both as its hard disk like storage and as it's removable media.

There are (currently) no other physical storage devices for the Q68.

However it does have a serial port. So with another QL type system ( with a decent baud rate) connected via a null modem cable and using Sernet and the dev device the following SBASIC command :

DEV_USE 1,S2_FLP1_

a SBASIC or using the files thing  can now access flp1_ on the second QL second identified as S2 by sernet.

A powerful combination of  existing software enhancing the functionality of new hardware.

Answer to a question on the QLforum

In answer to polka's question in the QL Forum, here is a snippet of my boot code that allows the selection of multiple hardware configurations using a single boot file and to load alternative operating systems if desired.

The key elements are a timed loop that will start a default configuration if nothing is selected during the timeout period. Otherwise if an alternative configuration is chosen a file that indicates the selected cofiguration is written to the primary partition of the hard disk. This is used after the configuration of smsq/e is loaded and started by the boot file to set up the drivers and programs for the previously selected configurations.Nothing is written to these file but they could be used to add different adaptions to the boot.  

1000 REMark Overwrite the ROM SMSQ/E 2.91

1010 :

1020 REMark -- Mount Win2_,Win3_& Win4_ to make immediatly available --

1030 WIN_DRIVE 2,0,1 : WIN_DRIVE 3,0,2 : WIN_DRIVE 4,0,3 : ft=0

1040 REMark for the moment DONT automatically mount all drives except backup

1050 REMark AS DISK IS NOT ATTACHED

1060 REMark for the 1ST IDE SLAVE channel

1070 REMark WIN_DRIVE 5,1,0:WIN_DRIVE 6,1,1:WIN_DRIVE 7,1,2:WIN_DRIVE 8,1,3

1080 REMark for the 2ND IDE MASTER channel

1090 REMark WIN_DRIVE 5,2,0:WIN_DRIVE 6,2,1:WIN_DRIVE 7,2,2:WIN_DRIVE 8,2,3

1100 :

1110 WINDOW #0;SCR_XLIM(#0),SCR_YLIM(#0),0,0:CSIZE#0,0,0:INK#0,2:PAPER#0,0:CLS#0

1120 IF PEEKS$(2,3)='RES': GO TO 1930

1130 :

1140 WINDOW #1;256,128,128,64:INK#1,4:PAPER#1,0

1150 PAPER#1,0

1160 INK#1,7:PRINT "F1";:INK#1,4:PRINT " for SMSQ/E 3.33 (QMAC) + FAT32"

1170 INK#1,7:PRINT "F2";:INK#1,4:PRINT " for SMSQ/E 3.33 (QMAC) + QUBide"

1180 INK#1,7:PRINT "F3";:INK#1,4:PRINT " for SMSQ/E 3.33 (QMAC) + Win5-8"

1190 INK#1,7:PRINT "F4";:INK#1,4:PRINT " for SMSQ/E 3.33 + FAT16"

1200 PRINT

1210 INK#1,7:PRINT "F5";:INK#1,4:PRINT " for Test Versions of SMSQE & QPAC2"

1220 INK#1,7:PRINT "F6";:INK#1,4:PRINT " for QDOS Classic"

1230 INK#1,7:PRINT "F7";:INK#1,4:PRINT " for Mode4 SMSQ/E 3.32"

1240 INK#1,7:PRINT "F8";:INK#1,4:PRINT " for SMSQE Compile Enviroment"

1250 INK#1,7:PRINT "F9";:INK#1,4:PRINT " for SMSQ/E 3.13 mode 4 and PSION Chess"

1260 PRINT

1270 PRINT "   Timeout SMSQ/E 3.33 (QMAC) Win1-4 only"

1280 :

1290 timeout=DATE

1300 timeout=timeout+15

1310 REPeat lp

1320 IF PEEKS$(2,3)='RES':EXIT lp

1330 key=CODE(INKEY$(#0))

1340 SELect ON key

1350 :

1360   =232 : REMark F1 overwrite the ROM with SMSQ/E 3.33

1370          OPEN_OVER#3,"Win1_DoMountFat32":CLOSE#3:key=0

1380          AT#0,2,12

1390          PRINT#0,"INSERT CADDY with FAT32 CF card. Press ANYKEY"

1400          PAUSE#0

1410          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq333_ROM"

1420 :

1430   =236 : REMark F2 go with SMSQ/E 3.33 + QUBide

1440          OPEN_OVER#3,"Win1_DoQUBide":CLOSE#3:key=0

1450          AT#0,2,12

1460          PRINT#0,"INSERT CADDY with QUBide CF card. Press ANYKEY" : PAUSE#0

1470          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq333_ROM"

1480 :

1490   =240 : REMark F3 go with SMSQ/E 3.33 and Wins 5-8

1500          OPEN_OVER#3,"Win1_DoMountAll":CLOSE#3:key=0

1510          AT#0,2,12

1520          PRINT#0,"INSERT CADDY with HD containing Win5-8. Press ANYKEY" : PAUSE#0

1530          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq333_ROM"

1540 :

1550   =244 : REMark F4 Use the new version of SMSQ/E with 3.33

1560          OPEN_OVER#3,"Win1_DoFAT16":CLOSE#3:key=0  : AT#0,2,15

1570          PRINT#0,"INSERT CADDY with FAT16 CF card. Press ANYKEY" : PAUSE#0

1580          IF PEEKS$(2,3)<>'RES':LRESPR "WIN1_SMS_Q40smsq333_rom"

1590          REMark IF PEEKS$(2,3)<>'RES':LRESPR "WIN1_rom"

1600 :

1610   =248 : REMark F5 Test version of SMSQ/E

1620          OPEN_NEW#3,"Win1_TestQPAC2":CLOSE#3:AT#0,2,12

1630          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMQ_smsq_q40_testrom"

1640 :

1650   =234 : REMark F6 load QDOS Classic

1660           LRESPR Win1_Classic_SoftRom_rext

1670           COPY Win1_CLASSIC_CLASSICr_rom TO ram1_CLASSICr_rom

1680           PRINT#0,"Wait for Drive Light to go out, then Press Anykey to continue"

1690           PAUSE

1700           SOFTROM ram1_CLASSICr_rom

1710 :

1720   =238 : REMark F7 boot Mode 4 from Win1_

1730          OPEN_NEW#3,"Win1_Mode4":CLOSE#3

1740          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq332mode4_ROM"

1750 :

1760   =242 : REMark F8 Try SMSQ/E compile environment

1770          OPEN_NEW#3,"Win1_CmpEnv":CLOSE#3

1780          BEEP 5000,0

1790          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq333_rom"

1800 :

1810   =246 : REMark F9 boot 3.13 into mode 4

1820          OPEN_NEW#3,"Win1_psionchess":CLOSE#3

1830          IF PEEKS$(2,3)<>'RES':LRESPR "WIN1_SMS_q40mode4_rom"

1840 :

1850   =250 : REMark F10 smsq/e 3.33

1860          IF PEEKS$(2,3)<>'RES':LRESPR "Win1_SMS_Q40smsq333_rom"

1870 :

1880 END SELect

1890 IF DATE>timeout

1900      key=0:IF PEEKS$(2,3)<>'RES':LRESPR  "Win1_SMS_Q40smsq333_rom":EXIT lp

1910 END IF

1920 END REPeat lp

1930 :

1940 drv$="WIN1_"         : REMark Boot default directory

1950 REMark -- LOAD Enviroment Variable support early --

1960 LRESPR(drv$&"env_bin") : REMark used by all c68 progs

1970 :

1980 errt=FOPEN("Win1_DoMountFAT32")

1990 IF errt>0

2000    CLOSE#errt:DELETE "Win1_DoMountFAT32"

2010    WIN_DRIVE 5,2,0,0,"QXL.WIN"

2020    OPEN_OVER#3,ram1_Win5dump: DIR#3,Win5_:CLOSE#3:DELETE ram1_Win5dump

2030    SETENV "HDTYPE=FAT32"

2040 END IF

2050 :

2060 errt=FOPEN("Win1_DoMountAll")

2070 IF errt>0

2080    CLOSE#errt:DELETE "Win1_DoMountAll"

2090    WIN_DRIVE 5,2,0:WIN_DRIVE 6,2,1:WIN_DRIVE 7,2,2:WIN_DRIVE 8,2,3

2100    SETENV "HDTYPE=ALLWINS"

2110 END IF

2120 :

2130 errt=FOPEN("Win1_DoFAT16")

2140 IF errt>0

2150    CLOSE#errt:DELETE "Win1_DoFAT16" : WIN_DRIVE 5,2,0,0

2160    SETENV "HDTYPE=FAT16"

2170 END IF

2180 :

2190 errt=FOPEN("Win1_CmpEnv") : IF errt>0 :CLOSE#errt:LRUN Win1_Bootsmq_bas

2200 :

2210 errt=FOPEN("Win1_psionchess")

2220   IF errt>0

2230     CLOSE#errt:DELETE Win1_psionchess

2240     EX Win1_PRG_PSION_Chess_exe:STOP

2250   END IF

2260 :

2270 errt=FOPEN("Win1_Mode4")

2280 IF errt>0

2290    CLOSE#errt:DELETE "Win1_Mode4"

2300    REMark LRESPR("Win3_QTOP_thorgold_bin"):EX Win3_QTOP_TINDEX : STOP

2310    LRUN Win4_StartUp_Qx0boot

2320 END IF

2330 :

2340 TK2_EXT:IF VER$(1)>2.95 AND VER$(1)<=3.03:Set_Mode4_Colours

2350 key=KEYROW(7):REMark press "x" to load ProWess

2360 :

2370  IF VER$(1)<3 .03="" span="">

2380    LRESPR ('WIN1_CACHEMODES_rext') :WRITETHROUGH

2390    REMark LRESPR ('WIN1_MOVP4SMSQ60_cde')

2400 END IF

2410 REMark although MOVEP instruction removed from SMSQ/E 3.00 on there are some in Text87

2420 REMark so LRESPR 060 patch anyway

2430 LRESPR ('WIN1_MOVP4SMSQ60_cde')

2440 :

2450 IF VER$(1)=2.98 AND (key=0 OR key=8):DISP_SIZE 1024,512

2460 IF VER$(1)=2.99 AND (key=0 OR key=8):DISP_SIZE 1024,512

2470 :

2480 IF key=64:STOP

2490 :

2500 REMark -- Set Some Default Devices --

2510 IF SCR_LLEN>=128

2520   PWSDIR$="Win1_PWS_"  : REMark ProWesS default directory

2530 END IF

2540 DATA_USE "WIN1_" : PROG_USE "WIN1_"

2550 DEV_USE 1,Win1_PRG_EDT_ : REMark Editor 2.05 directory

2555 DEV_USE 8,FLP1_ : REMark make a device for CUE shell on Q68 to access a floppy

2560 :

2570 REMark set Colour Theme

2580 IF VER$(1)>=3.03:EX Win1_COLOUR_CoCo_setconf_bas;"Win1_COLOUR_CoCo_Themes_greys_thm,0"

2590 IF VER$(1)>=3.03:EX Win1_COLOUR_CoCo_setconf_bas;"Win1_COLOUR_CoCo_Themes_cream_thm,1"

2600 IF VER$(1)>=3.03:EX Win1_COLOUR_CoCo_setconf_bas;"Win1_COLOUR_CoCo_Themes_blueme_thm,2"

2610 IF VER$(1)>=3.03:EX Win1_COLOUR_CoCo_setconf_bas;"Win1_COLOUR_CoCo_Themes_copper_thm,3"

2620 :

2630 REMark set up window colours

2640 tcol=0

2650 IF VER$(1)>2.95:COLOUR_PAL:tcol=176

2660 WINDOW #0;SCR_XLIM(#0),SCR_YLIM(#0),0,0:CSIZE#0,0,0:INK#0,4:PAPER#0,tcol:CLS#0

2670 :

2680 BGCOLOUR_24 $919FCC : REMark BGCOLOUR_24 $AAAAFF : REMark BGCOLOUR_24 $878787

2685 REMark BGCOLOUR_24 $0

2690 : REMark Can we use ProWess

2700 errt=FOPEN("Win1_DoProWess")

2710 IF errt>0 : key=8 : CLOSE#errt:DELETE Win1_DoProWess

2720 IF SCR_LLEN>=128 AND key=8

2730   IF PWSDIR$(LEN(PWSDIR$))<>"_" THEN PWSDIR$=PWSDIR$&'_'

2740   LRESPR PWSDIR$&"ext_dll_rext"

2750   LRESPR PWSDIR$&"ext_syslib_rext"

2760   LRESPR PWSDIR$&"ext_global_rext"

2770   LRESPR PWSDIR$&"ext_PWbasic_rext"

2780   dd_err=0 : REMark for DATAdesign error trapping

2790 END IF

2800 :

2810 :

2820 REMark -- LOAD Extended environment extensions --

2830 IF VER$(1)>3.02

2840   LRESPR(drv$&"menu_rext")

2850   errt=FOPEN("Win1_TestQPAC2")

2860   IF errt>0

2870     CLOSE#errt:DELETE Win1_TestQPAC2

2880     LRESPR(drv$&"QPAC2_test")

2890   ELSE

2900     REMark LRESPR(drv$&"QPAC2_patch")

2910     LRESPR(drv$&"QPAC2_145a")

2920   END IF

2930 ELSE

2940   LRESPR("Win1_PRG_QD98_Menu_rext_old")

2950   LRESPR("Win1_TOOLS_QPAC2_Qpac2_139")

2960 END IF

2970 LRESPR ("Win1_QPTR")

2980 :

2990 REMark - Any more resident extensions?

3000 REMark --LOAD SERNET --

3010   BAUD 2,115200  : SER_ROOM 2,4096

3020   LRESPR("Win1_PRG_SERNET_sernet_rext")

3030   SNET 2

3040   SERNET

3050 :

3060 REMark install PFF virutal device whatever

3070 LRESPR ("Win1_PrinCtrl_PFF_bin")

3080 :

 and so on for loading extensions.

Reading Long File Names on FAT formatted SD cards

FAT drivers have been embedded in smsq/e for some time. Initially FAT12 for DOS formatted floppy disks and now FAT16 for the Q68. One frustrating thing about the drivers is that they only support the DOS short file name naming convention of 11 characters. This truncates names and makes it difficult to identify files in a list of similarly named files as shown.

The conventions for constructing LFNs can be found on the internet so after a bit of SBASIC work here is a first iteration of a menu system to manage files via their LFN on FAT 16 formatted disks.

The interface still needs a bit of work.

Multiple files can now be copied, moved or deleted from the FAT16 formatted SDHC card using their LFNs.

Qcascade Menu Editor for Q68

After some more work the mini menu editor for Qcascade has reached operational capability.
The idea of MenuEdit_QCSCDE_rc_bas and Make_Qcascade_rc_bas was to simplify and make more flexible the creation of small menus for use with Qcascade. As explained in the previous post the Qcascade _rc file and all the applications that will feature on the menu are located in a directory called APPS on win1_. EX Make_Qcascade_rc_bas, ideally from the Qcascade menu, and it will create a simple qcascade_rc filr incorporating all the files in the APPS directory. Next once the
 basic _rc file has been created EX MenuEdit_QCSCDE_rc_bas to embellish the menu derived from the _rc file with additional discription of the featured files if required. To add files to the menu add to the APPS directory and EX Make_Qcascade_rc_bas to update the _rc file, and that's it.

Writing MenuEdit_QCSCDE_rc_bas with the QPTR toolkit has not only refreshed my knowledge of this amazing toolkit but has also been a major learning experience as although I have written a number of QPTR based programs previously It seems I have only scratched the surface of what can be done with QPTR. Thanks also to Wolfgang Lenerz programming QPTR series in QLToday from the July/August 2002 issue through to the August/October 2004 issue.

Qcascade Menu Editor a work in progress for the Q68

There are now a plethora of free front ends for QL systems, many formerly commercial programs are now freeware. Several such as Launchpad, QDock and Go are from Dilwyn Jones. Then there is QTOP from CWO and Cueshell and QDT. There are also the more complex to customise ProWess and Proforma. Some require a bit of customisation but those from Dilwyn Jones are usually set up through the familiar config block and menu config and the point and click with the program. Where does this leave an old program like Qcascade, a drop down menu system from the 1990s written in C and using environment variables and a configuration script. The configuration script can be quite a tortuous process to set up especially if all the potential complexity of the software is used. As a result once configured it is not one that encourages change and adaption.

Acquisition of a Q68 has resulted in a new look at the use of Qcascade in the set up of this system. The Q68 system with 8 QXL.win files on SDHC card as "hard drives" has the potential to have access to up to 2-4 GB of files depending on the size of the QXL.win containers. The Q68 comes with a boot file for QDT and QDock as alternative desk top front ends. Speed on the Q68 system is dependent on screen size and colours used. Here there is a Q60 so for compatibility the 512x384 16 bit colour resolution works best with a speed that is similar to a SGcard/Aurora set up.

Given that Qdock had been chosen for the main front end it seemed that the best role for Qcascade would be to provide a menu of little apps that might be used to help with other tasks. As there was plenty of disk space programs were copied in to a directory on Win1_, neatly called APPS_.

A SBASIC program called "Make_QCSCDE_rc_bas" was created. When run this program scans the APPS_ directory and creates a new _rc file for Qcascade. To add programs to the menu, copy the program to the APPS_ directory and run "Make_QCSCDE_rc_bas"., place the mouse over the Qcascade button and press ESC and next time the menu is used the new app is on the menu. To remove - delete the program from the APPS_ folder and rebuild the menu as before. To make it really easy copy "Make_QCSCDE_rc_bas" to the APPS_ folder and run it from the menu. Simple.

Anyway here are 2 screen dumps.  One of the menu, and one of the next part of the project a pointer driven menu editor.Both programs have been written using QPTR 0.14 and show the use of 16 bit WMAN colours.

Q68 in QLHeaven

A Q68 is here at last. It is a lovely QL replacement/development. Loads of memory, a 68000 compatible processor emulation making loads of old software run well, 16 bit colour and a range of screen modes that all display well on flat screen monitors. It comes supplied with a 4 GB SDHC card containing 8 QXL.WIN type hard drive files absolutely loaded with freeware software. The super QDock front end comes as part of the package.

The preferred display here is 16 bit mode 33 512x384 giving high colour compatible with modern software, a slighly larger display than the original QL and a speed that is the same a superGoldCard QL or slightly faster. All in all a super QL system. More later.

More Stuff for QLers - are things hotting up??

Recently CueShell was released as freeware. This is not a program that QLHeaven ever thought to buy, mores the pity. The down loadable demos of the program did not do the program itself justice and so did not attract attention from this quarter. But now the full version is available and what a useful program. The only downside is that  the colours it can use remain locked in to the old mode 4 colours but even so on a modernish QL system it can be quite colourful.

Dilwyn Jones Q-Dock is also now freeware.It is an impressive development of Launchpad also now freeware.

On the hardware side of things the Q68 seems to be selling well.

There are also Qubide, Goldcard, Trumpcard and Backplane clones from Tetroid - see sell my retro. 

The Qubide hard drive roms have been updated to v3.10 with the Qubide drivers becoming part of smsq/e.

And Dave from Austin Texas on the QL forum has been discussing many new hardware ideas.

One thing there has been less of are 2nd hand QLs and peripherals for sale on ebay. While in the past there have been 2 or 3 pages or more of items for sale now there is only one and prices do seem to be going up. Does this mean that people are now hanging on to their old QLs as support for the system has been growing in the QL forum?   

Finally  there has been discussion of the future of the Q60 with a sadly heated exchange with the designer of the Q60 provoked by another longstanding QL figure.

Looking through old floppy disks

Here in QL Heaven there is a store of old commercial and PD floppy disks for the QL, both DD and HD along with a few ED. What is on them is mainly unknown. The floppy disk labels tend to indicate only the main content so there can be surprises sometimes. Looking through the disks for something else this intriguing disk was discovered:

It had not been well looked after. Initially it would not read on the ED drive on the Aurora but the HD floppy drives on the Q60 were up to the job.

 The file that was interesting was the smsq_con. What was this? Menuconfig showed that it was an original replacement screen driver for smsq/e for the Aurora and interestingly is seemed to suggest that some work had been done on the colour screen drivers even at that stage. How it should be used is unknown as there is no documentation. Could there be rudimentary 8 and 16 colour drivers in the file? Who knows.