Please excuse my ignorance - if all this was written in a single document somewhere, it would help.
Now I have a little more time on my hands, maybe you could send me the originals of the various articles and anyone else who has made notes could email them to me, and I will attempt to put it all together into one document.
Rich Mellor wrote:OK, so any machine code program which utilises the new system calls has to check for an error return and if present use the old IOW.SINK command to set the ink colour - presumably this will require a different value in D1 to that passed to the GD2 4 colour driver (or will it??).
Why should it? IOW.SINK has not changed its meaning ever.
Not sure where this is leading.
If a machine code program wants to set up the colours for a specific text printed to screen, what should the procedure be?
a) Check MT.DMODE to see if we are in a high colour mode or not
b) Use IOW.INKP to set the colour palette colour according to the colour mode - although if colours are chosen carefully, it shouldn't matter whether the machine is in MODE 4, MODE 16, MODE 32 or MODE 33 here. However, the programmer may like to adapt the colour scheme to take account of extra colours available or not.
c) If IOW.INKP returns an error, then use IOW.SINK to set a standard QL colour.
I thought the point of the new WMAN was to avoid needing to revert to (c) but it seems this is necessary on non smsq/e systems.
What happens if a BASIC program uses WM_INK command - on high colour smsq/e it will use the 256 colour standard palette,
...or the QL palette, or gray colour, or 15bit colour, or system palette.
on standard smsq/e it will use the 4 colour palette (presumably giving the same colour) and on the latest PTR_GEN/WMAN what happens?
It tries its best to match the colour you give it.
OK though a program is going to struggle if it does not adapt to the fact that a lot less colours are available - otherwise it could end up with black text on a black background, or some combination which would not look ery good (green on white - QPAC 2 suffers from this - especially when you select all files - I really must try to alter the colour settings for QPAC2).
So where is this documented so I can check?The only option that is currently there is to read directly from the CON driver linkage (byte $142, I think, should be non-zero if Aurora-256 driver is present). Again, there is currently NO other way.
It is not documented anywhere. This is a purely internal variable. It is not meant to be read by applications. But as this is currently the ONLY way to do it, what else do you expect me to answer?
OK fair enough - I will use this then :-)
As pointed out earlier - there appears to be no valid way of reading the current INK, PAPER and STRIP colours set by the GD2 calls.
This is true.
The standard ones are stored in the CON driver linkage at offsets $44 - $47. Surely a program might want to check what these values are?! These appear to be set to zero after using WM.INK for example !?
If you tell me how to put a 16 bit value into 8bits, we could also again write them at the default locations. Where it is actually written to is no secret but documented in the GD2 documentation.
Yes I know that, but surely there is space somewhere in the con driver linkage - after all you are using byte $142 when the original was only $68 bytes long.
What do the other $84 + bytes contain??
You say where the ink colour etc is written to appears in the GD2 documentation - well its not in the copy I have (issued by Tony Tebby when the colour drivers were first released)... Anyone point me to the right file on the internet?
I will email the extension direct. However, the command does not crash high colour smsq/e or QDOS/Minerva, so why should it crash standard smsq/e?
Chance? It looks like you're overwriting pt_lext!
Certainly looks like it - thank god you spotted this (phew)
What does WMAN have to do with it now? WMAN does not even have one single trap!OK my mistake - PTR_GEN adds the traps, WMAN the keywords does it not? You have the benefit of the source codes - I don't
And this is because of what?
Help yourself, there are enough sources for everyone: http://www.scp-paulet-lenerz.com/smsqe/
These do not include the sources for PTR_GEN and WMAN do they (except in so far as they are part of smsq/e).
OK fair enough so machine code programs will need to check for this not implemented error as said - again there is no documentation to let programmers know this !
Documentation might be a bit lacking, but I have tried to explain it as thoroughly as I can do. I cannot document it any better, I'm sorry.
-- 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
