Pointer Environment

Pointer menu

Pointer Environment And Mice On QDOS

A QIMI mouse and interface While the Pointer Environment is built into the SMSQ/E variant of the operating system, QDOS needs us to add three files to have the pointer environment on a QDOS system (including Minerva). Collectively, these three files are known as the Pointer Environment or Extended Environment. The Extended Environment is strictly speaking the combination of the first two and the hot_rext file, whereas the term Pointer Environment can be used to indicate a system where the Hotkey System is not present.

These three files are called ptr_gen, wman, and hot_rext. Nowadays, they are freely available and can be downloaded from the PE page on my website at http://www.dilwyn.me.uk/pe/index.html

In general, you should use the most recent version available, unless that version is known not to work on your system for some reason.

Older versions are available on the page, mainly for historical interest and also for software authors to test their programs with.

The usual way to install these files is to write a short program called BOOT, which is a short program written in SuperBASIC, that runs automatically when you start your QL or emulator. Usually from floppy disc or from a hard disc, although nowadays it is perfectly possible to arrange to boot from a flash memory device such as SD card, RomDisq, or compact flash card.
  1. Ptr_gen is known as the Pointer Interface. It provides an on-screen pointer, usually a small arrow symbol, to point to and control the various objects and menus in the program. It also provides the window save and display system, whereby when you use CTRL C to switch between programs, it “remembers” the screen display of each program.
  2. Wman is known as the Window Manager. It manages the appearance of the programs, often providing a standardised appearance so that most programs which use the Pointer Environment can look alike – menus work similarly in most programs and so on.
  3. Hot_rext is referred to as the Hotkey system. Keys with definable actions attached to them. Plus something known as the Thing system. A Thing is a general system resource, but their types can be so vague and vastly different we have to give them a very generalised name, hence Thing. Don’t worry too much about them at this stage.
Here is an example program. We will assume that the files are loaded from a floppy disc drive, called FLP1_.

100 REMark BOOT program for Pointer Environment
110 base1 = RESPR(xxxxx) : LBYTES FLP1_PTR_GEN, base1 : CALL base1
120 base2 = RESPR(yyyyy) : LBYTES FLP1_WMAN,base2 : CALL base2
130 base3 = RESPR(zzzzz) : LBYTES flp1_HOT_REXT,base3 : CALL base3

xxxxx, yyyyy and zzzzz are the length of the ptr_gen, wman and hot_rext files respectively, in bytes. The length is usually given where you downloaded the files from, but if not, you can easily check the length using a file handling program, or using the FLEN function in Toolkit 2:

PRINT FLEN(\flp1_ptr_gen)
PRINT FLEN(\flp1_wman)
PRINT FLEN(\flp1_hot_rext)

Note the backslash before the filename. If your version of Toolkit 2 is so old that you can’t use FLEN with a backslash like that, use something like this instead:

OPEN_IN #3,flp1_ptr_gen : PRINT FLEN(#3) : CLOSE #3
OPEN_IN #3,flp1_wman : PRINT FLEN(#3) : CLOSE #3
OPEN_IN #3,flp1_hot_rext : PRINT FLEN(#3) : CLOSE #3

The filenames are not case sensitive (flp1_ptr_gen is exactly the same as FLP1_PTR_GEN as far as the QL is concerned). The filenames may be put in quotes if you prefer, e.g. “flp1_wman” or ‘flp1_hot_rext’).

If you have Toolkit 2 on your system, there is a way to simplify the BOOT program by using the LRESPR command to replace the RESPR/LBYTES/CALL sequences. Toolkit 2’s name is often abbreviated to TK2.

100 REMark BOOT program for Pointer Environment using TK2
110 TK2_EXT : REMark activate Toolkit 2 on some systems
120 LRESPR flp1_ptr_gen
130 LRESPR flp1_wman
140 LRESPR flp1_hot_rext

Line 110 contains a command called TK2_EXT. This is used to activate Toolkit 2 on some older systems which have it built in, but not automatically activated when the computer starts. Some floppy disc interfaces may need a TK2_EXT command to start Toolkit 2. Some interfaces, such as the Super Gold Card have commands which can make the interface remember whether or not to start Toolkit 2 as the system starts. You will need to refer to the interface documentation to check for each individual interface type. Or you can adopt a trial and error approach. If the extensions work without a TK2_EXT command, then you don’t need a TK2_EXT command in the BOOT program (although it does not harm if present).

This simple program is enough in itself to use the pointer environment at its simplest level. You can now use CTRL C to switch between two or more programs running on your system, to save and restore the display of each program as you switch to it or from it.

If you wish to add other extensions or toolkits to this simplest of BOOT programs, it is quite easy to do so. We just need to be aware that such things may need to be installed in a particular order, whether before or after the ptr_gen, wman and hot_rext extensions.

The rule of thumb is that most such extensions will go after the pointer environment files. But there are exceptions, and the software manuals will generally tell you about this. For example, if you use Lightning or Lightning Special Edition screen accelerations software, those extensions would need to be installed BEFORE pointer environment, but after Toolkit 2 if the TK2_EXT command is needed for example.

