Re: [ql-users] WM.RPTRT again
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 versions. iop_flim Aug 02 sms_sevt Jun 02 sms_wevt Jul 02 wm_rptrt Jun 02 The last update on Dave's sight that I found incuded the GD2 LIBC routines from March 2001. Jim It is very useful to have a note of these corrections to libc_a. I have looked at iop_flim, sms_sevt and sms_wevt as they are on my libc_a. Only sms_sevt has an error as far as I can see. The error is that the 2nd parameter is loaded from 6(a7) instead of 8(a7). The other two functions worked when I put them into C programs. I would therefore be very grateful if someone could say what the errors are in iop_flim and sms_wevt. As I have already said I have changed wm_rptrt in my libc_a to correct it and also to return only D0. (BTW wm_rptrt is declared as "int" and not "chan_t"). Another error was reported to me some years ago. In ut_scr #$C8 is used instead of $C8 when calling the ut_scr vector. I have corrected that too in my libc_a. Has anyone else detected further errors in libc_a? George
Re: [ql-users] WM.RPTRT again
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 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 versions. iop_flimAug 02 sms_sevtJun 02 sms_wevtJul 02 wm_rptrtJun 02 The last update on Dave's sight that I found incuded the GD2 LIBC routines from March 2001. Jim On Jan 6, 2004, at 7:22 AM, Marcel Kilgus wrote: 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 Jim and I that stumbled across this almost 2 years ago. And I, too, thought it has officially been fixed since then. On a slightly different tack, what is the state of play on implementing new WMAN vectors for use in C68. At the moment, C68 calls to QMENU enjoy 3-d buttons etc. etc. but homegrown windows do not yet. Well, you don't really need any new vectors to enjoy the new colours, it's just a matter of the colour values in the menu definition (my modified Qascade for example is a C68 application, too). Marcel
Re: [ql-users] WM.RPTRT again
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 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
Re: [ql-users] WM.RPTRT again
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 Jim and I that stumbled across this almost 2 years ago. And I, too, thought it has officially been fixed since then. On a slightly different tack, what is the state of play on implementing new WMAN vectors for use in C68. At the moment, C68 calls to QMENU enjoy 3-d buttons etc. etc. but homegrown windows do not yet. Well, you don't really need any new vectors to enjoy the new colours, it's just a matter of the colour values in the menu definition (my modified Qascade for example is a C68 application, too). Marcel
Re: [ql-users] WM.RPTRT again
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 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've just come back - it seems to me that these are 2 different calls .RPTR and .RPTRT. Only the second has the additional parameters (from the start). So no overlap or problem there! Wolfgang
Re: [ql-users] WM.RPTRT again
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
[ql-users] WM.RPTRT again
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
