George Gwilt writes: > As everyone will realise by now, the events given to WM.RPTRT in D2.B are job > events, not pointer events. So, obviously, WM.RPTRT will return on any > pointer event just as WM.RPTR does whatever the value in D2.B.
Sorry I wasnt more helpful but Ive been extermely busy being lazy this Christmas. Glad you resolved it. > However, there is another question (which I may be able to answer before > anyone else too). The addition of job events to SMSQ/E has caused a change in > IOP.RPTR. This will now allow a return from a job event. The manual states clearly > that the job event will be placed in the top 8 bits of the pointer event > (pt_pvent) in the status area. It also seems to suggest that the top 8 bits of D2 > in a call to IOP.RPTR should contain the job events on which to return. A > short test seems to bear this out. Now comes the question. > > Since the original IOP.RPTR asks for D2.B to be set, does this not mean that > old programs calling the routine might find peculiar things happening? For > example, the contents of D2.L could have $FF as the top byte. D2 might have been > -1 before D2.B was set with the required pointer events return. In that case > any job event sent to the program would cause a spurious return. > > What steps have been taken to prevent this? I have no intelligent answer to this. However, I expect that in most instances people will have used a moveq instruction to set the byte in d2.. Per
