>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
I agree that a MOVEQ would eliminate the problem. However there are two places where that instruction is not used.
1. The C68 function iop_rptr has something like
MOVE.W $10(A7),D2
since the return parameter is "short".
Clearly this does not cater for a job event termination so I have produced a new function "iop_rptrj" which sets the correct value in D2 in the way described below for BRPTR.
2. A S*BASIC extension such as BRPTR (from TurboPTR's TPTR_EXT) will have a word parameter so that D2 is filled by something like
MOVE.W (A1,A6.L),D2
In fact, since this obviously does not correctly set the job event termination requirement in D2, I have already changed BRPTR (though the alteration is not yet issued) to
MOVEQ #0.D2 (to clear the middle 2 bytes)
MOVE.W (A1,A6.L),D2
ROR.W #8,D2
ROR.L #8,D2
(BRPTR is a function reading the pointer via IOP.RPTR)
WM_RPTR and WM_RPTRT
My original query did not concern WM_RPTR/T, mentioned by Wolfgang Lenerz in his comment. However, I have found yet another problem here. I wanted to use WM_RPTRT via C68 so I looked at the code, since I don't seem to have a description of what it does. I was amazed to see
MOVE.W $14,D3
MOVE.W $16,D2
inside it. Anyone using that version is in for a nasty shock!
Luckily the length of code for the correct
MOVE.W $14(A7),D3
MOVE.W $16(A7),D2
is the same. I have thus patched my own copy of the library. However, in addition I discovered that wm_rptrt returns either the error code (if negative) or the channel ID. This is in contrast to wm_rptr which just returns the contents of D0. Thus, although wm_rptrt with infinite timeout and zero job event termination should be equivalent to wm_rptr you will find that
while (!wm_rptr(ww))
is not the same as
while (!wm_rptrt(ww,-1,0))
since the latter will exit the while on a correct return as well as an error return.
Because of this I altered my version of wm_rptrt so that only D0 is returned and a zero test will work.
I wonder if anyone else has had trouble with wm_rptrt in C68?
George
