Rich Mellor wrote:Must be a breakdown somewhere then because I have v3.07 of the non-colour SMSQ/e for Gold Card
We will work on that.
Good :-)
<<cut>>
No, it should absolutely not return an error. A colour driver is present. Only a 4 colour driver, but a colour driver nonetheless!OK fair enough - but why does it return an error on the PE - must be missing something here.
Just because both drivers only provide 4 colours does not mean they have the same interface. The SMSQ/E driver is a GD2 4-colour driver, the PE for QDOS bases on the QDOS CON driver, which is not GD2.
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??). I guess the GD2 4 colour palette matches the colours in the GD2 256 colour palette (unless redefined of course) .
What happens if a BASIC program uses WM_INK command - on high colour smsq/e it will use the 256 colour standard 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 ?
So in this case, it is completely impossible for software to tell if the version of SMSQ/e in use provides the high colour drivers or not.
That's basically what I was saying all along, yes. We could only provide a new call that returns 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?
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. 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 !?
However, it should not crash the system as I get with PRINT RW_GD2 (using my routine - it prints 1 and then crashes).
No it shouldn't. But it could also be your code, how can I know? The snipped posted is not enough to see that (mainly the definition of "Hardware_Flag" is missing, as is "float_ret").
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?
I must have missed something there cos I do not recall it saying that WMAN's traps for the new ink and paper commands would return not implemented,
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
but smsq/e wouldn't even though they are not implemented if there is no colour driver. Surely the PE should also provide the same result, as it should presumably use the 4 colour driver as SMSQ/e??
The 4 colour driver is NOT part of the PE. It is part of the OS. The SMSQ/E 4 colour driver can do the INK call, therefore no "not implemented" error, the QDOS/Minerva 4 colour driver cannot do the call, therefore a "not implemented" error.
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 !
<<cut>> -- 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
