[REQ:ASM] Reading a keystroke

[ross]

Originally Posted by Photon

I'm not 100% sure this routine is compatible with A2000 keyboards made by Cherry (difference in behavior). All hardware routines should be checked on this combo(!)

What's the difference? Timing for the handshake?
(on my routine I wait 85us)

[Asman]

@Photon
As I see in ChkKey.S you are waiting at least one scanline. In worst case it will be one scanline and it will take 63.5us. No offence, but I think is it not enough for handshake.

[Leffmann]

Up to 200 µs needed for some Cherry keyboards apparently.

Reading vhposr and waiting for 4 line changes should work best, you'll get a delay no less than 192 µs (probably closer to 200 with code overhead), and no more than 256 µs.

If you want an even simpler routine you can just ignore the delay and handshake next VBL or whenever you call your keyboard routine. You'll get low throughput and can't use it for proper typing, but it's enough if you just want to register a few keypresses.

[ross]

Originally Posted by Leffmann

Up to 200 µs needed for some Cherry keyboards apparently.

Heck! 200 µs..

Well, i use CIA timer so is a simple value change, but this keyboard is totally out of specs!

[Photon]

Yes, this is the oldest routine then, modify as you like. It was mostly because I couldn't quickly see a runnable routine with Rawkey LUT linked.

I did a search through my later source backups but apparently I haven't commented the code with the fix... so I can't provide it quickly now. If I find it I will post it. But it was mostly about these special keyboards. Like there are some floppy drives that ignore HRM also and require a blind 500ms wait somewhere.

[ross]

Originally Posted by Photon

If I find it I will post it. But it was mostly about these special keyboards.

Thanks Photon.

Anyway, one more reason not to use the wait by scanlines wait.
Too many time lost..

Like there are some floppy drives that ignore HRM also and require a blind 500ms wait somewhere.

The very same reason 'cause on my loader I blindly wait

Cheers

[ross]

Originally Posted by phx

You may also look into input.asm from the Solid Gold source (should be the same in Trap Runner). It implements a Level 2 keyboard interupt handler and a FIFO queue for fast typing. Nevertheless it's quite compact.

Just Looked at input.asm: good and compact routine, very similar to mine (i've to look at SG source more often!).

You have opted for 'interior' CIA wait, I've an 'exterior' wait (I start a timer and differ the handshake so I dont waste cycles on fast machine).
Moreover my L2 IRQ manager is more general because i've a dispacher for the variuos sources (also other timers and TOD),
but I change it according to the needs, it can also become with only the handshake and without buffer since I use it for the various games/demos patches.
And the request for a Disable() when you've to read a key is a bit to much, I prefer a semaphore

But I like also Photon approach for the qualifier keys.
The best would be for a "bit level" approach like used by system in InputEvent.ie_Qualifier (well, actually if I need a qualifier I opt for the input.device method )
One day i'll rewrite a routine that sum-up all this goodies..

Cheers!

[Tigerskunk]

Wow, thanks for these many answers, my friends... Will have a look into this over the next days..

This is really a great place...

[phx]

Originally Posted by ross

You have opted for 'interior' CIA wait, I've an 'exterior' wait (I start a timer and differ the handshake so I dont waste cycles on fast machine).

True. I'm optimizing my games always for the slowest supported architecture, so I didn't think it was worth it. Especially when key presses are rather rare within the game (usually just ESC to quit it).

Interestingly, the "interior handshake" seems to be the prefered method by OS drivers. AmigaOS keyboard.device and NetBSD /dev/kbd do it the same.

And the request for a Disable() when you've to read a key is a bit to much, I prefer a semaphore

This was rather a note to myself than a request. My games usually runs in a VERTB-routine, so I am always safe to call getkey.

One day i'll rewrite a routine that sum-up all this goodies..

LOL
Please do!

[NorthWay]

I have one of those A2000 Cherry keyboards (currently connected to my A1000).
It is mindblowing how many games it doesn't work with - you get one single keypress and then it is total incommunicado.

For my own simpleton key reading I just did a bunch of e-clock accesses to waste time.
You should ofc use a timer interrupt for anything better than a 7MHz 68000....

[Tigerskunk]

@phx: unfortunately, I get a lot of errors regarding autovecbase, which I don't use in my code.
Just copying the variable from OS.asm didn't do the trick it seems..

[phx]

AutoVecBase must be initialized with the VBR.

When you still have assembler errors, although the symbol exists, then I guess you are confused by the Small Data model I am using (all variables are addressed base-relative via A4). Remove the "(A4)" from all instructions.

[Photon]

Northway just helped me verify that >=200 microseconds handshake is the only modification required to fix skipped or frozen key values on the Cherry A2000 keyboards

[dissident]

Originally Posted by ross

What's the difference? Timing for the handshake?
(on my routine I wait 85us)

How does your routine look like?

Mine is based on an article of the German Amiga Magazin from 1992. See enclosed page as pdf.

My code looks like this:

keyboard_handler
  btst    #CIAICRB_SP,CIAICR(a4) ;CIA-A SP-Interrupt ?
  beq     kh_no_keyboard_handler ;No -> skip
  btst    #CIACRAB_SPMODE,CIACRA(a4) ;Output ?
  bne     kh_no_keyboard_handler ;Yes ->skip
  move.b  CIASDR(a4),d0      ;Keycode
  ror.b   #1,d0
  not.b   d0  
  bmi.s   kh_reset_serial_port ;Key released -> skip
  tst.b   kh_key_flag(a3)    ;Keycode already saved?
  bne.s   kh_reset_serial_port ;Yes -> skip
  move.b  d0,kh_key_code(a3) 
  not.b   kh_key_flag(a3)    ;Set key flag
kh_reset_serial_port
  moveq   #FALSE,d0
  move.b  d0,CIASDR(a4)      ;Pulse: Set SP line = low
  moveq   #CIACRAF_SPMODE,d0
  or.b    d0,CIACRA(a4)      ;Serial port output, start handshake
  moveq   #CIACRBF_START,d0
  or.b    d0,CIACRB(a4)      ;Start timer for delay 85 microseconds
kh_delay_loop
  btst    #CIACRBB_START,CIACRB(a4)
  bne.s   kh_delay_loop
  moveq   #TRUE,d0
  move.b  d0,CIASDR(a4)      ;Pulse: Set SP line = high
  moveq   #~CIACRAF_SPMODE,d0
  and.b   d0,CIACRA(a4)      ;Serial port input, stop handshake
kh_check_key
  clr.b   kh_key_flag(a3)    ;Clear key flag
  move.b  kh_key_code(a3),d0
  cmp.b   #kh_key1,d0        ;F1 ?
  ...

I don't see in all the code examples pulsing the SP line for the handshake low then high.

[phx]

Originally Posted by dissident

I don't see in all the code examples pulsing the SP line for the handshake low then high.

Loading the SDR with 0, as in your example, is not required. To my knowledge handshaking only needs you to set the SP to output for some time (I use 65 ticks).