Keyboard wait, register reset?

[TCH]

@ross:
I did follow the flowchart. There was a

bra .0

in your code which was at the end of the part where the keystroke was handled which branched back to before the

move.b (a1),d0

part, where the clear was. I've changed the code, but the result is the same: one read and after that nothing. Full code:

		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)

TCheckF2:	cmp.b		#BtnF2,d0				; Check if F2.
		bne		TCheckF3				; Nope, skip.
		eor.b		#1,THitPower				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF3:	cmp.b		#BtnF3,d0				; Check if F3.
		bne		TCheckF4				; Nope, skip.
		eor.b		#1,THealth				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF4:	cmp.b		#BtnF4,d0				; Check if F4.
		bne		TCheckF5				; Nope, skip.
		eor.b		#1,TTime				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF5:	cmp.b		#BtnF5,d0				; Check if F5.
		bne		CheckMouse				; Nope, skip.
		eor.b		#1,TLaserShots				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

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

Isin't this way the clearing redundant? And the CLI did not pick up any keys.

@Thomas Richter:
After the program, a single-task game will start and will throw out the OS anyway. I just would like to check the state of a few keys and the mouse button. (The latter one works.)

[ross]

Originally Posted by TCH

Isin't this way the clearing redundant?

It depends, with such a simple code in fact it is. [EDIT: not in the last snippet you posted, ReadKbd in this position make it mandatory]
But in the 'flowchart' I made a

clr

immediately to avoid the possible loss of a subsequent quick key press.

Suppose you have a keypress, your code takes a long time to execute and in the meantime there is a subsequent keypress (or more than a key pressed at once, the Amiga keyboard buffer it).
If you

clr

it at the end of the cycle you have lost the keypress.

In any case this would only alleviate a little the problem, it seems to me that the keyboard buffers 10 keys or something like that.
But simple cases would still be handled, like shift-keys.

Well, it remains a lousy method...
It is sometimes used in intros or for really unimportant things.
AVOID IT, please.

I don't seem to have ever used it.

And the CLI did not pick up any keys.

It works for me.

I have no idea why it doesn't work for you, do a post with the executable attached.

[a/b]

No, it's not redundant, it tells you that there is no new keycode.
You could also ditch the stateless approach and always remember the last code you read, and if it's the same then it means nothing was pressed. Something like (high-level):

byte code, last_code = 0;
...
while ((code = *0xbfec01) != last_code) {
  last_code = code;
  // process code
  ...
}

[ross]

What this executable does for you?:

	lea	$bfec01,a0
	lea	-256(sp),sp
	lea	(sp),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
	move.l	(sp),d0
	lea	256(sp),sp
	rts

If I press in sequence 1,2,3,4,ENTER, then LMB, I get "exe failed return code 16909060", as expected.

[TCH]

@ross: This is an unimportant thing, a simple menu. I give the binary via link, the attachment button does not working in my browser. Edit: The attachments popped up in a separate tab...
http://oscomp.hu/depot/8ac345dc

Edit: Yes, your binary does that for me too.

Edit: The drawing code might be slow, but it appears instantly, what makes it impossible for me to hit a key during drawing.

@a/b: But i cannot read new keycodes, so there is nothing to store, after the first.

[ross]

Originally Posted by TCH

@ross: This is an unimportant thing, a simple menu. I give the binary via link, the attachment button does not working in my browser. Edit: The attachments popped up in a separate tab...
http://oscomp.hu/depot/8ac345dc

Edit: Yes, your binary does that for me too.

Edit: The drawing code might be slow, but it appears instantly, what makes it impossible for me to hit a key during drawing.

@a/b: But i cannot read new keycodes, so there is nothing to store, after the first.

You are using _LVODisable()!

There is no system handshake, and the keyboard does not send other codes, simple.

[TCH]

That was needed for opening the custom screen. During keyboard reading i should use

Enable()

?

[ross]

Originally Posted by TCH

That was needed for opening the custom screen. During keyboard reading i should use

Enable()

?

Why is it necessary to open the screen? Do you have to turn off IRQs for some reason?
Use _LVOForbid() instead, it only disable task scheduling.

[a/b]

