Polling IKBD with its IRQ disabled

[simonsunnyboy]

Hey,

I have a handpolling keyboard routine here (the IRQ is disabled for raster stabilization) which works for keypresses.
But when I move the mouse some packets seem to get throught being interpreted as keypresses.
I tried disabling mosue reporting by sending the $12 command to the IKBD but it doesn't work.

My GFA code for the keyboard scanner looks like this:

Code: Select all

FUNCTION read_keyboard(debounce!)
  LOCAL rkbd|,key|
  rkbd|=PEEK(&HFFFFFC02)                ! read IKBD
  IF rkbd|<128                          ! key pressed?
    IF debounce!
      ' debounce if wanted
      WHILE PEEK(&HFFFFFC02)<128
      WEND
    ENDIF
    key|=BYTE(rkbd| AND 127)            ! get key value
    '    IF key|<>old_key|
    '    old_key|=key|
    RETURN key|
    ' ELSE
    '   RETURN 0
    ' ENDIF
  ELSE
    RETURN 0
  ENDIF
ENDFUNC

Any ideas?

cheers,
ssb

[lp]

Did you do something like OUT 4,$12 ?

According to the IKBD docs any valid mouse command resumes mouse monitoring. Is it possible some other program in the system has caused it to resume monitoring? I guess if you are sure your program is the only one running, this is not the case. Just an idea.

[simonsunnyboy]

Did you do something like OUT 4,$12 ?

According to the IKBD docs any valid mouse command resumes mouse monitoring. Is it possible some other program in the system has caused it to resume monitoring? I guess if you are sure your program is the only one running, this is not the case. Just an idea.

OUT 4,18 was exactly what I tried

[Klapauzius]

Just filter the mouse paket bytes?
Check for $f8 to $fb (relative mouse paket header) and discard the following two paket bytes...

[simonsunnyboy]

I tried to do exactly that but somehow the routine never detected any of those
While we at this...is there some sort of handshake? When do I know that there is the next byte of an IKBD packet waiting?

[Klapauzius]

When do I know that there is the next byte of an IKBD packet waiting?

Afaik, an ikbd packet can't be suspended by other bytes. So if you're detecting a header byte, you can be sure that the following bytes will be packet bytes (how many depends on packet length).
If you got a reasonable polling interval (retaining some time of waiting between your polls), you should see the complete packet.

[simonsunnyboy]

Seems I have to create a nice FSM in m68k then and hook it into the VBL...with the bruteforce GFA code my timing is *ehem* not really predictable

[lp]

Don't know if this will help, but you can check for waiting bytes on a device. See INP?() in the gfa manual.
do while inp?(4)=false
loop

[simonsunnyboy]

Don't know if this will help, but you can check for waiting bytes on a device. See INP?() in the gfa manual.
do while inp?(4)=false
loop

I fear it won't work if the IKBD service routine from TOS is disabled. And I do not want to enable it...as I disabled it to stabilize my rasters
I will try tommorow and experiment a bit...

[Nyh]

Did you do something like OUT 4,$12 ?

According to the IKBD docs any valid mouse command resumes mouse monitoring. Is it possible some other program in the system has caused it to resume monitoring? I guess if you are sure your program is the only one running, this is not the case. Just an idea.

OUT 4,18 was exactly what I tried

Did you wait long enough? In all my Omikron basic demo's (with very stable rasters) I started with something like:

Code: Select all

 'Muis Uitzetten
 BIOS (,3,4,$12)
 FOR I%L=0 TO 9
   WVBL
 NEXT I%L

Sending the disable mouse command and then (almost) immediately disabling the interrupts doesn't work.

Hans Wessels

Hans Wessels

[simonsunnyboy]

Did you do something like OUT 4,$12 ?

According to the IKBD docs any valid mouse command resumes mouse monitoring. Is it possible some other program in the system has caused it to resume monitoring? I guess if you are sure your program is the only one running, this is not the case. Just an idea.

OUT 4,18 was exactly what I tried

Did you wait long enough? In all my Omikron basic demo's (with very stable rasters) I started with something like:

Code: Select all

 'Muis Uitzetten
 BIOS (,3,4,$12)
 FOR I%L=0 TO 9
   WVBL
 NEXT I%L

