Well, I really should have picked up on a6 before - it's well known that you mustn't mess with it in extensions, but this was being invoked through a RESPR/LBYTES/CALL sequence and the issue hadn't occurred to me. It didn't help that SMSQ/E (neither under QPC2 nor on an Aurora SGC) didn't cause the fault to present! ;) which actually is a tribute to SMSQ's robustness.
Adrian -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Lee Privett Sent: 18 February 2011 18:57 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB Excellent Adrian, glad to se you making progress, sorry couldn't make any suggestions, machine code like my partners Greek is a language I have great difficulty with understanding. Lee ----- Original Message ----- From: Adrian Ives To: ql-us...@q-v-d.com Sent: Friday, February 18, 2011 6:20 PM Subject: Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB Got the b***ard!!!! I had code like this bracketing it ... move.l a6,-(sp) ... my mt.cjob call and other code ... move.l (sp)+,a6 I was calling this all from SuperBASIC with a RESPR/CALL and my theory is that making a call to mt.cjob caused QDOS to do some shuffling around, changing the value of a6 - except that I then restored it with the value that it started with - now the wrong value! Now I'm one step closer to Ser-USB running on an unexpanded QL ;) Adrian -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Adrian Ives Sent: 18 February 2011 17:37 To: ql-us...@q-v-d.com Subject: [Ql-Users] Looking for inspiration: Death by MT.CJOB I'm scratching my head over this ridiculously simple piece of code that works fine under SMSQ but locks a QDOS JM-ROM Aurora/SGC every time: moveq #mt.cjob,d0 moveq #0,d1 ; Independent job moveq #16,d2 ; Enough room for job name move.l #1024,d3 ; Some stack space sub.l a1,a1 ; Start address 0 trap #1 ; Create a job It's getting called at the end of a device driver installation, but actually it doesn't seem to matter how it gets called . it locks up the OS! And as I say, SMSQ has happily executed the same code hundreds of times (if not thousands by now). I've tried numerous combinations of code size and dataspace size; the only difference being that reducing the dataspace size below 512 causes the infamous message PROC/FN Cleared to appear . and still locks QDOS. Any suggestions - however much out of the box - would be much appreciated. Adrian _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
