The Sinclair QL Forum

Does the Hermes chip fix the keybounce problem with these?

There are also some SuperHermes in production

RWAP wrote:Does the Hermes chip fix the keybounce problem with these?

There are also some SuperHermes in production

The keybounce problem with the Schön PC-style keyboard was a keyboard one. They work perfectly in the beginning, but the graphite under the caps was not very well manufactured. This gave bouncing letters after a while.

What you can do or not do with the 8049 (or, rather, a replacement for it) depends solely on interface to the rest of the QL - And that is, in good old Sinclair tradition, unfortunately minimal.

The 8049 in the QL is not directly connected to the 68008 bus, but rather clumsy through a serial (sic) interface that connects into the 8302. Everything that needs to go into the QL needs to be transported over this (quite slow, because bit-banged) interface.

Regards,
Tobias

Silvester wrote:The only other option that comes to mind is perhaps using spare IO on 8049 and mouse driver on QL polling IPC.

On the standard 8049 IPC there is one spare output pin P23 that can be used (redundant IPL1, pin needs isolating), and one input pin P26.

Normal IPC calls can be used: P23 output is set by call IPC 12, P26 read using IPC 01

Perhaps AVR can use P26 input to flag mouse activity. A poll job on QL could then set P23 to signal to AVR that a read for mouse status on matrix input is required, rather than keyboard. The byte read could simply emulate QIMI port (easy to patch PTR_GEN for this).

RWAP wrote:There are also some SuperHermes in production

Nice out-of-the-box solution, but I have a couple of Enhanced Logitech keyboards and twin scroll mouse I would like to hook up to a QL. IIRC Tony and Lau had headache getting it recognise most PS/2 variants. Modern AVRs can now do on chip what S/H PCB does, and it would be nice to have open design.

Ralf R. wrote:I also had this. Lasts two years, then the same faults.

I've made mine last 26 years! Had it to pieces about 5 times, after a thorough clean it lasts a while. Even tried painstakingly fixing foil pads to every key (OK for TV remotes etc). Just made the keybounce wwwwooorrssseeee.

The QL Schon replacement keyboard didn't get so much use and has only had to be clean once. Still works as good as new.

BTW I recall Keyboard Products did a final offer back in 1990 (?) reducing PS/2 to £72 and QL replacement to £22. I ordered another one of each, but after several months nothing turned up. When I phoned them they said they didn't get enough interest to do another batch (!) and returned my cheque.

tofro wrote:Everything that needs to go into the QL needs to be transported over this (quite slow, because bit-banged) interface.

Indeed, but it is at least reliable. I always thought QL IPC serial was dodgy, but I've yet to get a USB serial adaptor to work on a laptop above 9600 reliably (CH340 or PL2303).

Silvester wrote:

Silvester wrote:The only other option that comes to mind is perhaps using spare IO on 8049 and mouse driver on QL polling IPC.

On the standard 8049 IPC there is one spare output pin P23 that can be used (redundant IPL1, pin needs isolating), and one input pin P26.

Normal IPC calls can be used: P23 output is set by call IPC 12, P26 read using IPC 01

Perhaps AVR can use P26 input to flag mouse activity. A poll job on QL could then set P23 to signal to AVR that a read for mouse status on matrix input is required, rather than keyboard. The byte read could simply emulate QIMI port (easy to patch PTR_GEN for this).

Hmmm.... that's a really interesting idea, thanks for sharing! I'll give this some thought and do a couple of experiments.

I'm assuming this approach would not work with a Hermes chip?

Cheers,
Petri

ppe wrote:I'm assuming this approach would not work with a Hermes chip?

Should do.

Snippet from Hermes manual on extra IO:

• Hardware
  
  For those of you who indulge in soldering iron work, it may be of
  interest that HERMES has now "liberated" some of its legs. (A strange
  turn of phrase...)
  
  The old 8049 could tell you the state of P26 (pin 37), which was an old
  microdrive write protect idea that never worked. It could also be
  persuaded to drive P23 (pin 24), which was supposed to be "microdrive
  reduced sensitivity", but actually got wired to INT2, causing all sorts
  of mayhem. Actually, the QView CAPSLED kit uses this output to drive
  an LED, but only after bending the leg out.
  
  With the new serial handling in HERMES, P20 (pin 21, serial input) and
  T1 (pin 39, BAUDX4) are no longer required.
  
  There are now provisions in HERMES for using all the spare pins. You
  can use P20, P23 and P26 as inputs and/or outputs. T0 (pin 1) and T1
  may also be used as inputs. If T0 is not required as an input, it can
  be told to output a clock which will be 3.67MHz (11/3).
  
  Note that, to read the input on P20, P23 or P26, they must have had a
  one sent to them. This is the case at startup, but if you try to use
  one of them for both input and output, you won't get anything but zero
  back from it unless the last thing you sent to it was a one.

Silvester wrote: Indeed, but it is at least reliable. I always thought QL IPC serial was dodgy, but I've yet to get a USB serial adaptor to work on a laptop above 9600 reliably (CH340 or PL2303).

..ooOO

I have about a billion of those things due to my job, never had a problem with them.