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: [email protected] [mailto:[email protected]] On Behalf Of Adrian Ives Sent: 18 February 2011 17:37 To: [email protected] 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
