DOS ain't dead

myrkraverk 18.10.2019, 00:57	Getting the raw state of the keyboard with CauseWay? (Developers) Post reply
	Ok, so I've been playing with the CauseWay extender for a bit, and I'm trying to read the keyboard. So far I've just been using OpenWatcom's conio.h. However, I cannot seem to get key events for things like control+space in DOSBox-X. Is there a way for me to get access to the raw keyboard? And if so, can I use that trick with CauseWay extended programs?

myrkraverk

18.10.2019, 01:26

@ myrkraverk

Getting the raw state of the keyboard with CauseWay?

Post reply

> Ok, so I've been playing with the CauseWay extender for a bit, and I'm
> trying to read the keyboard. So far I've just been using OpenWatcom's
> conio.h. However, I cannot seem to get key events for things like
> control+space in DOSBox-X.
>
> Is there a way for me to get access to the raw keyboard? And if so, can I
> use that trick with CauseWay extended programs?

There are helpful answers on Stack Overflow but they're not protected mode.

I've read the CauseWay manual, and I know that interrupt handlers must be in locked memory. I also know how to do this from the mouse interrupt 33/C example in the Programmer's Guide.

Do interrupt handlers need to be compiled as 16bit rather than 32bit code?

Is this just as easy as compiling and installing said interrupt handlers from the SO answers with CauseWay?

myrkraverk 18.10.2019, 19:35 @ myrkraverk	Getting the raw state of the keyboard with CauseWay? Post reply
	A friendly soul on usenet guided me to the _bios_keybrd() function which I've used to get scan codes and shift states. I have no immediate need to write my own keyboard handler with CauseWay, though I'll admit I'm still a bit curious how to do it.

myrkraverk 21.10.2019, 12:48 @ myrkraverk	Getting the raw state of the keyboard with CauseWay? Post reply
	I made a first move in writing my own keyboard driver. Posted on usenet. I cannot recommend anyone trying it out on real hardware; not until I understand exactly what the inp() and outp() routines are doing. It also beeps for a long time on first use in DOSBox-X, and I think that's something to do with my code rather than DOSBox-X. If anyone here has some comments on the code, please share.

Japheth

Germany (South),
21.10.2019, 14:58

@ myrkraverk

Getting the raw state of the keyboard with CauseWay?

Post reply

> If anyone here has some comments on the code, please share.

The STI opcode isn't really necessary, since interrupts should already be disabled when the routine is called.

Readinf/Writing port 0x61 is most likely a requirement for PC/XT machines only, to send an "acknowledge" (ACK) to the keyboard controller that the request has been handled. On AT and newer machines, reading port 0x60 is sufficient for this.

Writing 0x20 to port 0x20 sends ACK to the PIC.

---
MS-DOS forever!

myrkraverk

23.10.2019, 01:16

@ Japheth

Getting the raw state of the keyboard with CauseWay?

Post reply

> > If anyone here has some comments on the code, please share.
>
> The STI opcode isn't really necessary, since interrupts should already be
> disabled when the routine is called.
>
> Readinf/Writing port 0x61 is most likely a requirement for PC/XT machines
> only, to send an "acknowledge" (ACK) to the keyboard controller that the
> request has been handled. On AT and newer machines, reading port 0x60 is
> sufficient for this.
>
> Writing 0x20 to port 0x20 sends ACK to the PIC.

Thank you. I've gotten similar (and more detailed) replies on usenet as well.

Getting the raw state of the keyboard with CauseWay? (Developers)

Getting the raw state of the keyboard with CauseWay?

Getting the raw state of the keyboard with CauseWay?

Getting the raw state of the keyboard with CauseWay?

Getting the raw state of the keyboard with CauseWay?

Getting the raw state of the keyboard with CauseWay?