Sending the disable mouse command and then (almost) immediately disabling the interrupts doesn't work.
Hans Wessels

Thanks for that tip - I will certainly try to let my code wait directly after the mouse disable command.

[charles]

try this ,
i got lost as soon as i read this ,
what do you mean??

(the IRQ is disabled for raster stabilization)

which irq do i disable for raster stablization??

which works for keypresses.
did you disabled the ikbd keypolling?

jenabint and jdisint ???
is this the condition it falls under?? ,

if you disabled the ikbd polling
maybe thats the problem right there but in any case try this too see if works.

Code: Select all

'
exit|=57
' ******************************************
HIDEM
'
REPEAT
  IF LEN(INKEY$)>0
    scan_byte|=FN read_keyboard(TRUE)
    PRINT AT(3,10);USING "###",scan_byte|
  ENDIF
UNTIL scan_byte|=exit|
'
SHOWM
'
~APPL_EXIT()
'
' *******************************************
'
FUNCTION read_keyboard(debounce!)
  LOCAL key|
  IF debounce!
    key|=BYTE(PEEK(&HFFFFFC02) AND 127)                ! read IKBD
    RETURN key|
  ELSE
    RETURN 0
  ENDIF
ENDFUNC
'
'

[charles]

i see what you now mean , my example only reads $ffffc02,
i whent back and tryed while moving the mouse.
yep $fffffc02 is no good ,
where did you get this address from?
its not the same address as iorec() for the keyboard handler buffer.

so you are attempting to read incoming data from the keyboard ,
while drawing to screen,
results from using the mouse ?

is this correct?
charles

[simonsunnyboy]

The idea is not to use the TOS at all. iorec or somethign is certainly a data structure in use by TOS.
I disable all interrupts used to poll the keyboard for TOS.

$fffffc02 is the hardwareregister to access the IKBD. It is listed in every ST hardware manual.

[charles]

simon i own every hardware manual,
i really don't have any further suggestions because tos is the whole computer system.
and to not use the tos at all means non-tos compliant.

any command you use is used by the tos ,
my real other attempt would be place the mouse disable within the fn-read keyboard.
diable before checking the hardware register enable directily after.

i think the tos sets up the interupts to execute in a specific order, you may have to jump this order to avoid the mouse being encountered first ..but i am a novice ...

was i right about you
drawing to screen ,
with the mouse
while using the keyboard?

to bad you have no tos problem,

evnt_multi is good for this area of events too!!!
there is bios aswell
but these are all tos ,
i do not know at the moment ,
please give a more exact senerio because
i would kinda like to help.
computers move very quickily , reaCTION TIME =0

charles

[lp]

Charlie, please reread the first post, read it several times... v e r y ... s l o w l y. He clearly states the mouse is interfering with the keyboard polling. He wants to disable the mouse entirely.

[charles]

well thats what is happening ,
is it appears you're program is
missing a control from the
status register to go ahead and read the data register.



i know just a little above your $fffffc02 is
the $fffffc04 my midi status control register
and
at $fffffc06 is midi in/out data register

so with this applied maybe $ffffff00 is the keyboard control register?
i'm going to try then get right back.


but when as for midi ,
which might be similar ,

within the structure there is an additional condition we wait for
and it falls under this condition..

if something to read or send in the address
we have to wait until the status of the control register changes allowing us to read it.
(like if inp?(1) =true)

i have to wait for the stat buffer to clear
or what my example states:

we wait until bit 2 of the status register is clear ............



but who knows maybe only applies to writing to the ports and not reading them.

its like a vsync
but we wait for next cycle of polling to begin
after the correct time to read the installed data register vector .



but its all theroretical at the moment , i will try then report right back

these things have control registers right?
we can interupt them setting them to any polling area we want right?

charles

[charles]

nope , i'm wrong , any body got the answer yet?
so the mouse needs diabling or removed from the tos, one of the two.

charles
i think all areas will be checked , it just on the level peeking you do,

i will now try to disable my mouse.

any suggestions as what will happen when i can't disable my mouse?


charles

[charles]

ok last stupid bunch of ideal .
what is the ipl ?
do we use it in gfa ?

charles

why is xbios(13) not used in gfa?
mfpint?

[lp]

charlie wrote:
ok last stupid bunch of ideal .

Agreed.

what is the ipl ?

No idea.

do we use it in gfa ?

If you have to ask, erm no.

why is xbios(13) not used in gfa?
mfpint?

That is for installing a user definable interrupt. It's up to you to sort out it's use, not GFA. It's a system call available to all programming languages which have access to the Xbios().

[simonsunnyboy]

*CENSORED*

It seems I have to add some flag waiting code on bit #0 in $FFFFFC00.

[charles]

simon ,

this is what i said before in one of my posts.
use might need control through control register.

the midi adress is bi-directional
is this keyboard address bidirectional as-well??

why do they antagonize me .

anyhow i'm surprised no one else is trying to help.
i tryed most of yesterday but to busy with pascal.

charles

[simonsunnyboy]

simon ,

this is what i said before in one of my posts.
use might need control through control register.

Yes, after careful reading again your post, I agree to find that buried. I just had to dig into some books to finally find the piece of information needed.

the midi adress is bi-directional
is this keyboard address bidirectional as-well??

No they are not. Read accesses go to different internal registers than write accesses.
Write access to $FFFFFC02 will send data which will end up in a reciever register while reading the same address gives you the contents of a different register inside of the keyboard controller.
But the generic behaviour is similar for MIDI and the keyboard itself.

[Nyh]

It seems I have to add some flag waiting code on bit #0 in $FFFFFC00.

This flag tells you new data is available at $FFFC02. If your mouse is disabled you can just read $FFFC02 as a keyboard scancode. If mouse (or joystick) is enabled this is not true because you can have multi byte mouse and joystick packets.

@Charles:
simonsunnyboy is bypassing all TOS routines for reading the keyboard and has disabled the MFP interrupt handling a keyboard packet coming from the ACIA. You never know when those interrupts arrive and those interrupts destroy your rasters. Because there are no interrupts you will have to look at the ACIA data register yourself. This technique is called polling. Normally you read the ACIA data one time per vertical blank. If you don't care to miss some key presses this is a very good technique. Most demo screens use it.

Normally they are only interested to see whether the space bar was pressed and some the cursor keys. It is not a big deal to miss a incoming byte. But all mouse and joystick data is coming in multi byte packets. If you miss the header byte of such a multi byte packet you don't know that the data you are reading belongs to a mouse packet and if you try to use it as normal keyboard scan codes you get unwanted results.

i know just a little above your $fffffc02 is
the $fffffc04 my midi status control register
and
at $fffffc06 is midi in/out data register

so with this applied maybe $ffffff00 is the keyboard control register?

Yes, FFFC00 and FFFC02 for keyboard are working the same way as FFFC04 and FFFC06 for MIDI as they are both ACIA registers.

what is the ipl ?

IPL stand for Interrupt Priority Level. Normally an ST runs at IPL 4, the HBL interrupts are blocked.
At IPL 6 the VBL interrupts are blocked.
At IPL 7 all interrupts are blocked.

the midi adress is bi-directional
is this keyboard address bidirectional as-well??

Yes it is. To disable the mouse you sent data to the keyboard.

anyhow i'm surprised no one else is trying to help.

??? On February 12 simonsunnyboy asked the question. On February 14 he got some useful suggestions. The a long time nothing happened (it is safe to assume the problem is solved or simonsunnyboy is busy testing solutions). On the 1st of March you started to ask a lot of questions clearly showing you didn't have a clue what simonsunnyboy was doing and what problems he faced. Why are you stating no one is helping simonsunnyboy?

Polling $FFFC02 for reading the keyboard works fine. Most demos work this way. But you have to disable the mouse. Sending $12 to the keyboard should work fine. The big question is why it doesn't work as expected for simonsunnyboy.

Hans Wessels

[simonsunnyboy]

Actually i'm busy with real life at this time...getting a job to be precise.

@Nyh: Cheers for your clean explanation. You have exactly stated my problem.

If all fails I'll have to add a FSM to filter mouse packets out....
Let's see when I find the time to try out.