Keyboard wait, register reset?

[TCH]

There is the keyboard reading code, which reads raw codes.

		move.b		$bfec01,d0	
		not.b		d0
		ror.b		#1,d0

Amigadev says, that i should pulse KDAT for 85 us, but do i need that, when the OS is still in control? If yes, how do i do it?

[Thomas Richter]

Originally Posted by TCH

There is the keyboard reading code, which reads raw codes.
Amigadev says, that i should pulse KDAT for 85 us, but do i need that, when the OS is still in control? If yes, how do i do it?

No, there is nothing you need to do. If you want to capture a keyboard reset, install a keyboard reset handler via the keyboard.device (see RKRM devices), and the keyboard device will reply to the keyboard once your interrupt is run.

[TCH]

I don't want to capture a reset. I would like to read raw keycodes. But after i read the first one, i always get

$FF

.

[a/b]

You have to send a handshake before you can receive further keycodes. Something like:

  bset #6,$bfee01
; wait 85 microseconds
  bclr #6,$bfee01

[TCH]

The 85 us must be exactly that much, or at least that much? Just because this code

KbdWait:	bset		#6,$bfee01
		move.l		#$20,d0
KbdWaitLoop:	nop
		nop
		nop
		nop
		dbra		d0,KbdWaitLoop
		bclr		#6,$bfee01

is not working. (I know it's bad practice to time from CPU cycles, it's gonna get a timer, but now i would like to progress with the task itself.)

[a/b]

At least 85 microsec. This works for me (1 rasterline in PAL is ~64microsec, so waiting for at least 2 full lines):

	lea	$bfe001,a5
	lea	$dff000,a6
	move.w	#$4000,$09a(a6)

	lea	buffer(pc),a0
loop
	move.b	$c00(a5),d0
	beq.b	loop
	sf	$c00(a5)

	not.b	d0
	ror.b	#1,d0
	move.b	d0,(a0)+

	bset	#6,$e00(a5)
	moveq	#3-1,d0
delay1	move.b	$006(a6),d1
delay2	cmp.b	$006(a6),d1
	beq.b	delay2
	dbf	d0,delay1
	bclr	#6,$e00(a5)

	btst	#6,(a5)
	bne.b	loop

	move.w	#$c000,$09a(a6)
	rts

buffer	DCB.B	256,0

Press LMB and a key to exit the loop.

[TCH]

Still does not works. I've adapted your code:

		move.w		#INTEN,INTENA(a2)
		lea		CIAA,a1
WaitForLMB:	btst		#bFIR0,CIAPRA(a1)
		beq		BreakCycle
		move.b		CIASDR(a1),d0
		beq		WaitForLMB
		sf		CIASDR(a1)
		not.b		d0
		ror.b		#1,d0

; Here are the part which handles the buttons.

KbdWait:	bset		#bSPMODE,CIACRA(a1)
		moveq		#2,d0
KbdDelay1	move.b		VHPOSR(a2),d1
KbdDelay2	cmp.b		VHPOSR(a2),d1
		beq.b		KbdDelay2
		dbf		d0,KbdDelay1
		bclr		#bSPMODE,CIACRA(a1)
		move.w		#SETCLR|INTEN,INTENA(a2)
		bra		ScreenStuff

Now i always get zero after the first successful read.

[a/b]

In what state is the OS? Disabled or still running? Because...
The point of $4000->INTENA is to disable the OS so it doesn't "steal" the keycodes and you don't interfere with its regular operations. In my example I'm not doing it when I check for a single keycode, I'm doing it *globally* so the OS and its lvl2 interrupt (see below) are completely shut down and don't steal anything throughout the entire example. Which is the point since you want to read directly from hardware.
When a key is pressed, it will trigger a lvl2 interrupt set up by OS that handles the keyboard. If that is still active, it will trigger before your code will manage to read the keycode, and it's up in the air what will happen with your code.

If the OS is still fully running then you should use lowlevel.device GetKey() for example, if that's applicable (OS v40+), or something more OS friendly depending on how complicated you want it to be (you could replace/extend lvl2 interrupt handler, etc.).

[TCH]

At this point the OS is still alive. It's not a problem, if we temporarily disable the interrupts for that time, but it is still not working. One keycode comes in, and then nothing.

It's Kickstart 1.x, which means OS v34-.

[ross]

TCH, just some generic advice from me.
You must be clear about what you want to do and the conditions in which your code must operate, in this way it is also easier to help you for those who read.

You have had some different answers on this thread and many others exist on the same topic in the foum (there are several examples from me too).
The keyboard reading can be done in many different ways:
- completely through the system
- with the multitasking system active but in 'dirty mode' banging the hardware and knowing that the system will take care of the handshaking
- at system deactivated (or not) and direct management of level 2 IRQ
- with system deactivated without using IRQ2
- with system deactivated with management through recurring IRQ, which is usually IRQ3, with direct or deferred handshaking
- with system deactivated WITHOUT any IRQ but all in polling

As you can see there are many way, but each one must be handled in a different way and not mixing pieces.

First of all you need to understand how the hardware works and then what the system does.
If you leave the system active know that you will have to 'fight against it', so you need to know exactly what to do

[TCH]

