Re: [Ql-Users] QL System information
On 17/02/2011 08:14, Lee Privett wrote: Might want to take a gander at some QL add-ons from this site, makes interesting viewing, some of them I wouldn't mind getting but alas! http://www.binarydinosaurs.co.uk/museum/sinclair/ql/addons.php Lee snip The cognoscenti come up with useful information spread around, showing that there are a bewildering number of backplanes; how could a newcomer easily find this? I still don't know what sort of backplane the original enquiry, asking who would buy one, referred to. I must admit that this is an academic exercise, as I wouldn't expect to buy one anyway. Bryan ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL System information
On 18/02/2011 09:42, BryanHorstmann wrote: On 17/02/2011 08:14, Lee Privett wrote: Might want to take a gander at some QL add-ons from this site, makes interesting viewing, some of them I wouldn't mind getting but alas! http://www.binarydinosaurs.co.uk/museum/sinclair/ql/addons.php Lee snip The cognoscenti come up with useful information spread around, showing that there are a bewildering number of backplanes; how could a newcomer easily find this? I still don't know what sort of backplane the original enquiry, asking who would buy one, referred to. I must admit that this is an academic exercise, as I wouldn't expect to buy one anyway. Bryan ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Hi Bryan, I have updated the details on the hardware page on the QL Wiki as a result of this discussion yesterday, which should hopefully help newcomers - let me know if you have any comments (or feel free to add to the pages!) -- Rich Mellor RWAP Services http://www.rwapsoftware.co.uk http://www.rwapservices.co.uk -- Try out our new site: http://sellmyretro.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL System information
BryanHorstmann wrote, on 18/Feb/11 09:42 | Feb18: On 17/02/2011 08:14, Lee Privett wrote: Might want to take a gander at some QL add-ons from this site, makes interesting viewing, some of them I wouldn't mind getting but alas! http://www.binarydinosaurs.co.uk/museum/sinclair/ql/addons.php Lee snip The cognoscenti come up with useful information spread around, showing that there are a bewildering number of backplanes; how could a newcomer easily find this? I still don't know what sort of backplane the original enquiry, asking who would buy one, referred to. I must admit that this is an academic exercise, as I wouldn't expect to buy one anyway. There is really only one 'backplane' - a device that adds extra expansion plugs to the QLs expansion connector (sometimes called 'J1' as that is its label on QL circuit diagrams). Dave has not decided exactly what his backplane will look like. In all probability he will just build some Mplanes from component stock I have - http://tfs.firshman.co.uk/ql/mplane.htm Tony -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL System information
On Fri, Feb 18, 2011 at 4:20 AM, Tony Firshman t...@firshman.co.uk wrote: BryanHorstmann wrote, on 18/Feb/11 09:42 | Feb18: On 17/02/2011 08:14, Lee Privett wrote: Might want to take a gander at some QL add-ons from this site, makes interesting viewing, some of them I wouldn't mind getting but alas! http://www.binarydinosaurs.co.uk/museum/sinclair/ql/addons.php Lee snip The cognoscenti come up with useful information spread around, showing that there are a bewildering number of backplanes; how could a newcomer easily find this? I still don't know what sort of backplane the original enquiry, asking who would buy one, referred to. I must admit that this is an academic exercise, as I wouldn't expect to buy one anyway. There is really only one 'backplane' - a device that adds extra expansion plugs to the QLs expansion connector (sometimes called 'J1' as that is its label on QL circuit diagrams). Dave has not decided exactly what his backplane will look like. In all probability he will just build some Mplanes from component stock I have - http://tfs.firshman.co.uk/ql/mplane.htm Well, yes, I do know what 'my' backplanes will look like. :) I looked at mine, and the other designs out there. There are two families of design: The riser, which stacks cards up above each other, and the low profile, which places cards side by side. It seems to me the side by side design would fit in most cases better, and it gives better access to the cards, while also allowing them to radiate and convect heat better. I think I would design something like the MPlane, but since I already have the offer to assemble the remainder, I think that's what I should do. Tony is offering me an exceptional courtesy and I would be foolish not to accept. It's a no-brainer ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[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
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
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
Re: [Ql-Users] Looking for inspiration: Death by MT.CJOB
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
Re: [Ql-Users] (no subject)
Is Dave Park about ? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What the hell happened?
In message 4d5cf9b2.9040...@dunbar-it.co.uk, Norman Dunbar nor...@dunbar-it.co.uk writes I go to Madrid for 4 days, and when I get back, I have 207 emails, unread, in my QL-Users folder! Been busy around these parts then! I'll catch up later. Cheers, Norman. Hi Norman, Yes, interesting though. I had around 180 emails to catch up on recently ... :-) -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] (no subject)
On Fri, Feb 18, 2011 at 2:09 PM, David Tubbs davet...@tiscali.co.uk wrote: Is Dave Park about ? I am. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What the hell happened?
On Fri, Feb 18, 2011 at 2:28 PM, Malcolm Cadman q...@mcad.demon.co.uk wrote: In message 4d5cf9b2.9040...@dunbar-it.co.uk, Norman Dunbar nor...@dunbar-it.co.uk writes I go to Madrid for 4 days, and when I get back, I have 207 emails, unread, in my QL-Users folder! Been busy around these parts then! I'll catch up later. Cheers, Norman. Hi Norman, Yes, interesting though. I had around 180 emails to catch up on recently ... :-) I feel I must apologise for my youthful intrusion! I imagine a mailing list seismologist would be able to look at the history of any mailing list and tell when someone enthusiastically returns to a hobby. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
