Re: [ql-users] Philips USB chip (and Qx0 systems)
On Wed, 14 Apr 2004 13:10:44 +0100, Tony Firshman [EMAIL PROTECTED] wrote: On Mon, 12 Apr 2004 at 21:23:55, Marcel Kilgus wrote: (ref: [EMAIL PROTECTED]) And for the future (also good to check whether a mail has arrived at the list): http://www.mail-archive.com/ql-users-q-v-d.com%40lists.q-v-d.com/ ... and this archive shows the importance of not using literal email addresses, even in the signature. I also found this which I would love to try ;-) Phoebus ___ QL-Users Mailing List
Re: [ql-users] AGM Workshop 2004
Tony Firshman wrote: It was a pity the last Quanta was so incomplete (8-(# I think that's being a bit unfair to the acting editor. Pages 23 24 seem to have all the relevant info. John ___ QL-Users Mailing List
Re: [ql-users] Philips USB chip (and Qx0 systems)
At 11:09 15.04.04 -0400, =?iso-8859-7?B?IlBob2VidXMgUi4gRG9rb3MgKNbv3+Lv8iDRLiDN9Pzq7/Ip wrote: On Wed, 14 Apr 2004 13:10:44 +0100, Tony Firshman [EMAIL PROTECTED] wrote: On Mon, 12 Apr 2004 at 21:23:55, Marcel Kilgus wrote: (ref: [EMAIL PROTECTED]) And for the future (also good to check whether a mail has arrived at the list): http://www.mail-archive.com/ql-users-q-v-d.com%40lists.q-v-d.com/ ... and this archive shows the importance of not using literal email addresses, even in the signature. I also found this which I would love to try ;-) Doh! I meant : url:http://www.simtec.co.uk/products/EB1161ISA/ You'd like to try what? Writing native USB drivers? :-) Thanks for the pointer! I knew the chip, but didn't see an ISA card yet. Possibly a nice toy for Qx0 Linux. All the best Peter ___ QL-Users Mailing List
Re: [ql-users] AGM Workshop 2004
On Thu, 15 Apr 2004 at 16:26:12, John Hall wrote: (ref: [EMAIL PROTECTED]) Tony Firshman wrote: It was a pity the last Quanta was so incomplete (8-(# I think that's being a bit unfair to the acting editor. Pages 23 24 seem to have all the relevant info. I assumed the last edition was the thin 4 month one - I have not seen anything since except a letter asking for my subscription renewal! As an advertiser - probably the longest standing one now - I actually don't subscribe. John G - I assume my payment arrived OK? -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List
Re: [ql-users] Philips USB chip (and Qx0 systems)
On Thu, 15 Apr 2004 12:34:06 -0400, Phoebus R. Dokos ( . ) [EMAIL PROTECTED] wrote: It comes standard with Linux drivers. Probably an afternoon for Richard to port ;-) So there a potential solution for Qx0 owners to have USB (and ugly EPSON printers ;-) hehehehehe, digital cameras etc) Phoebus ___ QL-Users Mailing List
Re: [ql-users] iop.rpxl
On 24 Feb 2017 at 23:33, P Witte wrote: Can someone else confirm that iop.rpxl is broken in recent versions of SMSQ/E. It doesnt work in hicolor mode, only in QL colour. Try Qptr RPIXL or EasyPtr RPXL%, or indeed iop.rpxl itself. As Marcel pointed out, this is simply not implemented in high colour mode. One of the reasons for this is that there is no specification (yet?) as to how the colours to be given/returned are to be handled in that mode. As a reminder, the trap may - scan a window until a required colur is found, and then return the position of that colour, or - return the colour of a pixel at a given coordinate. To work correctly, it requires, on entry: D1 to contain the x,y coordinates of pixel to be returned or where the scan starts D2 to contain the colour in the low word and some flags telling the trap what to do, in the high word. For high colour graphics, there are two questions here: - how is the colour to be specified when entering the trap, - how is the colour to be specified upon returning from the trap. After all, we could potentially specify these colours as QL colours(2/4 bits), native colours (16 bits or 8 bit for Aurora), 8 bit colours (palette) or 24 bits. Passing/returning the colour as a 24 bit colour would have been ideal, the trap could have made the necessary adjustments for each hardware but, as an additional complication, the required scan colour must be passed in D2 - but only in a word, which seems to rule out 24 bit colours! The trap could probably be modified, without too much work, to function correctly if native colours are passed to it - for the time being no machine uses a higher colour definition than a word, so that a colour would fit into D2.w. The great inconvenience of this is that this would force the application programmer to work too close to the machine, since he would have to obtain the native colour representation of the colour he was looking for. Hence the fact that this trap was never implemented in high colour graphics. To implement it correctly (pass a 24 bits colour, get back a 24 bits colour), the passing parameters for the trap must be changed which would probably break any existing software that used this...(is there any?). An alternative would be to create another trap with the same function, but using other parameters. However, I dimly remember that for some reasons (Minerva?) it wasn't possible to extend the trap numbers any more. Perhaps we could use a CON or WMAN vector, though. So - any ideas? Wolfgang ___ QL-Users Mailing List