"Cannot"...
If you are doing the handshaking yourself then you must ensure that nothing is interfering (eg. OS must be shut down), otherwise you could end up not being able to read them (properly).
If you are not doing the handshaking and relying on OS to do it for you, then you have to know whether the code you just read is the old code (that you have read already) or not. One way is to clear the HW register and the other way is to compare it to the previous code you've read. Clearing is simpler/stateless, but since you said that doesn't work either (pretty much every code posted before an hour or so ago), then this should really work as it does not interfere with the protocol in any way (doesn't write anything to HW).
But if you have managed to get the clr version working, that's ok then.

[TCH]

@ross:
I have no idea why it is necessary if it is, you've suggested it's usage too.

@a/b:
It seems the

Disable()

was preventing both your and ross' code from working.

[ross]

Originally Posted by TCH

@ross:
I have no idea why it is necessary if it is, you've suggested it's usage too.

You have to contextualize ..
The link point to some generic code (which does nothing!) that take control of the system, in anticipation of the free modification of the IRQs and hardware registers.
In this case you don't have to take control of the machine, let alone change the IRQs.

[ross]

Originally Posted by TCH

@a/b:
It seems the

Disable()

was preventing both your and ross' code from working.

http://amigadev.elowar.com/read/ADCD.../node0203.html

Urge that you read some docs

EDIT: Sorry for the back-to-back post, this text was not in the original post.

[TCH]

I've seen a custom screen opening code and used it.

Disable()

was supposed to do something with the copperlist, or i don't know. In the other topic, no one questioned it's usage.

Edit: But, that was what you and a/b suggested until this point, to disable the interrupts. Now what then?

Edit 2: Okay, i've put the

Enable()

after the DMA and the copper is set, and another

Disable()

before they are restored and now the code works. Thanks guys.

Edit 3: No, i was wrong. It works until the system tries to exit. After LMB everything freezes.

[ross]

Originally Posted by TCH

I've seen a custom screen opening code and used it.

You don't have to take some random code and apply it just in case

[TCH]

Currently it become quite stochastic. The following cases are observed:

- Neither the keyboard, neither LMB works from the start.
- The keyboard works, but when LMB is clicked it freezes.
- If LMB is clicked without the keys hit, it works.
- Both works.

All this randomly.

Edit: I've removed all

Enable()

and

Disable()

and now it works. No, it's not, it's just worked for ten times a row... /o\

[TCH]

Code for initialization:

		lea		CUSTOM,a2

		move.l		$4,a6					; Old copper backuped in a3.
		lea		graphics_lib(pc),a1
		jsr		OldOpenLibrary(a6)
		move.l		d0,a1
		move.l		38(a1),a3
		jsr		CloseLibrary(a6)

		jsr		Disable(a6)
		lea		copperlist(pc),a1
		move.l		a1,COP1LCH(a2)

		move.w		#SETCLR,d3				; DMA backuped in a4.
		or.w		DMACONR(a2),d3
		move.w		d3,a4
		move.w		#$7fff,DMACON(a2)
		move.w		#SETCLR|DMA_ENABLED,DMACON(a2)
		jsr		Enable(a6)

The code for the keyboard/mouse handling:

		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)

TCheckF2:	cmp.b		#BtnF2,d0				; Check if F2.
		bne		TCheckF3				; Nope, skip.
		eor.b		#1,THitPower				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF3:	cmp.b		#BtnF3,d0				; Check if F3.
		bne		TCheckF4				; Nope, skip.
		eor.b		#1,THealth				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF4:	cmp.b		#BtnF4,d0				; Check if F4.
		bne		TCheckF5				; Nope, skip.
		eor.b		#1,TTime				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

TCheckF5:	cmp.b		#BtnF5,d0				; Check if F5.
		bne		CheckMouse				; Nope, skip.
		eor.b		#1,TLaserShots				; Yep, toggle.
		bra		PrintStatuses				; Break from keyboard handling.

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

The exit code:

Exit:		jsr		Disable(a6)
		move.w		#$7fff,DMACON(a2)
		move.l		a3,COP1LCH(a2)				; Restore old Copper settings.
		move.w		a4,DMACON(a2)				; Restore old DMA flags.
		jsr		Enable(a6)

		moveq		#0,d0					; Exit.
		rts

Any ideas?

[TCH]

Okay, this time i got it, by removing the first

Enable()

and the second

Disable()

and replacing the remaining ones with

Forbid()

and

Permit()

the code now finally works. (ross, you were right on this.)

Thx again guys.

[hooverphonique]

Originally Posted by 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.

Originally Posted by TCH

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

You misunderstood what a/b was saying - you need to disable interrupts permanently (i.e. not periodically while reading the keyboard) for his example to work. Please read what people are suggesting carefully - only using half their advice when you don't understand what's going on will often not get you anywhere

[phx]

Indeed, the code shown is calling for trouble.
Never access the hardware directly when the OS is still alive! And the OS is alive, when the AmigaOS interrupts are handled. Also don't play with DMA channels and copper lists in that state.

[TCH]

Interesting, because now i did not disable the interrupts at all and yet, the keyboard reading works.

I called

Forbid()

(formerly

Disable()

) before setting the DMA channel and the copperlist, is that okay that way?