Re: [Ql-Users] Ser-USB Driver running under Q-emuLator

2011-02-28 Thread Adrian Ives
Tony,

If you're talking about the drivers built into the USBWiz, there's USB
printer support and HID for mice and keyboards. However, nobody should get
excited about that because the USB printer support appears to be raw data
only so it would need a driver written.  Keyboard and mouse might be
possible, but I've already covered the problems of running them across the
same serial connection as used for the storage devices.

Beyond that, it would be possible to talk to just about anything USB ...
with a driver.

The Ser-USB driver currently supports SD Cards and USB Mass Storage devices;
both accessed in native QDOS mode.


Adrian

-Original Message-
From: ql-users-boun...@lists.q-v-d.com
[mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman
Sent: 28 February 2011 00:09
To: ql-us...@q-v-d.com
Subject: Re: [Ql-Users] Ser-USB Driver running under Q-emuLator



On 27 Feb 2011, at 23:49, Adrian Ives adr...@acanthis.co.uk wrote:

 
 
 I was asked this question recently and have only just got around to 
 testing it.  Yes, it does work!
 
 
 
 Tested this evening under Q-emuLator 3.0.2 with a JS ROM image on 
 Windows 7
 64 bit with a USB to Serial adapter connecting to the Ser-USB unit.
 
 

That is really good news. What inbuilt drivers are there of any use?  

I forget the details but  on first reading the specs anything really useful
via USB will need QL drivers.

Looks like you are making real progress.

Tony

--
QBBS (QL fido BBS 2:257/67) +44(1442)-828255
 t...@firshman.co.uk http://firshman.co.uk
Voice: +44(0)1442-828254  Fax: +44(0)1442-828255 Skype: tonyfirshman
  TF Services, 29 Longfield Road, Tring, Herts, HP23 4DG
 
 
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Adrian Ives
I know I've seen this somewhere but, as usual, when you really want
something it refuses to be found!

 

I'm looking for a function to use in S*BASIC that will tell me if the
display driver is capable of providing resolutions greater than the QL's
mode 4  8 defaults - it would be enough just to know if the display driver
is GD2 or not.  It has to run on any QL system, including clones and
emulators.  Can anyone help?

 

Thanks,

 

 

Adrian

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Adrian,
there is (I think) not a single function that allows to retrieve this 
information, but some strong hints from the system that GD2 is there:

- Use SD.EXTOP and check offset $64 of the channel table - this gives you the 
number of bytes per scanline.
- use MT.DMODE to retrieve the screen mode
Divide scan line length*8 by the number of colour bits for the detected mode, 
should give you a hint on screen width when you cannot detect PE (The screen 
height is, I think not easy to detect when no PE is present)

If you can detect PE, use iop.flim to get width and height from the PE directly.
The only system with resolutions 512x256 and no PE is, to my knowledge, uQLX.

Dilwyn's page has the wonderful display_cde toolkit that incorporates this (and 
a few other display related calls into a wonderful S*Basic extension.

Cheers,
Tobias

-Original-Nachricht-
Subject: [Ql-Users] Help: Function to tell whether display is better than QL 
standard
Date: Mon, 28 Feb 2011 15:01:55 +0100
From: Adrian Ives adr...@acanthis.co.uk
To: ql-us...@q-v-d.com

I know I've seen this somewhere but, as usual, when you really want
something it refuses to be found!

 

I'm looking for a function to use in S*BASIC that will tell me if the
display driver is capable of providing resolutions greater than the QL's
mode 4  8 defaults - it would be enough just to know if the display driver
is GD2 or not.  It has to run on any QL system, including clones and
emulators.  Can anyone help?

 

Thanks,

 

 

Adrian

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread gdgqler

On 28 Feb 2011, at 14:01, Adrian Ives wrote:

 I know I've seen this somewhere but, as usual, when you really want
 something it refuses to be found!
 
 
 
 I'm looking for a function to use in S*BASIC that will tell me if the
 display driver is capable of providing resolutions greater than the QL's
 mode 4  8 defaults - it would be enough just to know if the display driver
 is GD2 or not.  It has to run on any QL system, including clones and
 emulators.  Can anyone help?

I look to see if WM_BLOCK is a valid keyword. If so then I assume that GD2 
colours are there.

By using TURBO I am able to replace WM_BLOCK by a valid keyword even though the 
real WM_BLOCK is not there.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Adrian Ives
Yes, display_cde is the one I was thinking of.  I think I can get all I want
from this.  Thanks for jogging my memory and many thanks to Dilwyn for the
toolkit in the first place!

Adrian

-Original Message-
From: ql-users-boun...@lists.q-v-d.com
[mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of
tobias.froesc...@t-online.de
Sent: 28 February 2011 14:50
To: ql-us...@q-v-d.com
Subject: Re: [Ql-Users] Help: Function to tell whether display is better
than QL standard

Adrian,
there is (I think) not a single function that allows to retrieve this
information, but some strong hints from the system that GD2 is there:

- Use SD.EXTOP and check offset $64 of the channel table - this gives you
the number of bytes per scanline.
- use MT.DMODE to retrieve the screen mode Divide scan line length*8 by the
number of colour bits for the detected mode, should give you a hint on
screen width when you cannot detect PE (The screen height is, I think not
easy to detect when no PE is present)

If you can detect PE, use iop.flim to get width and height from the PE
directly.
The only system with resolutions 512x256 and no PE is, to my knowledge,
uQLX.

Dilwyn's page has the wonderful display_cde toolkit that incorporates this
(and a few other display related calls into a wonderful S*Basic extension.

Cheers,
Tobias

-Original-Nachricht-
Subject: [Ql-Users] Help: Function to tell whether display is better than QL
standard
Date: Mon, 28 Feb 2011 15:01:55 +0100
From: Adrian Ives adr...@acanthis.co.uk
To: ql-us...@q-v-d.com

I know I've seen this somewhere but, as usual, when you really want
something it refuses to be found!

 

I'm looking for a function to use in S*BASIC that will tell me if the
display driver is capable of providing resolutions greater than the QL's
mode 4  8 defaults - it would be enough just to know if the display driver
is GD2 or not.  It has to run on any QL system, including clones and
emulators.  Can anyone help?

 

Thanks,

 

 

Adrian

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Adrian Ives
That's also a good way of doing it.

Thanks, George.

-Original Message-
From: ql-users-boun...@lists.q-v-d.com
[mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of gdgqler
Sent: 28 February 2011 15:09
To: ql-us...@q-v-d.com
Subject: Re: [Ql-Users] Help: Function to tell whether display is better
than QL standard


On 28 Feb 2011, at 14:01, Adrian Ives wrote:

 I know I've seen this somewhere but, as usual, when you really want 
 something it refuses to be found!
 
 
 
 I'm looking for a function to use in S*BASIC that will tell me if the 
 display driver is capable of providing resolutions greater than the 
 QL's mode 4  8 defaults - it would be enough just to know if the 
 display driver is GD2 or not.  It has to run on any QL system, 
 including clones and emulators.  Can anyone help?

I look to see if WM_BLOCK is a valid keyword. If so then I assume that GD2
colours are there.

By using TURBO I am able to replace WM_BLOCK by a valid keyword even though
the real WM_BLOCK is not there.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread gdgqler

On 28 Feb 2011, at 15:42, Marcel Kilgus wrote:

 gdgqler wrote:
 I'm looking for a function to use in S*BASIC that will tell me if the
 display driver is capable of providing resolutions greater than the QL's
 mode 4  8 defaults - it would be enough just to know if the display driver
 is GD2 or not.  It has to run on any QL system, including clones and
 emulators.  Can anyone help?
 I look to see if WM_BLOCK is a valid keyword. If so then I assume that GD2 
 colours are there.
 
 Many things are mixed up here. WM_BLOCK is WMAN2, which I've developed
 a long time after GD2 has seen the light.
 

OK. I needed WMAN2 in my program anyway.

 Also, higher resolutions were available long before GD2 came out. GD2
 is only necessary for higher *colour depths*.
 
 I think the PE was necessary for higher resolutions, so you can test
 for that first. Afterwards IOP.FLIM should be able to find the screen
 limits.

IOP.FLIM is a good way of finding screen limits. It is slightly annoying if it 
is not available. I have programs which find the maximum size by trial and 
error if IOP.FLIM is not there.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Marcel Kilgus
gdgqler wrote:
 IOP.FLIM is a good way of finding screen limits. It is slightly
 annoying if it is not available. I have programs which find the
 maximum size by trial and error if IOP.FLIM is not there.

In which cases is IOP.FLIM not available and the resolution not
512x256?

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Marcel,
see my other post.

Cheers,
Tobias

-Original-Nachricht-
Subject: Re: [Ql-Users] Help: Function to tell whether display is better than 
QL standard
Date: Mon, 28 Feb 2011 16:52:53 +0100
From: Marcel Kilgus ql-us...@mail.kilgus.net
To: ql-us...@q-v-d.com

gdgqler wrote:
 IOP.FLIM is a good way of finding screen limits. It is slightly
 annoying if it is not available. I have programs which find the
 maximum size by trial and error if IOP.FLIM is not there.

In which cases is IOP.FLIM not available and the resolution not
512x256?

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread gdgqler

On 28 Feb 2011, at 15:52, Marcel Kilgus wrote:

 gdgqler wrote:
 IOP.FLIM is a good way of finding screen limits. It is slightly
 annoying if it is not available. I have programs which find the
 maximum size by trial and error if IOP.FLIM is not there.
 
 In which cases is IOP.FLIM not available and the resolution not
 512x256?

There must have been some, otherwise I would certainly not have gone to the 
trouble of testing different sizes! Nor, i suspect, would Mark Knight.

I think that QXL did not have PE with SMSQ. What about Aurora? Both have larger 
screen sizes than 512x256.

But, as usual, I'm probably wrong.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Marcel Kilgus
tobias.froesc...@t-online.de wrote:
 -- I think the PE was necessary for higher resolutions, so you can test
 -- for that first. Afterwards IOP.FLIM should be able to find the screen
 -- limits.
 Not quite.
 UQLX does offer higher resolutions without PE (sure you can run PE
 on top of it.)

From the uQLx manual:

The theoretical limit is - because of Pointer Environment's bad
habits that the screen must fit with all RAM into 16 MB. Pointer
Environment is patched when activated to recognise the new screen
parameters - there are 'cleaner' solutions, unfortunately with severe
side effects. If you receive the warning could not patch PE, you are
in serious trouble..

Are you sure it works without PE?

 And the original (preliminary) QXL software that came with the card
 supported higher (I think, EGA) resolutions without PE. Another
 thing, however is, whether you really want that.

That's possible. But then this OS didn't even include BASIC, so isn't
that compatible anyway I'd say...

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Marcel Kilgus
gdgqler wrote:
 There must have been some, otherwise I would certainly not have
 gone to the trouble of testing different sizes! Nor, i suspect, would Mark 
 Knight.

I'm genuinely curious and don't pretend that I know the whole truth.
But except the SMSQ for QXL fringe case I cannot currently imagine
any other scenario.

 I think that QXL did not have PE with SMSQ. What about Aurora? Both
 have larger screen sizes than 512x256.

From the Aurora manual on Dilwyn's site:

To properly exploit all the Aurora facilities, you will need to run
the SMSQ/E operating system [...] Previously, the Aurora came either
bundles with a version of SMSQ/E which works with it, or a patch disc
which will unlink the built-in display driver of your existing copy of
SMSQ/E and link a new one

That's all I know about it. Even though I wrote the GD2 Aurora
graphics driver, I've never had or used an Aurora board, I did all
that without access to the actual hardware...

 But, as usual, I'm probably wrong.

Usually you're more right than wrong. :-)

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Yes, I'm sure ;-)
Mostly because I have to re-install PE from Dilwyn's site whenever I set up a 
new Linux box
(I use a common qxl.win-file for all my QDOSSMSQ installations, but uqlx has to 
pick its WMAN, PTR_GEN and HOT_REXT from mdv1 separately before actually 
running win1_boot)

The citation you made refers to the run-time patch mechanism of uqlx - If you 
load PE, it's being patched by uqlx, if you don't - it's just not there

Cheers,
Tobias

-Original-Nachricht-
Subject: Re: [Ql-Users] Help: Function to tell whether display is better than 
QL standard
Date: Mon, 28 Feb 2011 17:07:26 +0100
From: Marcel Kilgus ql-us...@mail.kilgus.net
To: ql-us...@q-v-d.com

tobias.froesc...@t-online.de wrote:
 -- I think the PE was necessary for higher resolutions, so you can test
 -- for that first. Afterwards IOP.FLIM should be able to find the screen
 -- limits.
 Not quite.
 UQLX does offer higher resolutions without PE (sure you can run PE
 on top of it.)

From the uQLx manual:

The theoretical limit is - because of Pointer Environment's bad
habits that the screen must fit with all RAM into 16 MB. Pointer
Environment is patched when activated to recognise the new screen
parameters - there are 'cleaner' solutions, unfortunately with severe
side effects. If you receive the warning could not patch PE, you are
in serious trouble..

Are you sure it works without PE?

 And the original (preliminary) QXL software that came with the card
 supported higher (I think, EGA) resolutions without PE. Another
 thing, however is, whether you really want that.

That's possible. But then this OS didn't even include BASIC, so isn't
that compatible anyway I'd say...

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard

2011-02-28 Thread Dilwyn Jones


- Original Message - 
From: Adrian Ives adr...@acanthis.co.uk

To: ql-us...@q-v-d.com
Sent: Monday, February 28, 2011 3:26 PM
Subject: Re: [Ql-Users] Help: Function to tell whether display is 
betterthan QL standard





Yes, display_cde is the one I was thinking of.  I think I can get 
all I want
from this.  Thanks for jogging my memory and many thanks to Dilwyn 
for the

toolkit in the first place!

Adrian

Adrian - please feel free to use or adapt display_cde in any way you 
see fit.


The sources are I think included in the package on the Toolkits page 
on my site, if not, just send me a private email and I'll send them.


--
Dilwyn Jones 




___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Marcel, George,
my QXL originally came with SMS (neither 2 nor Q attached to it).
This definitely had no PE. (Today it's on newest SMSQ/E, naturally)

Cheers,
Tobias

-Original-Nachricht-
Subject: Re: [Ql-Users] Help: Function to tell whether display is better than 
QL standard
Date: Mon, 28 Feb 2011 17:19:09 +0100
From: Marcel Kilgus ql-us...@mail.kilgus.net
To: ql-us...@q-v-d.com

gdgqler wrote:
 There must have been some, otherwise I would certainly not have
 gone to the trouble of testing different sizes! Nor, i suspect, would Mark 
 Knight.

I'm genuinely curious and don't pretend that I know the whole truth.
But except the SMSQ for QXL fringe case I cannot currently imagine
any other scenario.

 I think that QXL did not have PE with SMSQ. What about Aurora? Both
 have larger screen sizes than 512x256.

From the Aurora manual on Dilwyn's site:

To properly exploit all the Aurora facilities, you will need to run
the SMSQ/E operating system [...] Previously, the Aurora came either
bundles with a version of SMSQ/E which works with it, or a patch disc
which will unlink the built-in display driver of your existing copy of
SMSQ/E and link a new one

That's all I know about it. Even though I wrote the GD2 Aurora
graphics driver, I've never had or used an Aurora board, I did all
that without access to the actual hardware...

 But, as usual, I'm probably wrong.

Usually you're more right than wrong. :-)

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard

2011-02-28 Thread Ralf Reköndt

Marcel Kilgus wrote:


I'm pretty sure that version was called SMSQ (it's the only version
that was called SMSQ, actually). Even Wikipedia agrees with me here
and I'm pretty sure I didn't write the entry myself ;)
It began life as SMSQ, a QDOS-compatible version of SMS2 intended for
the Miracle Systems QXL emulator card


You're right, it has always been called SMSQ.



But yes, it did not include the PE, that was only the case of the /E
versions. But I still think this is a fringe case, it didn't even
include any BASIC language after all. It was pre-release software and
should be ignored for any new development, I think.


There is only one hardware, I assume: The so-called Extended QL Emulator 
Card (NOT QVME!) for the Atari ST series, with (I think) 780xXXX or similar 
(Jochen may prove).


Cheers...Ralf 


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Marcel,
sorry to contradict again ;-) :
uqlx can run a JS ROM in 800x600 without PE quite well.
But whether that JS ROM then still counts as a Standard QL ROM after being 
runtime patched heavily by uqlx is highly debatable
uqlx has a quite sophisticated (mmap-based) mechanism to detect access to real 
hardware - even by the OS itself. It then bails out to the host OS (I think, by 
patching Trap#x with Line-A-and-F instructions) and rewrites large parts of the 
(here: console) drivers through native code (that's the runtime patching). 
Don't know how you do that in QPC.
But it doesn't expose Minerva's second screen for reasons unknown to me.

Cheers,
Tobias

-Original-Nachricht-
Subject: Re: [Ql-Users] Help: Function to tell whether display is better than 
QL standard
Date: Mon, 28 Feb 2011 17:37:06 +0100
From: Marcel Kilgus ql-us...@mail.kilgus.net
To: ql-us...@q-v-d.com

tobias.froesc...@t-online.de wrote:
 Yes, I'm sure ;-)
 Mostly because I have to re-install PE from Dilwyn's site whenever I set up a 
 new Linux box

Yes, you're right. I already had the suspicion that Minerva was
written cleanly enough to support different screen layouts (had to
really, because of the dual screen feature). But that's the only case,
no standard QL rom can support different resolutions without the PE
replacing its CON driver. That I'm pretty sure of ;)

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Marcel,

-- include any BASIC language after all. It was pre-release software and
-- should be ignored for any new development, I think.

That's what I did in the 90ies (I mean ignore). You couldn't do much else with 
it.

Cheers
Tobias


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread Marcel Kilgus
tobias.froesc...@t-online.de wrote:
 Marcel,
 sorry to contradict again ;-) :
 uqlx can run a JS ROM in 800x600 without PE quite well.

This is right out of the uQLx source code:

 if (isMinerva) {
[...]
 else  /* JS doesn't handle big screen */
{
bsfb:
  qlscreen.linel=128;
  qlscreen.yres=256;
  qlscreen.xres=512;
  
  qlscreen.qm_lo=128*1024;
  qlscreen.qm_hi=128*1024+32*1024;
  qlscreen.qm_len=0x8000;
}

 Don't know how you do that in QPC.

I don't do MMAP based tricks for screen hardware because that's
usually too slow. I only do that for accesses outside of the QL memory
layout.

Cheers, Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread tobias.froesc...@t-online.de
Marcel,
you're right, tricked myself:
when started with the big screen enabled, it seems that uqlx loads the Minerva 
ROM, regardless of what ROM you might have configured in the config file.

Cheers,
Tobias

-Original-Nachricht-
Subject: Re: [Ql-Users] Help: Function to tell whether display is better than 
QL standard
Date: Mon, 28 Feb 2011 18:02:43 +0100
From: Marcel Kilgus ql-us...@mail.kilgus.net
To: ql-us...@q-v-d.com

tobias.froesc...@t-online.de wrote:
 Marcel,
 sorry to contradict again ;-) :
 uqlx can run a JS ROM in 800x600 without PE quite well.

This is right out of the uQLx source code:

 if (isMinerva) {
[...]
 else  /* JS doesn't handle big screen */
{
bsfb:
  qlscreen.linel=128;
  qlscreen.yres=256;
  qlscreen.xres=512;
  
  qlscreen.qm_lo=128*1024;
  qlscreen.qm_hi=128*1024+32*1024;
  qlscreen.qm_len=0x8000;
}

 Don't know how you do that in QPC.

I don't do MMAP based tricks for screen hardware because that's
usually too slow. I only do that for accesses outside of the QL memory
layout.

Cheers, Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is betterthan QL standard

2011-02-28 Thread Adrian Ives
Many thanks, Dilwyn.

This all came about because ... I've only just found time to revisit the
original Ser-USB File Manager program (now called USBWiz Terminal). It was
written over a year ago and needed some updating.

Because this program has to be able to run with nothing more than Toolkit 2
loaded, the first thing I had to do was to incorporate any machine code
extensions into the Turbo'd task.  It was while doing this that I remembered
Simon Goodwin's W_STORE and W_SHOW functions, which I'd used for for its
popup menus ... and they don't work with the higher screen resolutions!

I couldn't find any high resolution replacements, so if the USBWiz Terminal
is running on anything greater than Mode 8 it's going to insist that the
pointer environment is there to handle its window saves and restores ...
unless anyone knows of updated versions of W_STORE and W_SHOW?  I don't have
time to muck about developing my own at the moment.  The PE version - when I
get around to writing it - won't have this problem.

I now have two volunteers for testing the driver and expect to release the
first beta on the 14th March, after myself and my wife have (hopefully) had
a nice holiday ;)




Adrian

-Original Message-
From: ql-users-boun...@lists.q-v-d.com
[mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Dilwyn Jones
Sent: 28 February 2011 16:26
To: ql-us...@q-v-d.com
Subject: Re: [Ql-Users] Help: Function to tell whether display is betterthan
QL standard


- Original Message -
From: Adrian Ives adr...@acanthis.co.uk
To: ql-us...@q-v-d.com
Sent: Monday, February 28, 2011 3:26 PM
Subject: Re: [Ql-Users] Help: Function to tell whether display is betterthan
QL standard



 Yes, display_cde is the one I was thinking of.  I think I can get all 
 I want from this.  Thanks for jogging my memory and many thanks to 
 Dilwyn for the toolkit in the first place!

 Adrian

Adrian - please feel free to use or adapt display_cde in any way you see
fit.

The sources are I think included in the package on the Toolkits page on my
site, if not, just send me a private email and I'll send them.

--
Dilwyn Jones 



___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[Ql-Users] Survey update...

2011-02-28 Thread Dave Park
Hi all,

The survey has now closed, and I have composed and sent the email of the
survey answers to the list.

The results are in HTML format and use a lot of tables, so the email is
quite large - 309K - and is being held in the moderation queue. Hopefully,
it will be allowed through shortly. The current limit is a measly 40k ;)

If not, I will transcribe it into plain text. I am hoping to avoid that so
you all can see the complete original responses, cut and pasted.

Dave
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


[Ql-Users] The First Survey - Results!

2011-02-28 Thread Dave Park
Hi all,
Here are the survey results as promised. I have added some commentary in
GREEN. Some surveys had blank lines submitted so I have indicated those in
RED. I have deleted entries from the right column of the option tables to
protect privacy: I have retained this info and will be happy to dig deeper
upon request: for example, in the question about desire for new types of
hardware, this can be related to amounts people are willing to pay so I can
give a separate chart for each category.

I am very impressed with the results, and they show some clear patterns I
would not have guessed existed. I hope they inform you and give rise to new
questions and discussions.

I will be running a new survey on 1st - 31st April - if new questions arise
from these answers, I will include them in that survey.

Discuss!

Dave


Survey Answers
Total Unique Responses Received:*74*
Question 1**What is your primary QL system?* 128K or 640K QL  2
 3%  QL with expansion card (eg: Floppy Parallel TK2)  9
 12%  QL with Gold Card  5
 7%  QL with Super Gold Card  3
 4%  QXL  3
 4%  Aurora  3
 4%  Q40/Q60  7
 9%  Free software emulator  4
 5%  Commercial software emulator  33
 45%  Other:  5
 7% *ID**Other:*
4302368Aurora+Super Gold Card+Qbide
4312335QPC
4323266QL2K : As I'm the main author.
4379480Don't really have a primary system any more. Last used was QPC on
eeepc running wine
4414132QPCII on W98; QL w/ SGC, more.
In this question, some answers fit in the categories above. I have not
corrected or moved these answers for transparency. I found it interesting
there is a near precise 50/50 split between hardware users and emulators. It
will be interesting to repeat the question in a year and see how the balance
changes. Combining these answers with others, it seems reasonable to
conclude that the single largest QL platform is QPC at around 40% of total
primary machines. The Qx0 is the dominant replacement hardware platform =
limited I suspect only by quantity made. Very impressive. I neglected to
include the Amiga and ST - my bad! Also interesting to note that it's likely
only 3% of users don't have access to floppies on their QL...
Question 2*Which other systems do you own? (Please mark all that apply)* 128K
or 640K QL  44
 18%  QL with expansion card (eg: Floppy Parallel TK2)  41
 17%  QL with Gold Card  26
 11%  QL with Super Gold Card  21
 9%  QXL  15
 6%  Aurora  17
 7%  Q40/Q60  5
 2%  Free software emulator  38
 16%  Commercial software emulator  31
 13% *ID**Other:*
4302001Note - invalid question - I have no other.
4302278Atari ST/E with hardware QL emulators
4303208Atari STe + SMS2
4304124QDOS on Amiga (no emulator) SMSQ/E on Atari (no emulator)
experimental 68060 self-built QL
4307955Also Thor and OPD
4309788A non functioning Thor F2, waiting for repair.
4312335Q-Emulator
4347254QXL card
4303858I regret I put my QL in a heavy DEC case (monitor + keyboard +
floppy) and it's not portable anymore (seemed like a good idea at the time,
to get better keyboard and monitor instead of TV). Result is it's boxed and
I don't use it anymore.
4414132Mini-tower w/ 4x floppies and who knows what else (Aurora, Qbide?)
whose details I don't know, it having been put together by my dad before he
died.
This question was optional.
Question 3*How many different QL systems, hardware and emulators, do you
own?* No others  3
 4%  1  2
 3%  2  16
 22%  3  16
 22%  4  9
 12%  5+  27
 37%
93% of QLers have two or more QLs!
Question 4*On your primary system, what is the main OS you use?
* QDOS  21
 28%  Minerva  9
 12%  SMSQ/E  42
 57%  Other  2
 3% *ID**Other*
4379480use all three from time to time
4414132SMSQ on QPC, QDOS on SGC.

Question 5*On your primary system, how much memory do you normally have
installed or configured?* 128 KB  3
 4%  384 - 640 KB  6
 9%  896 KB  3
 4%  1 MB  4
 6%  2 MB  7
 10%  4 MB or more  47
 67% *ID**Please describe anything about your system not covered above?*
4300920I have a plug-in Romdisk in the top edge extra slot. Loads Xchange
(optional) spellcheck (optional) and any of my little facilities that I need
for the job, all from memory. Marvelous!
4301197Q-emuLator 1 for Mac set to 4Mb with JS ROM
430227816 or 24 Mb, depending on usage My ST..QPC systems all have HDDs
4303809Running QPC2 configured with 16MB under Windows XP.
4304548I am not sure how much memory was provided in an original Q40 (two
DIY boards to be installed in a case and peripherals added)
4314351Standard for QXL
4406414I run QPC configured to use 4 MB RAM.
4414132512MB QPC / W98; 4MB SGC / QDOS.

Question 6*On average, how often do you use your QL(s)?* All day every day!
 2
 3%  Daily  19
 26%  Weekly  23
 32%  Monthly  11
 15%  A few times a year  12
 16%  Not much anymore  6
 8%  Never  0  0%
I find this answer impressive. 61% of QLers use their QLs at least weekly!
76% use them monthly or more.
Question 7*Do you expect to buy new QL hardware, if something interesting
was released?* No  11
 15%  Yes if it's under 100 euros  20
 28%  Yes if it's 

Re: [Ql-Users] The First Survey - Results!

2011-02-28 Thread Norman Dunbar

 Question 14*Can you program in Assembly Language?* Yes  32
  44%  No  40
  56%
As I thought, only George and I read my articles on QL Assembly
Language! ;-(

 ...

 4340156 do not no, never seen it but people seem to refer to it as ql toady
 which implies its full of mistakes
This is a joke right? Complaining about mistakes with this grammar! ;-)
(That was a joke too!)

The reason for calling it QL Toady is not because it is full of
mistakes, but someone spelt (spelled? Tony which is correct?) it
incorrectly once and it stuck as it is somewhat amusing.

I can see where this is coming from though, The Guardian often has
spelling mistakes and is known as The Gruniard.

Mmmm. Very interesting point this person has brought up - should we stop
calling it QL Toady? We could be sending out the wrong signals.

 ...


Cheers,
Norman.

-- 
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] The First Survey - Results!

2011-02-28 Thread Dave Park
On Mon, Feb 28, 2011 at 2:15 PM, Norman Dunbar nor...@dunbar-it.co.ukwrote:


  Question 14*Can you program in Assembly Language?* Yes  32
   44%  No  40
   56%
 As I thought, only George and I read my articles on QL Assembly
 Language! ;-(


You read your own articles? Isn't that like laughing at your own jokes? :P


  4340156 do not no, never seen it but people seem to refer to it as ql
 toady
  which implies its full of mistakes
 This is a joke right? Complaining about mistakes with this grammar! ;-)
 (That was a joke too!)

 The reason for calling it QL Toady is not because it is full of
 mistakes, but someone spelt (spelled? Tony which is correct?) it
 incorrectly once and it stuck as it is somewhat amusing.

 I can see where this is coming from though, The Guardian often has
 spelling mistakes and is known as The Gruniard.

 Mmmm. Very interesting point this person has brought up - should we stop
 calling it QL Toady? We could be sending out the wrong signals.


I have never seen a typo in QL Today. But then, the headline on my last copy
was Q60 released! QL Today and Quanta are both in the modern struggle to
stay relevant when the internet is a more immediate information source. They
can't get by just by providing news any more. Quanta does have the
advantage of being a club and having many other services.

That said, it becomes more important than ever for both to be accessible,
informative and a resource.

I'd start by putting every past issue of their magazines on their respective
websites in a password protected area, and publish the password in the
current magazine. Change the password once a year. Next, I'd start properly
maintaining the websites to be current and to have local content. I'd get
the local clubs to appoint a publicity person to get the local club news
to the national site organizer promptly.

Finally, I'd do things like this survey, and share the results, then try to
act on them by addressing failings of the community like lack of new
hardware and software...

Also, how about an annual award ceremony for best new h/w, software,
utility, lifetime achievement awards - so we can all pat ourselves on the
back? *grins* Heck, I might even go to England for that.

But that's what I would do. I'm not Quanta or QL Toady. :)

