QLCOMMANDER - testers and help needed

[Andrew]

All in all, your enhancements to this already very nice application work very well and its proving to be a very useful tool in practice, especially on the smaller QL platform where you might not be able to run CueShell (now made freeware).

Cueshell is great file manager - but on the 512x256 QL screen it gets a bit too crowded and windows overlap and need to be rearranged often - also it really needs a mouse. I still couldn't install a mouse on the QL
My experience with Cueshell gave me the idea to write QLCommander.

Now about the mouse: I have 5 serial mice. I installed serialmouse and tried to configure it, but failed miserably The movement of the mouse is chaotic and after a couple of moves the cursor jumps to the left bottom corner.
What mouse driver are you using on QL ? Can someone please send me a configured version of the driver, that works with the mouse on ser 2 ?

[mk79]

Now about the mouse: I have 5 serial mice. I installed serialmouse and tried to configure it, but failed miserably The movement of the mouse is chaotic and after a couple of moves the cursor jumps to the left bottom corner.

There were two versions of SerMouse, one for 2 and one for 3 button mice. Maybe that is your problem?

Marcel

[Andrew]

There were two versions of SerMouse, one for 2 and one for 3 button mice. Maybe that is your problem?
Marcel

I have a version that is configurable - and should works with both 3 and 2 buttons
I have 3 mice with 3 buttons and 2 with 2 buttons
I modified the serial cable as it is described in sermouse documentation
I believe that I am configuring something wrong - maybe the speed of the mouse ?
That is why I need an already configured driver that works on your system

[mk79]

I don't have any serial mice. But I do know that the latest SERmouse driver is not configurable between 2 and 3 buttons, so this is strange.

I could in theory build an adapter USB to serial, but my main goal is to eventually use the 3rd SPI port of QL-SD and attach a mouse there. Just lacking the time

[martyn_hill]

Hi again Andrew

Coming back briefly to your font printing observations documented in your new manual...

1. QPC2 char_inc issue 1

I realise now that my own adjustment to QLC didn't address the problem you mention in the new manual - although it did allow FAT founts to be rendered more effectively - just against the black PAPER.

Testing against the stippled PAPER instead, I see what you were getting at and believe the following explains why...

The standard QDOS (and SMSQE) screen driver is only capable of PRINTing in one of the standard CSIZE 'frames' (6, 8 and equivalent double-width 12 and 16) mode-4 pixels, taking account of the PAPER (or STRIP - which is how you are using PAPER in this example.)

The fact that we can use CHAR_INC to adjust the incremental offset between successive characters does not change this fundamental design of the PRINT routines - they will still only ever render 6, 8, 12 or 16 pixels wide, regardless of where the next character will be printed (based on CHAR_INC.)

Thus, for that 8x9 FAT font, one only needs to set CSIZE 1,x (to fill 8 pixels wide) to achieve the desired outcome - the 2-pixel 'gap' of stippled PAPER showing through in your example is due to not first setting CSIZE to extend the frame to 8-pixels, but still moving the cursor over by 9 pixels with CHAR_INC. Only the first 6-pixels are masked against the new PAPER/STRIP - the remaining pixels left at the original stippled PAPER as they are not actually drawn, but 'skipped' by CHAR_INC...

An overly long-winded way of saying that, if you are printing over a non-blank background using the standard PRINT routines, only 6, 8, 12 or 16 pixel widths can be used (using just CSIZE) without the background showing through. CHAR_INC won't hep you there as its not designed to...

I haven't tested this on a real QL yet, but would expect the same behaviour - did you only see this on QPC (or more accurately, on SMSQE)?

Item 2 from your own testing is still a mystery to me as I don't observe the problem on my QPC...

[Andrew]

I haven't tested this on a real QL yet, but would expect the same behaviour - did you only see this on QPC (or more accurately, on SMSQE)?

I saw this behavior only on QPC - on QL (Minerva ROM) and on QEmulator there are no gaps.

[martyn_hill]

Hi Andrew

I saw this behavior only on QPC - on QL (Minerva ROM) and on QEmulator there are no gaps.

Yes, a quick test on a vanilla Minerva-based QL shows that Minerva (at least) appears to interpret the character-increment as set by CHAR_INC to trigger extra 'padding' PAPER/STRIP pixels following the last font-pixel (up to 8) rendered, rather than simply moving the cursor over. That's perhaps more intuitive an approach from Minerva!

It's a moot point, but at some point I'll test a 'real' QDOS such as JS to see what the original 'design intention' was.

BTW, what are you running in QEm? Minerva or SMSQE?

[dilwyn]

There were two versions of SerMouse, one for 2 and one for 3 button mice. Maybe that is your problem?
Marcel

I have a version that is configurable - and should works with both 3 and 2 buttons
I have 3 mice with 3 buttons and 2 with 2 buttons
I modified the serial cable as it is described in sermouse documentation
I believe that I am configuring something wrong - maybe the speed of the mouse ?
That is why I need an already configured driver that works on your system

This is a "long shot" - I don't use Sermouse at the moment as my QL has a QIMI mouse interface.

I remember from days when I used SERmouse that one of the annoyances with some mice was that you had to hold down the left hand mouse button as the system powered up to get it to the correct mode for the Sermouse software version I used at the time.

IIRC, at the time I could only get that mouse to work in 2 button mode, but it was a 3 button mouse, so to get it to work as a 2 button mouse I remember having to hold down the left hand mouse button every time I switched on the QL. I vaguely remember the problem of the mouse running into a screen corner, but can't remember if that issue was related or how I fixed it, I'm afraid.

Probably less than 1% chance this is the answer to the problem on your system of course, but I thought I'd mention it just in case.

If you could check the version of the mouse driver you have, version 3.04 is available on my site at http://www.dilwyn.me.uk/pe/index.html and if anyone has a more recent version, I'd be glad to add that too. Albin Hessler gave permission some time ago for the software to be made available in this way.

[Andrew]

QLCommander v1.1

I included Martyn Hills suggestions and changes and Marcel's suggestion about not using DATAD$
Changes:
- View command now works with files with .ext and _ext
- Fonts are rendered better in View window - and QLCOmmander automatically detects (with reasonable accuracy) whether a given _fnt file actually contains a FAT 8x9 fount-set.
- Added a fail-safe to the ViewImage routine so now _scr files larger than 32k will not crash the QL
- Added commands:

- Ctrl-Left : back to parent
- Ctrl-Up : Goto top item
- Ctrl-down : Goto Last item

- When loading a BASIC file the program checks if BASIC is running - or if a basic program is already loaded
- QLCommander now does not use DATAD$ - now moving to parent directory is based on Marcel's routine
- Some other minor changes and bug-fixing
- updated manual


Known issue that drives me crazy (Please help with this !)
- Compiled program with QLiberator works on QL, QEmulator and QPC
- Compiled program with Turbo works only on QPC !! On QL and QEmulator it raises error "Not implemented yet"
Can anyone help with this peculiarity ?

[EmmBee]

- Compiled program with Turbo works only on QPC !! On QL and QEmulator it raises error "Not implemented yet"

What line number does this error occur on?
Also - did this happen in the previous version?

Michael