unsubscribe
- this (gobo...@tiscali.co.uk)
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 = $72), to
read/scan a pixel, is not implemented on the current versions of SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
George
___
QL-Users Mailing List
gdgqler wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where the API is difficult to apply
anyway.
Marcel Kilgus schreef:
gdgqler wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where the API is
François Van Emelen wrote:
Isn't that the reason why 'RPXL% (Easyptr) doesn't work correctly?
Sure. But it's been this way for exactly 10 years now ;)
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
On 19 Feb 2010, at 11:52, Marcel Kilgus wrote:
Has anyone noticed that iop.rpxl, which is the trap #3 call (d0 =
$72), to read/scan a pixel, is not implemented on the current versions of
SMSQ/E?
The entire code seems to be:
moveq #-15,d0
rts
Only in the high colour modes, where
gdgqler wrote:
I cannot see a need for it. It is nice to know that it is
intentionally not used in SMSQ/E. However, the message that is given
if you do try it is faulty parameter, which is slightly confusing.
Ah, I see. Not implemented would make much more sense, yes. But
nobody has touched it
There has been a problem with reading pixels using this trap for ever or
at least since display modes became richer. I asked about it in this
group a year or two back but this attracted no interest at the time. I
was trying to write a flood facility into my CAD program but ended up
having to read