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.

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?

George

Reply via email to