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" To: 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
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
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" To: 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
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
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. 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. 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
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
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
-- 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. -- -- Marcel Not quite. UQLX does offer higher resolutions without PE (sure you can run PE on top of it.) 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. 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
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 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
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
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
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
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 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
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 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
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
Re: [Ql-Users] Help: Function to tell whether display is better than QL standard
tobias.froesc...@t-online.de wrote: > 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) 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" 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. 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
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 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
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
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
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 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
Am 28.02.2011 um 17:45 schrieb Marcel Kilgus : "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