Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[MiNT] Keyboard and other IKBD handling drivers

4 views
Skip to first unread message

Standa Opichal

unread,
Feb 12, 2003, 8:41:38 AM2/12/03
to
Hi all!

I've crawled through the FreeMiNT 1.16 sources. Do it really use the ROM
TOS Bconin() (and related functions) to get the keyboard status? I've
found some obsolete /dev/mouse sources too.

What it that status of IKBD intercepting in FreeMiNT? What about
/dev/keyboard, /dev/mouse and /dev/joystick?

Correct me if I'm wrong: All the device /dev/console and others is done
via the bios_tdevice (bconout()/bconin() functions). If we create a new
/dev/keyboard for the keyboard than e.g. the /dev/console can be rewritten
to use it.

best regards

STan

PS: Please read the enclosed conversation with Henk about what he would
have like to have for XaAES. IMHO this would be a great thing for more
than only for the XaAES. Many applications uses the NKCC and my idea was
to write the /dev/nkcc or something similar.

Or... is there any better way to reach this?


---------- Forwarded message ----------
Date: Fri, 17 Jan 2003 23:46:10 +0100
From: Henk Robbers <h.ro...@chello.nl>
To: Standa Opichal <opic...@seznam.cz>
Subject: Re: Optional keyboard driver for XaAES
Resent-Date: Fri, 17 Jan 2003 23:51:58 +0100 (CET)
Resent-From: Opic...@seznam.cz
Resent-To: st...@idoox.com

Standa Opichal wrote:
>
>
> Good. I just thought that it would be really good to have this in the
> system directly so that other applications might use this as well. So if I
> have some time I'll try to implement such a device (no promisses - I just
> think that it would be really worth it).

It is especially nice because it would be a real 'raw' console. Make sure you dont
do any interpretation (^C (SIGQUIT) and other disasters).

I suppose you must intercept the IKBD completely. (well, I think you must)
There is no danger; Even when XaAES crashes, MiNT will close the device cleanly.

>
> > Currently, to be able to supply the AES code at all, I must fselect on dev/console
> > and then issue Bconin in stead of fread. This works, but doesnt make me feel comfortable.
>
> Ehm, and what would be the workflow when you have the /dev/nkcc
>

If I fread() from device/console, I just get 1 ascii character.
Bconin() returns the keyboard status + the scancode + the ascii code in a long.
With a small rearrangement this is just what the AES needs.


snippet from XaAES

typedef union
{
long bcon; /* returned by Bconin */
struct
{
unsigned char
state, /* Ensure conterm bit 3 is set, so we get the keyboard status in here. */
scan, /* scancode */
dum,
code; /* ascii (if applicable */
}conin;
} CONKEY;

typedef struct rawkey
{
CONKEY raw;
G_u aes, /* AES keycode */
norm; /* mormalized keycode */
} KEY;

/* snippet from xaaes kernel.c */

.......
input_channels |= 1L << C.KBD_dev; /* We are waiting on all these channels */
........
Fselect(timeout,
(long *)&input_channels,
0L,
0L
);
..........
if (input_channels & (1L << C.KBD_dev))
{ /* Did we get some keyboard input? */
KEY key;
key.raw.bcon = Bconin(2); /* Crawcin(); */
key.aes = (key.raw.conin.scan<<8) | key.raw.conin.code; /* Translate the BIOS raw data into AES format */
key.norm = 0; /* filled out by nkc_tconv when needed */

..........
}

What I would very much like to do in stead of Bconin:

Fread(C.KBD_dev, sizeof(KEY), &key);

if C.KBD_dev is dev/nkcc


and nothing more, so the device supplies key.norm.

--
Groeten; Regards.
Henk Robbers. mailto:h.ro...@chello.nl
http://members.ams.chello.nl/h.robbers/Home.html
A free multitasking GEM for MiNT: XaAES (heavily under construction);
http://xaaes.atari.org
Interactive disassembler: TT-Digger; http://digger.atari.org
A Home Cooked teXt editor: AHCX
The free desktop: TERADESK


0 new messages