There are some versions of Toolkit 2 out there, such as the old Reconfigurable Toolkit 2, or versions adapted to run from RAM memory (usually made by saving an image of a copy of Toolkit 2 from a ROM). These should be loaded BEFORE the pointer environment unless the Toolkit 2 documentation says otherwise.

If you have a SuperHermes or other keyboard interface fitted on your QL system, it usually needs a short keyboard driver file if using an extension keyboard (unless the driver software is loaded from an EPROM or ROM somewhere on your system). Its instructions will tell you where to install it in a BOOT program if required, but this will usually be one of the first items loaded. SuperHermes can also provide for using a mouse on your QL system – follow the SuperHermes manual’s instructions for where best to load the mouse driver software.

Many pointer-driven programs come with a set of extensions called the Menu Extension or QMenu, usually as a file called MENU_REXT. This provides a set of standard menus and other features which programs can use to build on the facilities offered by the pointer environment. This should be loaded AFTER the three standard pointer environment files, e.g.

100 REMark BOOT program for Pointer Environment using TK2
110 TK2_EXT : REMark activate Toolkit 2 on some systems
120 LRESPR flp1_ptr_gen
130 LRESPR flp1_wman
140 LRESPR flp1_hot_rext

In general, small toolkits of extensions for the BASIC interpreter (new keywords for the language) should be installed after these unless the documentation says otherwise. Software such as QPAC2 which is also generally installed via a BOOT file would also be installed at this stage. Once you have added all the software needed, you can then start on things like Hotkey definitions to control actions taken when keys are pressed in conjunction with the ALT key on a keyboard – there’s a guide to Hotkeys at http://www.dilwyn.me.uk/pe/index.html .

Some systems require that a mouse driver be installed to allow a mouse to be used on your system. Again, the documentation will usually tell you where the mouse driver should be added to your BOOT program. In general, this will be after the three base files, but before other things in the boot program, e.g. to add the serial mouse driver Sermouse, you could add this at line 145 or line 160 in the example above:


The filename of the sermouse driver may vary according to the package.

Mouse Systems For QL With Pointer Interface

With so many emulators and add-ons for the QL nowadays, it is hard to give a definitive answer as to which mouse system is best used with a QL which has the pointer interface installed.


On some emulators which run QDOS, the pointer interface will automatically detect and use the mouse used by the host operating system. By and large, the detection is either automatic, or documented in the emulator manuals.

An exception to this used to be the emulator called QemuLator, which until recently needed a small piece of code called MacMouse to be added to allow the pointer interface to be controlled by mouse in the emulator (as of v2.06 of ptr_gen, released in 2021, this should no longer be required). This was added just after the three pointer environment files in the BOOT program. Note that the manual for this emulator says that this is “available only with the ‘Expanded QL’ registration”. In other words, the free unregistered demo version may not work with a mouse. On registered versions of the emulator, you could add the MacMouse software just after hot_rext in the example BOOT file above:

100 REMark BOOT program for Pointer Environment using TK2
110 TK2_EXT : REMark activate Toolkit 2 on some systems
120 LRESPR flp1_ptr_gen
130 LRESPR flp1_wman
140 LRESPR flp1_hot_rext
145 LRESPR flp1_MacMouse11

The ‘11’ is the version number and may vary if your versions of the emulator has something other than version 1.1 of MacMouse.


Probably the oldest pointer environment mouse interface for the QL, this interface originally built by QJump and after that sold for a while by Quanta. It is a small circuit board which fits inside the QL and uses an Atari-style mouse. Once installed, it is automatically detected by the pointer environment and no further software is needed. The name QIMI stands for QL Internal Mouse Interface. There is a picture of the mouse and interface near the top of this page.

Sandy SuperQBoardSandy SuperQBoard

This was a mouse interface included in some of the disc interfaces released for the QL by a company called Sandy in the UK. Broadly equivalent to a QIMI interface, this type of mouse is also detected automatically by the pointer interface. If you have a SuperQBoard without the mouse interface on-board, there are some documents available at http://www.dilwyn.me.uk/docs/hardware/sqbmods.zip about upgrading a SuperQBoard.

SuperHermes boardSuperHermes

This was a circuit board from TF Services, designed as an enhanced replacement for the 8049 or Hermes second processor in a QL. Among other things, it allowed an external keyboard, additional serial ports and for a mouse to be added to the QL. Either a Microsoft or Mouse Systems mouse could be used. It required a small piece of code called called IPCEXT to be used. Add this to your boot file as indicated in the SuperHermes manual, using the IPCMOUSE extension to select the appropriate serial port and IPCSLOW command to control mouse acceleration. The IPCMOUSE commands should be called after the pointer environment has been installed in the BOOT program.


