In a message dated 07/01/04 07:47:56 GMT Standard Time, [EMAIL PROTECTED] writes:
In the meantime I had also found some issues with the following
routines and just made new wrappers that I use instead of those
included in the C libary. The dates are what I have on the files when
I made my own
Looking through some old notes, Marcel and I indeed had run across this
in Jun 02. It is in my version of LIBC_A already but looking further
and checking Dave Walker's C68 websight, I don't see any updates in
that time frame.
In the meantime I had also found some issues with the following
In a message dated 04/01/04 17:03:38 GMT Standard Time, [EMAIL PROTECTED] writes:
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
Christopher Cave wrote:
I have been watching this exchange with trepidation since I have
been using wm_rptrt surrounded by many thousands of lines of
C68 code WITH NO PROBLEM. I was under the impression that
Jonathan Hudson had sorted this call out some time ago.
Actually I think it was
On 2 Jan 2004 at 11:51, [EMAIL PROTECTED] wrote:
(...)
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
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
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
