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:
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
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.
Quote"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."
Quote from: jejump on April 23, 2025, 01:11:22 AM"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
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?
Quote from: jejump on April 23, 2025, 01:11:22 AMBasically, 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.
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?
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:
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.
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!!!
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!
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!! :thumbsup:
Quote from: jejump on April 24, 2025, 12:05:29 AMReading port 64h bit 0 was the answer!!
That's the "data present" bit of the 8042 (keyboard controller) status register (according to this page (https://stanislavs.org/helppc/8042.html)).
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.
Quote from: NoCforMe on April 24, 2025, 07:33:01 PMJust 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 (https://www.cs.cmu.edu/~ralf/files.html), 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
Quote from: sinsi on April 24, 2025, 07:58:58 PMRalf Brown's interrupt list (https://www.cs.cmu.edu/~ralf/files.html), 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 (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...
QuoteToday 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.
QuoteRalf 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.
Quote from: sinsi on April 24, 2025, 07:58:58 PMQuote from: NoCforMe on April 24, 2025, 07:33:01 PMJust 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 (https://www.cs.cmu.edu/~ralf/files.html), 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?
Quote from: NoCforMe on April 25, 2025, 02:50:12 AMJust give me some HTML!
How about this? (https://www.ctyme.com/rbrown.htm)
Or This? (https://www.delorie.com/djgpp/doc/rbinter/)
A quick
Google for "Ralf Brown interrupt list" yielded these and others.... :smiley:
And a Wiki page (https://handwiki.org/wiki/Ralf_Brown%27s_Interrupt_List)
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.
Quote from: NoCforMe on April 25, 2025, 04:01:02 AMNice. 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.
Quote... so quit with the net-chiding, pleeze.
Just like you had told me once before, NO. :tongue:
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. :badgrin:
As they say "I will leave that as an exercise for the reader". :biggrin:
Quote from: NoCforMe on April 25, 2025, 04:01:02 AMJust 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
OK, so next time you complain that the MS documentation is lacking and you can't find anything we'll ignore you.
Noted.
Quote from: zedd on April 25, 2025, 04:28:07 AMQuote from: NoCforMe on April 25, 2025, 04:01:02 AMNice. 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.
Well, goody gumdrops for you then.
Quote from: sinsi on April 25, 2025, 04:30:35 AMQuote from: NoCforMe on April 25, 2025, 04:01:02 AMJust 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
OK, so next time you complain that the MS documentation is lacking and you can't find anything we'll ignore you.
Noted.
So I take it that you take the time to research every topic here that you comment on, no matter how trivial it is, or how far out of your area of interest it is? Do I have that right?
If so I have to commend you on your perseverance and your commitment. You must have a lot of time on your hands.
Me, not so much. Like a lot of other hue-mons, there are some things I'm interested in enough to spend the half hour looking them up online. Other things, not so much. I don't anticipate ever having to write
in dx, [some port] ever again in my lifetime.
So please excuse the hell out of me if I don't jump up and spend the half hour for every goddamn thing that I happen to comment on. You know what? life's too fucking short.
And if that doesn't comport well with you, then go ahead and sue me. I'm tired of being net-nannied for such stupid infractions.
Quote from: NoCforMe on April 25, 2025, 05:54:22 AMSo I take it that you take the time to research every topic here that you comment on, no matter how trivial it is, or how far out of your area of interest it is?
Yes. I like to think I'm being helpful and not throwing shit against the wall to see what sticks.
Quote from: NoCforMe on April 25, 2025, 05:54:22 AMSo please excuse the hell out of me if I don't jump up and spend the half hour for every goddamn thing that I happen to comment on. You know what? life's too fucking short.
And if that doesn't comport well with you, then go ahead and sue me. I'm tired of being net-nannied for such stupid infractions.
Touched a nerve? Calm down eh?
Maybe 16-bit coding is not for you either :badgrin:
Cmon David, don't get your knickers in a twist. :rofl:
My first post here (https://masm32.com/board/index.php?msg=138678) was a helpful suggestion, not a demand nor any type of reprimand that you should have conducted a search yourself. My second post was in response to your reaction to that post.
So what are you going on about?
Quote from: sinsi on April 25, 2025, 06:12:00 AMMaybe 16-bit coding is not for you either :badgrin:
It used to be. Wrote a lot of .com programs back in the day. Device drivers and TSRs too.
I have some residual interest in it, that's all.