This is probably the simplest way to add a mouse to a QL with pointer environment, as it allows a standard serial mouse to be connected to a QL serial port (usually via a short cable adaptor) and uses a small piece of software to go between the mouse and the pointer interface, to connect the two. It was a little fiddly to set up the software and hit-and-miss with models of mouse. But when it works, with a suitable mouse, it was probably the simplest and most cost-effective approach to adding a mouse to a QL. This type of mouse could be used with a QL or with an Aurora card. There are two versions of the sermouse software on my website, at www.dilwyn.me.uk/pe/index.html , since some users have found that one version works with some mouse types, while the other version is required for some mouse types. Most users connect this type of mouse to SER2, and a user on QL Forum has kindly made a wiring diagram for the adaptor needed to connect a mouse with 9-pin D connector to the six pin UK ser2 port.

Cursor Mouse

Smiling Mouse Some older mouse interfaces for the QL work by emulating the cursor arrow keys, a bit like the CTL1 joysticks do. These include the Smiling Mouse, ABC mouse, and Mersey Mouse interfaces, for example. The pointer environment can, in the absence of a mouse, be controlled using the cursor arrow keys on the QL keyboard, with the two mouse buttons equating to the space bar and ENTER keys. This means that this type of mouse could in theory at least control the on-screen pointer, although the speed and response may vary from type to type.

Mersey MouseIf you fancy building your own mouse interface of this type, Gianni Carugno has devised a PS/2 mouse to QL CTL port interface to allow a PS/2 mouse to be connected to a QL and to work like the cursor arrow keys – details at http://www.dilwyn.me.uk/docs/hardware/gc_qlmouse.zip

If you have the DIY Toolkit software from Simon Goodwin, he produced some software which allowed a two or three button Microsoft or Mouse Systems 'PC' mouse connected to the serial ports to be used as a cursor-key equivalent mouse. The software is available in Volume I of DIY Toolkit, download it from http://www.dilwyn.me.uk/tk/index.html

There is a circuit diagram and scanned documents on my site for a Mersey Mouse – download the package from http://www.dilwyn.me.uk/docs/manuals/Mersey_Mouse.zip

One mouse system which will NOT support the pointer environment is the ICE mouse system, originally released by Eidersoft. Although quite a useful system for the QL in its own right, only software which knows how to use the proprietary system will be able to make use of this.

Moving On With Pointer Environment

When you’ve installed the pointer environment as described above, you might not immediately notice that anything has changed. On the whole, the QL display will not immediately look any different – you could be forgiven for thinking nothing had changed. The first thing you’re likely to notice is that the QL saves and restores program displays as you switch between them with the CTRL C keypress.

I’ve covered just enough of the basics here to get you going. I would suggest that in order to read further, and to find out what else is possible, plus start to get to grips with the terminology and common features, you look for documents such as Norman Dunbar’s PE Idiot’s Guide (available to read online at http://www.dilwyn.me.uk/docs/ptr/peig/pe.html ), the Hotkey System guides at http://www.dilwyn.me.uk/pe/index.html and when you feel a little bit more confident, the QPAC2 user’s guide at https://www.kilgus.net/smsqe/qpac/ .

The PE Idiot’s Guide is just that. A down to earth and very basic guide to the pointer environment. It helps to explain the new terminology – what is a loose item, what is an information window, and so on.

Front Ends

In itself, the pointer environment doesn’t put a “front end” or a graphical user interface on your QL. You still start programs by using EXEC commands, you still switch from program to program using CTRL C, and you still end programs in the same way.

Once you’ve got used to switching between programs, defining hotkeys and the general convenience of the pointer environment and mouse control, you may want to try some front-end software for the QL. These generally let you assign a name or an icon to a program and you can start that program by clicking on the name of the program, or the icon representing the program. Many will let you pick (or select) between programs already running, manage files by letting you select which files to copy, delete, rename, etc (file management), and generally manage programs by helping you do things like stop programs, change their priority (running speed relative to each other) and so on.

A number of these types of programs have been written for the QL over the years, and a selection may be found on the Front Ends page on my website, at http://www.dilwyn.me.uk/frontend/index.html

These may take the form of something along the lines of Start menus and Taskbars on other operating systems – software such as Qascade and Q-Bar. Qascade is a Start-menu type of program, which sits in something called the "bytton frame" (another feature of the pointer environment and QPAC2!), whereas Q-Bar implements a taskbar and Start menu. Others may be more ambitious desktop environments, such as QDT, or program launchers such as Launchpad, DEV Manager and several others on that page. Some are text based, while others like QDT and Launchpad are more graphically orientated. You can also get program docks such as my Q-Dock and Wolfgang Lenerz’s Dock. Some of these front ends need SMSQ/E (e.g. QDT and Q-Dock), while others will work on QDOS with pointer environment.

Pointer Environment Version 2

At various stages in the life of the pointer environment, some emulators and systems such as the Aurora motherboard started to implement higher resolution screens (bigger than the usual 512x256 QL screen). Then they went on to implement screen modes with more than the usual four or eight colours of the QL. Although adding the pointer environment to a suitable QDOS system can allow suitable systems to implement higher resolution modes, what it can’t do is to add full support for higher colour modes. You need SMSQ/E for that.

But as pointer environment version 2 began to mature, there was increasing support for some of the “Window Manager 2” features, such as colour palettes or ‘themes’. This is a more advanced subject and you can find further articles on such subjects elsewhere in this website.

Return to home page | Go to section index | Go to documents index