Re: [Ql-Users] Pic test.
On Wed, Feb 16, 2011 at 10:03 AM, Tony Firshman wrote: > Plastic wrote, on 16/Feb/11 14:48 | Feb16: > > On Wed, Feb 16, 2011 at 8:27 AM, Tony Firshman >> wrote: >> >> Plastic wrote, on 16/Feb/11 14:09 | Feb16: >>> >>> Fun, huh? :) >>> >>> >>> It was particularly good fun with sH using similar decoding chips. >>> >>> Firstly we *knew* we could use three pins only to output the 8 bit >>> keyrow. >>> >>> However Laurence then realised that the *same* three select lines could >>> be >>> used to read 8 separate input lines. This saved us ten Pic pins! >>> >>> It actually was the reason for many extra functions (spare RS232, DCD, >>> Turbo and keylock). We simply wanted to fill all eight input lines! >>> >>> >> I haven't ever owned a SuperHermes, but I have read the manual. It is a >> fine >> piece of efficient and clever design, befitting the QL. Kudos to you and >> Lau. >> >> It's just the sort of thing I'd like to build in due course... Though in >> this day and age, supporting PS2 keyboards instead of the 5-pin DIN >> keyboards might be the only worthy upgrade. >> >> Any prospect, USBWiz thread, that the USB driver could support a USB class >> keyboard? >> > sH was designed and sold many years before PS/2 keyboards were around. > It is a tribute to Lau's code that they work out of the box with the std > adapter. I wonder whether Di-ren and the others do? > Oddly designing code for these keyboards is very far from trivial. There > are oddities and bugs. When we came across these, no keyboard manufacturer > would assist. "We sent a lot of money working on these these and we will > not tell you" was Cherry's response. http://www.computer-engineering.org/ps2protocol/ http://www.computer-engineering.org/ps2keyboard/ We've come a long way since the 90s ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test. (Plus a quick update on Ser-USB)
There's a prospect of it supporting just about anything that plugs into a USB port. Converting a prospect to a working driver is another matter entirely. The main problem is going to be that you only have one serial channel to the USBWiz. So, if you're doing I/O with a USB flash drive, or the internal SD card slot, the keyboard would be blocked until at least the completion of the current Read Sector or Write Sector command. This would feel especially painful because the Ser-USB driver does fully asynchronous writes, returning the cursor almost instantly, even though the data might take many seconds longer to write. In this time you would try pressing a key and nothing would happen :( That said, I could probably enhance the driver to support multiple USBWiz's on different serial channels, but it would be a tad expensive as a hardware proposition. I have built hooks into the driver to support piggy-back processes, allowing other transactions to happen when the serial channel is free; but that facility would be woefully inadequate for any real-time transactions such as key presses or mouse movements. btw I am aiming for a test release of the driver to anyone who is interested around mid March. I have been concentrating on improved memory management, performance, compatibility and extensibility. The driver now contains no QUBIDE-era hardware interface code! Current build is 0.03.019 with support for the superHermes SER3 fast serial port. It runs happily on Aurora/SGC, but an unexpanded QL is problematic (slow ports, insufficient memory for adequate buffers). Adrian -Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Plastic Sent: 16 February 2011 14:49 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Pic test. Any prospect, USBWiz thread, that the USB driver could support a USB class keyboard? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
Plastic wrote, on 16/Feb/11 14:48 | Feb16: On Wed, Feb 16, 2011 at 8:27 AM, Tony Firshman wrote: Plastic wrote, on 16/Feb/11 14:09 | Feb16: Fun, huh? :) It was particularly good fun with sH using similar decoding chips. Firstly we *knew* we could use three pins only to output the 8 bit keyrow. However Laurence then realised that the *same* three select lines could be used to read 8 separate input lines. This saved us ten Pic pins! It actually was the reason for many extra functions (spare RS232, DCD, Turbo and keylock). We simply wanted to fill all eight input lines! I haven't ever owned a SuperHermes, but I have read the manual. It is a fine piece of efficient and clever design, befitting the QL. Kudos to you and Lau. It's just the sort of thing I'd like to build in due course... Though in this day and age, supporting PS2 keyboards instead of the 5-pin DIN keyboards might be the only worthy upgrade. Any prospect, USBWiz thread, that the USB driver could support a USB class keyboard? sH was designed and sold many years before PS/2 keyboards were around. It is a tribute to Lau's code that they work out of the box with the std adapter. I wonder whether Di-ren and the others do? Oddly designing code for these keyboards is very far from trivial. There are oddities and bugs. When we came across these, no keyboard manufacturer would assist. "We sent a lot of money working on these these and we will not tell you" was Cherry's response. 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] Pic test.
On Wed, Feb 16, 2011 at 8:27 AM, Tony Firshman wrote: > Plastic wrote, on 16/Feb/11 14:09 | Feb16: > > Fun, huh? :) > > >> It was particularly good fun with sH using similar decoding chips. > > Firstly we *knew* we could use three pins only to output the 8 bit keyrow. > > However Laurence then realised that the *same* three select lines could be > used to read 8 separate input lines. This saved us ten Pic pins! > > It actually was the reason for many extra functions (spare RS232, DCD, > Turbo and keylock). We simply wanted to fill all eight input lines! > I haven't ever owned a SuperHermes, but I have read the manual. It is a fine piece of efficient and clever design, befitting the QL. Kudos to you and Lau. It's just the sort of thing I'd like to build in due course... Though in this day and age, supporting PS2 keyboards instead of the 5-pin DIN keyboards might be the only worthy upgrade. Any prospect, USBWiz thread, that the USB driver could support a USB class keyboard? Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
Plastic wrote, on 16/Feb/11 14:09 | Feb16: On Wed, Feb 16, 2011 at 6:30 AM, David Tubbs wrote: The address decoder now knows that 1. "This address is for you" and two, it has three pins which it can now pas through a 3 to 8 line decoder: input output on 8 pins 000 = 0001 001 = 0010 010 = 0100 011 = 1000 100 = 0001 101 = 0010 110 = 0100 111 = 1000 So now the lines A8 through A10 work through the address decoder, permitted by the logic from A11+, to select which memory chip is being addressed. Obviously, this is a gross simplification of memory addressing, and the QL does it in two banks, and uses 4-bit chips so 2 chips need selecting to make the 8 bit wide data bus... But in principle, this is how it works, and this decision tree happens for every single memory access. Fun, huh? :) It was particularly good fun with sH using similar decoding chips. Firstly we *knew* we could use three pins only to output the 8 bit keyrow. However Laurence then realised that the *same* three select lines could be used to read 8 separate input lines. This saved us ten Pic pins! It actually was the reason for many extra functions (spare RS232, DCD, Turbo and keylock). We simply wanted to fill all eight input lines! 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] Pic test.
On Wed, Feb 16, 2011 at 6:30 AM, David Tubbs wrote: > If it is present, > Modified eprom board, just as easyly hold two full ROM & TK2 versions, > Mainboard ROMs removed of course. > Unfortunately, the lines aren't brought through to the ROM port to select chips outside of the 48-64K memory block, so OS chips can't be read through the port. (strictly speaking, the $8000 upper ROM could be placed in the ROM port and be readable, but that wouldn't be very useful. All that can be done with the ROM port is individual 16K ROM images can be placed there. There could be a choice of images switched in and out, but that's about it. They limited the internal $8000 ROM slot the same way - it only gets a CS signal for that 16K block, so you can't address a full 32k EPROM unless you attach the CS line from the ROM port to the upper ROM slot CS line. For those to whom this is Greek: CS means Chip Select. Take memory for example: there are 8 identical RAM chips, and each has access to the same address line (which tell the chip what address you're looking for) and data lines (where it puts the data for the address you asserted on the data lines.) As every chip is connected to the same address and data bus, you need a way to tell the chips "I'm talking to you" and so CHIP SELECT was born. So with 8 imaginary chips, and 128K of RAM, each chip stores 16k. You need an "address decoder" which takes the relevent lines of the address bus and creates an output to each chip as required. If the address bus on this imaginary computer is 16 bits wide (A0 to A15) and this 128K sits at a block from 0-128K (for example) then: A0 to A7 get passed to each chip. A8 thru A10 get passed to an address decoder A11 thru A15 get passed to a chip which makes sure they're all 0. IF they are all zero, and the address isn't over 128K, that chip tells the address decoder "this is for you." The address decoder now knows that 1. "This address is for you" and two, it has three pins which it can now pas through a 3 to 8 line decoder: input output on 8 pins 000 = 0001 001 = 0010 010 = 0100 011 = 1000 100 = 0001 101 = 0010 110 = 0100 111 = 1000 So now the lines A8 through A10 work through the address decoder, permitted by the logic from A11+, to select which memory chip is being addressed. Obviously, this is a gross simplification of memory addressing, and the QL does it in two banks, and uses 4-bit chips so 2 chips need selecting to make the 8 bit wide data bus... But in principle, this is how it works, and this decision tree happens for every single memory access. Fun, huh? :) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Pic test.
At 12:30 16/02/2011 +, you wrote: If it is present, Modified eprom board, just as easyly hold two full ROM & TK2 versions, Mainboard ROMs removed ofcourse. I tried to attach a pic, even reduced well below msg size limit of 40k no dice. I feel sure I saw one once, tho' might have been text. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