The program just opens up a custom screen and then waits for keyboard strokes and depending on the keys, it will draw something on the screen.
Currently i'm looking for the simplest solution, it's not a time-critical thing.

The code i coped from a/b is mixing what with what?

[ross]

Originally Posted by TCH

The code i coped from a/b is mixing what with what?

a/b was VERY clear: "In what state is the OS? Disabled or still running? Because..."
If system is not disabled you need system calls.

Or some dirty code like this (I hope Thomas turns away, I pretend I haven't written it ):

	moveq	#20,d0
	swap	d0
	lea	$bfec01,a0
	lea	$dff006,a5
	lea	kb(pc),a1
.0	clr.b	(a0)
.1	move.w	(a5),$180-6(a5)
	subq.l	#1,d0
	bmi.b	.2
	move.b	(a0),d1
	beq.b	.1
	ror.b	#1,d1
	not.b	d1
	bmi.b	.0
	move.b	d1,(a1)+
	bra.b	.0
.2	rts

kb	ds.b	1000

But of course expect side effects.

[Thomas Richter]

Originally Posted by TCH

I don't want to capture a reset. I would like to read raw keycodes.

Why make things so complicated? IDCMP_RAWKEY events work fine.

[TCH]

@ross:
Sorry, i am not at the top of my game recently.

I've adapted the code, but the results are the same: one read, nothing afterwards.

		moveq		#20,d1
		swap		d1
		lea		CIAA,a1
WaitForLMB:	btst		#bFIR0,CIAPRA(a1)
		beq		BreakCycle
		clr.b		CIASDR(a1)
KbdLoop:	subq.l		#1,d1
		bmi.b		WaitForLMB
		move.b		CIASDR(a1),d0
		beq.b		KbdLoop
		ror.b		#1,d0
		not.b		d0
		bmi.b		WaitForLMB

; Here are the part which handles the buttons.

		bra		ScreenStuff

@Thomas Richter:
Currently i am looking the simplest solution; i've checked

IDCMP_RAWKEY

, but as i see, for this, i need to mess around with system structs and calls.

[ross]

This is the right way to adapt this crap code to a LMB exit.

	lea	$bfec01,a0
	lea	kb(pc),a1
.0	clr.b	(a0)
.1	move.b	(a0),d1
	ror.b	#1,d1
	not.b	d1
	bmi.b	.2
	move.b	d1,(a1)+
	bra.b	.0
.2	btst	#6,-$c00(a0)
	bne.b	.1
	rts

kb	ds.b	1000

The point is:
- clear CIASDR
- 1
- if you read a positive value in CIASDR there is a key press* (I've also optimized the code, the

beq

can be avoided )

clear CIASDR

use the keycode

- goto 1

*EDIT: as you can see from the code, positive after the

ror/not

[roondar]

Originally Posted by ross

TCH, just some generic advice from me.
You must be clear about what you want to do and the conditions in which your code must operate, in this way it is also easier to help you for those who read.
<...>
As you can see there are many way, but each one must be handled in a different way and not mixing pieces.

First of all you need to understand how the hardware works and then what the system does.
If you leave the system active know that you will have to 'fight against it', so you need to know exactly what to do

I agree with this

@TCH:
My personal stance on the issue is simple: either code with the system up and use the OS to access the hardware (i.e. do what Thomas is suggesting), or deactivate the OS and hit the hardware.

I know this might not seem like it will solve the problem in the easiest way, but mixing the OS with directly accessing the hardware is asking for problems. Your life will be much easier if you choose one and avoid the other for any given program you make.

Hope this can help you, even if it doesn't contain any code

[TCH]

@ross:
No change, same results.

		lea		CIAA+CIASDR,a1
WaitInput:	clr.b		(a1)
ReadKbd:	move.b		(a1),d0
		ror.b		#1,d0
		not.b		d0
		bmi.b		CheckMouse

; Here are the part which handles the buttons.
; If none of the relevant buttons were hit, then it branches back to WaitInput.

CheckMouse:	btst		#6,-CIASDR(a1)
		bne.b		ReadKbd

@roondar:
I think a/b's code deactivated the OS by disabling the interrupts, but the results were the same.

[ross]

You didn't follow my code carefully (you can tell from the label you used)
I also made you a 'detailed' flowchart...

		lea		CIAA+CIASDR,a1
            	clr.b		(a1)

ReadKbd:	move.b		(a1),d0
		ror.b		#1,d0
		not.b		d0
		bmi.b		CheckMouse
                clr.b		(a1)

; Here are the part which handles the selection (if any).

CheckMouse:	btst		#6,-CIASDR(a1)
		bne.b		ReadKbd

[Thomas Richter]

Originally Posted by TCH

Currently i am looking the simplest solution; i've checked

IDCMP_RAWKEY

, but as i see, for this, i need to mess around with system structs and calls.

With the advantage, that your progam interacts nicely with other programs running, and only receives events if it has the input focus.



With "hacking CIAs yourself", you cannot be sure that the keystrokes were really meant to go to your program.

[ross]

Originally Posted by Thomas Richter

With "hacking CIAs yourself", you cannot be sure that the keystrokes were really meant to go to your program.

Yep, this is immediately evident running my stupid code from command line: the underlying CLI grab also the input and echoes it.