Dave
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Ser-USB Driver running under Q-emuLator

2011-02-28 Thread Tony Firshman

Adrian Ives wrote, on 28/Feb/11 11:33 | Feb28:

Tony,

If you're talking about the drivers built into the USBWiz, there's USB
printer support and HID for mice and keyboards. However, nobody should get
excited about that because the USB printer support appears to be raw data
only so it would need a driver written.  Keyboard and mouse might be
possible, but I've already covered the problems of running them across the
same serial connection as used for the storage devices.

Yes exactly as I remembered - printer support is next to useless.


Beyond that, it would be possible to talk to just about anything USB ...
with a driver.

The Ser-USB driver currently supports SD Cards and USB Mass Storage devices;
both accessed in native QDOS mode.


Those were the two that immediately looked practical.
I thought it  supported only FAT 8.3?  How do you work around that?

Tony

--
QBBS (QL fido BBS 2:257/67) +44(0)1442-828255
   t...@firshman.co.uk http://firshman.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Ser-USB Driver running under Q-emuLator

2011-02-28 Thread Adrian Ives
Tony,

I don't use the file system access functions, only direct sector access. The
SD card or USB hard drive really is formatted as a QLW1 volume.

otoh The File Manager (which is a standalone program independent of the
driver) does use the file system access functions to let users move files
between PCs and QLs using FAT16 format media.  This obviously means that QL
filenames are truncated to 8.3, but their headers are preserved.

