Readin keyboard and IRQs

[LeCaravage]

Hi,

Context : Amiga 500 1.3, non OS programing.

Would like to implement a pause in my program.
But I don't understand how works these keyboard thingies.

The routine doesn't detect any press at all, I suspect it's an IRQ enable pb. But I don't know which IRQ it is precisely.
I have IRQ blitter enable only in INTENA.

moveq #0,d0
bset #6,$bfee01
move.b	$bfec01,d0
bclr #6,$bfee01
not.b	d0
ror.b	#1,d0
clr.b $bfec01
cmp.b	#$50,d0		; F1 ?
bne.b	.non			; no

Also, I have another question. if the IRQ I need to enable for keys is lower priority than the actual IRQ I use in my programm, if an higher IRQ triggered during lower priority running IRQ, does it interrupted or it waits until running IRQ is finished ? In another words, does IRQs are linear sequential or like a tree sequence ?

[a/b]

http://eab.abime.net/showthread.php?t=107718

Higher level interrupt will trigger without waiting on lower level interrupt to finish.

[LeCaravage]

Originally Posted by a/b

Higher level interrupt will trigger without waiting on lower level interrupt to finish.

Madre mia, not good news for me then ^^

http://eab.abime.net/showthread.php?t=107718


Thanks dude.
Will try to adapt it. May be I'll be back for further question or stuck.

[LeCaravage]

By the way what is the meaning exactly of :

move.w	#$4000,$09a(a6)

?

[a/b]

Disable ($4000) or enable ($c000) all interrupts via master enable bit.
http://amigadev.elowar.com/read/ADCD.../node0036.html

[ross]

MOVE to SR can be used.
No need to save the old value cause RTE puts the right value back.

But it is a little used practice because if an IRQ has a higher priority there is usually a reason
(and remember in any case, if you do it, to make a very quick routine!)

[LeCaravage]

@a/b : So you turn off irqs during keys scan. No need for a keyboard irq (or sort of) to be allowed then, good news indeed.

@ross: With MOVE to SR I make sure there's no other higher irq triggered. Did I understand well ? And right after the RTE, the higher irq is triggered. If yes, that's cool trick.

@a/b : You're routine is cool but we waste 2 scanlines, may be more because in my case I use all 6 bitplans DMA and also blitter. Any chance to split this routine at two locations in loop where we are sure to have enough time between ?

[ross]

Originally Posted by LeCaravage

@ross: With MOVE to SR I make sure there's no other higher irq triggered. Did I understand well ? And right after the RTE, the higher irq is triggered. If yes, that's cool trick.

Yes, a

MOVE #$2600,SR

prevent any IRQ <= 6 from happening (you cannot stop an IRQ7..).
And yes, right after the RTE the higher IRQs, if any, are triggered.

[LeCaravage]

Thanks pal, now I just have to make sure the code run in supervisor mode.

[ross]

Originally Posted by LeCaravage

Thanks pal, now I just have to make sure the code run in supervisor mode.

For sure it run in supervisor mode, IRQ call activate it

[a/b]

Delay can be (partially) eliminated but that heavily depends on when, how and what your code is doing, and how exact the keyboard handler has to be. E.g. if you press 3 keys at the same time, is it ok to detect a single key in each consecutive frame or do you have to detect all 3 in a single frame (meaning you have to do 3 delays in single frame)?
You could start a handshake, do some processing and then finish a handshake with an optional wait just in case you are running on a very fast cpu (e.g. if you are doing this in a vblank interrupt, start with keyboard polling and start a handshake, then at the end of the interrupt finish a handshake if needed + optional wait). Or you could use a CIA timer interrupt to finish a handshake. Or if you are polling the keyboard at exactly the same screen position every time (e.g. first thing you do in a vblank interrupt) you could use copper to optionally trigger an interrupt to finish a handshake, etc.
Also, delay has to be at least 85 microsec and I don't know how much slower it can be, if there even is a cap, so this opens more possibilities but that could be tricky because it might not work on all keyboard models. For example, start with finishing a handshake from the previous frame (after a ~20 *millisecond* delay), do some processing to give the keyboard enough time to fill in the next keycode if there is one, then poll the keyboard and if there is a new keycode start a handshake (which will be finished in the next frame).
Too many unknowns to know what would be the best fit...

[LeCaravage]

@ross : hehe, no doubt, I learn a lot there. I wonder how many cycles cpu takes to switch to supervisor and reverse at exit.

@a/b : CIA is the way to go I guess, because I use a copper lvl 1 irq for vertical sync.

Ok, the pause routine works just fine now. The pb was coming from the fact that I didn't understand how works this keys scan (still I don't to be honest). The flag is set only when the key is pressed down. I assumed it was always when key is down.. So need two flags for pause managment, one for key down and another for switch pause state on/off.

