[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 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 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 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