The Sinclair QL Forum

As I only have a QPC2 system set up here atm, could someone possibly try something out on a BBQL for me to see if this is QPC specific, or applies across all QDOS/SMSQ_E systems.

Bit of an unusual issue with a PAN command, which could potentially be useful if it appliers across all systems.

It concerns the area panned left or right with the 3 or 4 parameters.

PAN doesn't support PAN #channel,pixels, parameter where parameter = 1 or 2 (i.e. only pans whole window, or cursor line, not the section above or below the cursor line).

As expected, PAN #channel,pixels,3 or PAN #channel,pixels,4 pans the current line whether in CSIZE height 0 or 1. Thus far, as expected.

After making a silly programming error in my program, I came across this, which may be useful.

On QPC2, if I altered the CHAR_INC vertical spacing to a value larger than the usual 10 or 20 pixels, e.g.

AT 0,0
CSIZE 1,1
CHAR_INC 8,50
PAN -10,3

It seems to pan left a block of 50 pixels high ten pixels to the left.

That's all I need checked really, that this still works on a QL with Toolkit 2. Useful being able to pan a variable height section if the PAN command takes CHAR_INC settings into account on all systems.

On my BBQL with Gold card (Minerva OS), it does pan top 5 lines left (50 pixel cursor line) by 10 pixels.

Thank you Silvester.

Hi,

Is it possible to use the PAN command in a overwrite mode, so that the foreground is PANned left or right leaving the background unchanged.

Probably this will not work and Sprite routine is required.

Derek_Stewart wrote:Hi,

Is it possible to use the PAN command in a overwrite mode, so that the foreground is PANned left or right leaving the background unchanged.

Unlike the Spectrum, the QL display doesn't have such thing as an 'attribute file'. A pixel doesn't have a background or foreground colour, it just has a colour. So scrolling or panning just moves the entire (part of the) display.

That said, I've once written a SCREEN$ function for the QL which looks up the character displayed on a particular position on the screen like the Spectrum's equivalent. This operation is much more complicated since the pixel pattern is spread over 2 or 4 colour bits in different bytes, which must match either the foreground colour or the background colour (yes, I had to deal with 'inverted printing' too). And even then it only worked if the colours weren't changed between the printing and the call to SCREEN$!

Jan