Dilwyn Jones wrote:The designers should add a proper method of detection or explain how it can RELIABLY be detected. At the moment, the best you can do is look for an identifying string, which does nothing other than show it's a version able to support GD2, even if GD2 is not possible on the system.
First of all there seems to be some confusion what GD2 actually is. GD2 is an interface definition, nothing more, nothing less. It introduced new TRAPs etc. If you check for GD2, you check whether these TRAPs are available, NOT whether any high colours modes are supported. How can you check for GD2? Easy, call IOP.PINF and check the "PTR_GEN" version. I suggest to demand version 2.0 at least.
We have a reliable check for GD2 - what we do not know is how to check if using the new traps will have any effect !
Next problem, which modes are available. There I say
"Thou shalt not write applications that alter the colour depth."
Don't intend to - though it is nice to see QWord running on an Aurora under Minerva or QDOS !!
This is where my problem lay - the current PTR_GEN was telling me GD2 was available, but because Minerva has no colour drivers installed, I could not simply check the display mode and if it was 0 or 8, presume that the user wants me to talk to the display hardware directly...
Is there actually a need to know if GD2 is available when it does not provide the answer to the question as to whether there are actually any drivers for the new commands to do anything?? Surely all we really want to know is - can I use the new colour drivers?
I think my solution of (a) seeing if GD2 is supported and then (b) try to use one of the new traps and see if there is an error return will let me know whether I am running on a system without colour drivers... Is this the right approach though? Ir certainly works on Minerva using the current PE v2.
<<cut>>
It is true there is no legal way on getting to know which modes are available, although this information is of course available in the CON variables. But then I don't want people to rely on those, in case that some restructuring is needed in the future. We could however introduce a new CON vector for this purpose.
Yes this may be an idea :-)
In the absence of comments from Jochen / Marcel I think the problemis that WMAN is reporting that GD2 is available.
Even more mixed up. WMAN is a separate module and although it currently relies on GD2 it is not the place to ask whether GD2 is available.
Sorry - you are right - it is PTR_GEN I am interrogating - guess you didn't look at the code snippets.
Guess the only way of doing this is to try and use one of the new commands added by the device drivers to set the ink / paper etc...
Non starter. Then you still only know whether GD2 is there, but not whether high colour modes are supported.
Not true - my second code snippet worked on Aurora - PTR_GEN was telling me that GD2 is there, but when I tried to use one of the new traps (set strip colour to system palette), I got an error return so that I know that the colour drivers are not supported. Guess it should be error -19 that is returned...?
-- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
