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. > 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. >> 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. > So where is this documented so I can check? 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? > 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. > 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! >> 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/ > 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. Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