Anyway, thanks @all for help and have a nice sunday.

[ross]

Just for reference.
Some users in the past have reported to me that 85us was not enough for their keyboard.
I was using some code with precise timed delay (CIA), not by beam counter wait that's imprecise by definition.

They weren't standard keyboards from the Amiga 500 or 1200, I think they were from the Amiga 2000.
And despite 85us being the reference value in HRM, some keyboards need 200us…, so use this value if possible as a minumum.

[redblade]

Originally Posted by ross

Just for reference.
Some users in the past have reported to me that 85us was not enough for their keyboard.
I was using some code with precise timed delay (CIA), not by beam counter wait that's imprecise by definition.

They weren't standard keyboards from the Amiga 500 or 1200, I think they were from the Amiga 2000.
And despite 85us being the reference value in HRM, some keyboards need 200us…, so use this value if possible as a minumum.

Was this all Amiga 2000s or is there a difference between the German and US Amiga 2000?

[ross]

Originally Posted by redblade

Was this all Amiga 2000s or is there a difference between the German and US Amiga 2000?

Problematic ones are some (or all?) A2000 keyboards made by Cherry.
Some EU users of this forum have them, I don't know for US users.

EDIT:
ah! NetBSD kbd.c:

	/* wait 200 microseconds (for bloody Cherry keyboards..) */
	DELAY(200);			/* fudge delay a bit for some keyboards */
	ciaa.cra &= ~(1 << 6);

[NorthWay]

Originally Posted by ross

Problematic ones are some (or all?) A2000 keyboards made by Cherry.
Some EU users of this forum have them, I don't know for US users.

I have one that came with a B2000 rev 4.2(or was it 4.1?), but I'm pretty sure it works fine with 85ms. IIRC I used E-Clock syncing to busy-wait.
It does definitely not work with a whole lot of stuff that assumes instant reaction like A500 keyboards.

[ross]

Out of curiosity I checked handshake time on kickstarts (rough values because only by vertical beam position between write, but enough for an estimation).

KS1.x - 480us
KS3.x - 400us

Of course you should check the code to have the actual values and not influenced by the multitasking system or the processor speed (bare 68k used).

Surprisingly (KS3.1 code):

00FBA7B4 0039 0040 00bf ee01      OR.B #$40,$00bfee01
00FBA7BC 41ee 0114                LEA.L (A6,$0114) == $00008868,A0
00FBA7C0 2f0e                     MOVE.L A6,-(A7) [00008754]
00FBA7C2 2c6e 0108                MOVEA.L (A6,$0108) == $0000885c [000081f4],A6
00FBA7C6 4eae ffc4                JSR (A6,-$003c) == $00008718
00FBA7CA 2c5f                     MOVEA.L (A7)+ [00fba7ea],A6
00FBA7CC 7036                     MOVEQ #$36,D0     <----------
00FBA7CE d1ae 0118                ADD.L D0,(A6,$0118) == $0000886c [001e6fc7]
00FBA7D2 6404                     BCC.B #$04 == $00fba7d8 (T)
00FBA7D4 52ae 0114                ADDQ.L #$01,(A6,$0114) == $00008868 [00000000]
00FBA7D8 4e75                     RTS

This basically setup a 'delayed check' (so fortunately it is not a pointless wait) based on E clock ticks, and the value used is #$36! -> 1/709309*54=76us! (with PAL crystal, ~75 on NTSC)
Even if the OS coders intended to use a shorter handshake, the management routine is so slow that in any case even Cherry keyboards have never had functional problems just for that reason .

This mean that:
- on VERY fast processor you can have a handshake of ~76us (on KS3.x, I've not checked the code on previous versions)
- on A2000 with Cherry keyboard everything works without problems because the processor is slow

[hooverphonique]

Originally Posted by ross

This mean that:
- on VERY fast processor you can have a handshake of ~76us (on KS3.x, I've not checked the code on previous versions)
- on A2000 with Cherry keyboard everything works without problems because the processor is slow

So if you install a fast cpu (possibly with rom in fastram) in an A2000, the keyboard no longer works? I doubt it..

[ross]

Originally Posted by hooverphonique

So if you install a fast cpu (possibly with rom in fastram) in an A2000, the keyboard no longer works? I doubt it..

You missed a step: "some Cherry keyboards".

And yes, if these keyboards really exist (and only if!, I can only know from hearsay, and also from that code in NetBSD) and if you find a fast enough setup for these A2000s, then yes.
Try disassembling the KS3.1 ROM to make sure, maybe that code appeared just for me

Probably such a configuration never existed and the problem never arose.

[hooverphonique]

Originally Posted by ross

Probably such a configuration never existed and the problem never arose.

That could be the case, of course