How do I get keyboard input without interrupts.

[www.:).com]

The subject of the post basically says my question - How do I get keyboard input without using interrupts? I would like if someone could give some code to do this, and please tell me how it works. While I'm asking that i would also like to know how to do the same thing with the mouse.

Thanks.

[clive]

Hardware or Software Interrupts? You want to talk to the keyboard controller, not the BIOS?

[dedndave]

in 16-bit code, you really can't handle the keyboard without some type of interrupt
in 32-bit code, you can't use interrupts at all (well - not easily)   :P

so - my question is - why do you want to do this ?
is it because you are writing 32-bit code ?
if so, this is the wrong sub-forum   :bg

[redskull]

I/O ports 60 and 64 are the data and status bytes.  However, since key presses are asynchronous, interrupts work better.

-r

[FORTRANS]

Hi,

   You could poll the keyboard controller ports in a tight loop
and that would avoid using interrupts.  Not a very goodi idea.
As Dave says you really should use either BIOS or DOS
interrupt routines.  Or write your own interrupt handler.  As
redskull hints, polling is not going to be the best way to get
keyboard data.

Regards,

Steve

[www.:).com]

The subject of the post basically says my question - How do I get keyboard input without using interrupts? I would like if someone could give some code to do this, and please tell me how it works. While I'm asking that i would also like to know how to do the same thing with the mouse.

Thanks.

I wan't to know how to do this for protected mode programming, were i hear you can't use the interrupt to handle it, and would just like to know how.

I/O ports 60 and 64 are the data and status bytes.  However, since key presses are asynchronous, interrupts work better.

-r

Ive seen something online that did something with the number 64 that you posted. It was something like:

Code Select Expand

Keyboard:
in 64h
test -forget what was here-
-some kind of conditional jump-
;I sort of understand what is going on it just loops till a key is pressed, but why 64 as the I/O is it always this?
;If I were to put 60 in place of 64 what would i be accessing?
;Do you happen to know a tutorial for this or something that will tell me about it in detail?
This code seems to have to do with what FORTRANS was saying:

Hi,

   You could poll the keyboard controller ports in a tight loop
and that would avoid using interrupts.  Not a very goodi idea.
As Dave says you really should use either BIOS or DOS
interrupt routines.  Or write your own interrupt handler.  As
redskull hints, polling is not going to be the best way to get
keyboard data.

Regards,

Steve

in 16-bit code, you really can't handle the keyboard without some type of interrupt
in 32-bit code, you can't use interrupts at all (well - not easily)   :P

so - my question is - why do you want to do this ?
is it because you are writing 32-bit code ?
if so, this is the wrong sub-forum   :bg

Why is it harder to use interrupts for this in 32-bit code than in 16-bit code?

[dedndave]

in 32-bit code, interrupts are somewhat of a protected feature
the OS uses them, of course
and, if you write a driver, you might use them
i am still trying to figure out how to write a 32-bit driver - lol - not a simple thing
but, you can use the win32 API functions to access keyboard and mouse functions

in 16-bit code, interrupts provide the standard interface - very different from 32-bit
it would be hard to write anything but a trivial program that does not use interrupts in 16-bit

[clive]

Why is it harder to use interrupts for this in 32-bit code than in 16-bit code?

Because the BIOS sets up a workable 16-bit environment, but for 32-bit protected mode you have to do it yourself, or use a DOS extender to do the work.

[dedndave]

i think you want to write a 32-bit program

the code you saw that used IN AL,64h was probably inside an interrupt handler or service routine

[redskull]

Why is it harder to use interrupts for this in 32-bit code than in 16-bit code?

Because 32-bit programs run as user mode programs, within a 32-bit O/S, which restricts all access to peripherals.  If any program could grab onto any of the system hardware at any time, then there would be no system stability.  Programs which run under Windows have to use a modern-day equivilent of INT 21 for any system service, keyboard reading included.  Executing a "DOS" program under Windows is simply a high quality (?) emulation of all that.  If you are writing your own driver or O/S, then the rules change, but you are probably not (and certainly shouldn't) be doing that.

You don't write 32-bit programs; you write Windows programs, and the difference is not trivial.

-r

[www.:).com]

ok, but how would i do this without interrupts even if it is not the best way to to it?
-mostly because i have never had luck with setting up an interrupt, I read that you have to store an address to the interrupt in the first 0 to 1024 bytes or something.
-If you happen to have some example code or tutorials for creating interrupts it would be useful to me as well.

[dedndave]

gosh - i'd have to dig up some old code
i think you read the status port, then the data port

thing is - if you do this - you are asking the system to be hosed - lol
because, even if you are not using interrupts, BIOS still is
also - it may skip keys or something - the data from one key gets clobbered by the next
oh - and one data value means the key is pressed - another means it was released
(as i recall values below 80h are presses - they or 80h onto it to signify release)
you have to affect your own repeat
and - continually clear the buffer in the BIOS data area, unless you like beeping sounds

i still have to ask - why ????
you are taking the hard way, for sure

[dedndave]

i almost forgot !
the data values are key numbers (and may vary slightly from one keyoard to another, too)
you will need a translation table to convert key numbers into characters and control codes

[redskull]

ok, but how would i do this without interrupts even if it is not the best way to to it?

You have yet to clarify what system you are writing for, and whether it's software or hardware interrupts you are opposed to.  To summarize:

1. If you are writing a 32-bit Windows program, you can't.
2. If you are writing a true 16-bit DOS program, you use the I/O port (reading port 60 will tell you the most recent keystroke)
3. If you are writing a 16-bit program to run in a DOS Box, then option two is not gaurenteed to work, but might.
4. If you are attempting to write your own 32-bit OS, then you should already know how to do it

-r

[clive]

I'm not sure why you insist on plouging into areas you are not ready for, experience comes with time, and without a good foundation you're going to have a heck of a time making any progress.

Start by looking at the source code to a DOS Extender (like Causeway), add some of your own 32-bit code. Even without source code, something like DOS4G(W) would let you poke around with interrupts, and get some familiarity with them.

If you are not able to write a 16-bit interrupt routine, some DOS drivers, and a boot loader, then coding a 32-bit protected mode OS/Environment, and bit banging hardware probably isn't in your immediate future. Dig up some old books on PC hardware, and BIOS implementation. Dig up some old WinNT DDK sources.