Adrian

-Original Message-
From: ql-users-boun...@lists.q-v-d.com
[mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Tony Firshman
Sent: 28 February 2011 21:58
To: ql-us...@q-v-d.com
Subject: Re: [Ql-Users] Ser-USB Driver running under Q-emuLator

Adrian Ives wrote, on 28/Feb/11 11:33 | Feb28:
 Tony,

 If you're talking about the drivers built into the USBWiz, there's 
 USB printer support and HID for mice and keyboards SNIP

 The Ser-USB driver currently supports SD Cards and USB Mass Storage 
 devices; both accessed in native QDOS mode.

Those were the two that immediately looked practical.
I thought it  supported only FAT 8.3?  How do you work around that?

Tony


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


Re: [Ql-Users] Help: Function to tell whether display is better than QL standard

2011-02-28 Thread ql

Am 28.02.2011 um 17:45 schrieb Marcel Kilgus ql-us...@mail.kilgus.net:


It began life as SMSQ, a QDOS-compatible version of SMS2 intended for
the Miracle Systems QXL emulator card

But yes, it did not include the PE, that was only the case of the /E
versions. But I still think this is a fringe case, it didn't even
include any BASIC language after all. It was pre-release software and
should be ignored for any new development, I think.
SMSQ was not pre-release only. Miracle supplied free updates IIRC  
until version 2.76 which were insync to the the bigger SMSQ/E. Only  
the very early versions of SMSQ did not have the complete SBASIC  
interpreter. The others had the same SBASIC as SMSQ/E. But yes, no  
integrated PE. This had to be LRESPRed. I used SMSQ to continue  
development of QTop (most parts of it are written in S*BASIC) in  
1994/1995 and to test if a piece of software works fine w/o PE.


Urs 
___

QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm