Problem With Reading Keyboard Port 60h

[jejump]

Hey folks,

I'm assembling a small TSR for DOS (MS-DOS is v6.22) and my TSR code works flawlessly ONLY IF I assemble my source (MASM 6.11) and then install by typing the name of the .com file.  If I simply boot (warm or cold), skip the assembly process, and just install the .com as it was last assembled, the code works up to the point where I check the keyboard port.  It's like the keyboard reading code isn't being observed properly.  Here's some of the pertinent code in question:

Code Select Expand

CA_Wait:                   ; Wait Loop
call    KBS_Service
test    BYTE PTR CS:[New_08 + 4], 1
jnz     Return
mov     DX, 379h
in      AL, DX
and     AL, 60h
jz      CA_Wait    ; Loop


KBS_Service:
pushf
push    AX
push    DX
push    ES
in      AL, 20h
test    AL, 2
jz      KBS_End
in      AL, 60h
cmp     AL, 1
jne     Esc_Key_No
or      BYTE PTR CS:[New_08 + 4], 1
Esc_Key_No:
mov     AX,0040h
mov     ES, AX
mov     AL, ES:[001Ch]
mov     ES:[001Ah], AL
mov     AL,20h                  ;Clear interrupt controller
out     20h,AL
out     0Ah,AL
and     ES:[0017h], 0F0h
KBS_End:
pop     ES
pop     DX
pop     AX
popf
ret


Basically, the wait loop is waiting on either signals from the parallel port, or the Esc key from the keyboard to exit the loop.  Just before this wait loop is entered, the keyboard interrupt mask is applied on port 21h, bit 1, so that no keyboard interrupt is processed.  It gets re-enabled later on.  Like I said, this works great as long as I assemble just before installing--as if the assembler running is somehow creating a more cohesive/conducive environment for this code.  Anyone have thoughts on this behavior?  Hopefully I've made it clear what's going on.  Thanks for the help!


John

[NoCforMe]

I'd say, as a first guess, that this has nothing at all to do with the assembler, and everything to do with the state of the keyboard port (or the interrupt controller) when you're reading them.

Not sure what exactly you're doing by reading the interrupt controller (port 20h) before looking for a keystroke: what's the logic here? Are you first looking for a pending interrupt, as if a key had been pressed? That might be the problem, or at least part of it.

[jejump]

"Not sure what exactly you're doing by reading the interrupt controller (port 20h) before looking for a keystroke: what's the logic here? Are you first looking for a pending interrupt, as if a key had been pressed? That might be the problem, or at least part of it."

"Just before this wait loop is entered, the keyboard interrupt mask is applied on port 21h, bit 1, so that no keyboard interrupt is processed.  It gets re-enabled later on."
 

So, unless I don't understand something about disabling keyboard interrupts, I assume given the above statement, the only way to know if a character is waiting is to poll the interrupt line (port 20h bit 1) since no interrupt is being processed for the keyboard.  I stole this code and method from a different project of mine where disabling the keyboard from interrupt processing was more necessary than it is with this recent project.  I could possibly allow interrupt processing for the keyboard and all will be well.  That might be how I fix it.  I'm just curious at this point, why this doesn't work regardless of whether I run the assembler just before or whenever before.

Thanks for the response.
Jj

[sinsi]

If you are polling the keyboard you shouldn't send EOI, this should only be sent by an ISR.
What's wrong with using INT 16h, AH=11h?

[_japheth]

Basically, the wait loop is waiting on either signals from the parallel port, or the Esc key from the keyboard to exit the loop.  Just before this wait loop is entered, the keyboard interrupt mask is applied on port 21h, bit 1, so that no keyboard interrupt is processed.

That's good and needed for polling.

Code Select Expand

KBS_Service:
    pushf
    push    AX
    push    DX
    push    ES
    in      AL, 20h
    test    AL, 2
    jz      KBS_End

As NoCForMe already pointed out, what's expected by reading port 20h here?

Code Select Expand

    in      AL, 60h
    cmp     AL, 1

If kbd is polled, one should not unconditionally read port 60h, but first check if a byte is actually ready to be read:

Code Select Expand

    in al, 64h
    test al, 01h        ; input buffer full?
    jz nokey
    mov ah, al
    in al, 60h
    test ah, 20h        ; is it input from PS/2 mouse?
    jnz nokeyps2

And input from PS/2 mice may also appear at port 60h, so better filter that as well.

Code Select Expand

    mov    AL,20h                  ;Clear interrupt controller
    out    20h,AL
    out    0Ah,AL

Already mentioned by sinsi: don't sent EOI to PIC if kbd is polled. And writing to port 0Ah - that's the ISA DMA controller!!!

[jejump]

Excellent information here!  I'm going to change the method of how I detect a key press to reading port 64h.  I wondered about the mouse hardware maybe causing conflict even though I don't have a mouse driver loaded.  Thanks for the tips!

[jejump]

Reading port 64h bit 0 was the answer!!  I guess I misled myself originally to believe I had to poll port 20h bit 1 because there was no interrupt connectivity after applying the mask and that would be my only way of detecting keyboard activity.  Turns out I don't need to do that.  I also eliminated the EOI on the interrupt and DMA hardware.

Thanks for helping!!   

[NoCforMe]

Reading port 64h bit 0 was the answer!!

That's the "data present" bit of the 8042 (keyboard controller) status register (according to this page).

Just curious: how did you come to figure this out? Do you have some IBM PC low-level manuals? This isn't anything like common knowledge.

[sinsi]

Just curious: how did you come to figure this out? Do you have some IBM PC low-level manuals? This isn't anything like common knowledge.

Ralf Brown's interrupt list, which includes a file called ports.txt
Ralf and Peter Norton were the only sources of free detailed info about the IBM BIOS and early MS-DOS

[_japheth]

Ralf Brown's interrupt list, which includes a file called ports.txt

Yes, but osdev is also a good source, if it's hardware-related: https://wiki.osdev.org/%228042%22_PS/2_Controller

One can also peek in the virtualizer's source code (i.e. qemu ), but I'm not too convinced that those are of high quality...

[jejump]

Today at 07:58:58 PM
Quote from: NoCforMe on Today at 07:33:01 PM
Just curious: how did you come to figure this out? Do you have some IBM PC low-level manuals? This isn't anything like common knowledge.

Ralf Brown's interrupt list, which includes a file called ports.txt
Ralf and Peter Norton were the only sources of free detailed info about the IBM BIOS and early MS-DOS

Ralf Brown is probably how I learned what I know.  I start with a Google search of some terms, but eventually came to the Ralf Brown site.

[NoCforMe]

Just curious: how did you come to figure this out? Do you have some IBM PC low-level manuals? This isn't anything like common knowledge.

Ralf Brown's interrupt list, which includes a file called ports.txt

Ugh. Everything's in .zip files. Just give me some HTML!
And where is ports.txt on that page?

[zedd]

Just give me some HTML!

How about this?
Or This?

A quick Google for "Ralf Brown interrupt list" yielded these and others....

And a Wiki page

[NoCforMe]

Nice. Good resource.
Realize that I'm just a bystander making comments from the peanut gallery.
Just because I complain about something doesn't mean I give enough of a shit to do an online search, so quit with the net-chiding, pleeze.

[zedd]

Nice. Good resource.
Realize that I'm just a bystander making comments from the peanut gallery.

Um, me too. But also I am being helpful (I think) while bystandering.

... so quit with the net-chiding, pleeze.

Just like you had told me once before, NO. 

Now I will further add, that doing a forum search for "Ralf Brown" will also yield some results. As will searching the old U.K. Forum...

Those forum searches might only reference Ralf Brown or his Interrupt List and not contain any part of that list.

As I am a bystander I didn't take extra time to explore those search results further. 

As they say "I will leave that as an exercise for the reader".