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