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
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
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
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
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]
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
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
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
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
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
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
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
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
- 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
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,
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
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
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
___
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;
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
