Article View: comp.sys.atari.st
Article #32346Re: st keyboard buffering
From: Leo de Wit
Date: Wed, 04 May 1988 10:45
Date: Wed, 04 May 1988 10:45
103 lines
4536 bytes
4536 bytes
In article <4215@dasys1.UUCP> newman@dasys1.UUCP (Ken Newman) writes:
>
>Sorry if this has whizzed by in this group before, but I would like to
>know if someone has a solution to the problem of buffering raw keyboard
>input on the ST, such as obtained by using the C routines Crawcin() or
>Bconin(). There doesn't seem to be any buffering at all with these
>routines, although I believe there is using the standard getchar (which
>is no good for my purposes). I would like perhaps a full 80-char line of
>typeahead and haven't been able to make sense of the keyboard queue
>routines in the Megamax docs. Thnx in advance.
>--
>Ken Newman
>Big Electric Cat Public UNIX
>..!cmcl2!phri!dasys1!newman
Here's how keyboard buffering is done (at least I thought so ...) :
The keyboard ACIA chip reads the keyboard and makes the characters available
at an I/O address (0xFF????). The processor, as part of the VBL routine,
reads the byte at that address (if the status, another I/O address is O.K.)
and places it in a buffer, let's call it the terminal I/O buffer.
This buffer is used by the BIOS for reading a single character and testing
availability of a character; also GEMDOS uses it to read a single character
with/without echo and to read a complete line with editing capabilities (I
think these are your Crawcin() and Bconin()). I don't quite see why you
should need direct access to the terminal I/O buffer; you can use bios
calls to check availability of a character (or use something like kb_hit())
and if there's a character, store it in your buffer. It could however be
possible that you just want to look at characters in the buffer, and not
mark them read, so here is some code (I used it to trap control C's: I can
now use stdio without control C terminating the program - a shell):
/* sh.prg */
.
.
.
#define TRUE 1
#define FALSE 0
#define CONTROLC 0x2e0003
#define CONTROLQ 0x100011
#define CONTROLS 0x1f0013
typedef struct iorec {
char *ibuf;
short ibufsize, ibufhead, ibuftail, ibuflow, ibufhigh;
} iorec;
typedef unsigned char bool;
.
.
.
iorec *iop;
.
.
.
iop = (iorec *)xbios(14,1); /* get ptr. to terminal I/O buffer structure */
.
.
.
bool test_ctrlc() /* test for control C; discard buffer if you see one */
{
int i;
for (i = iop->ibufhead; i != iop->ibuftail; ) {
i += 4;
if (i == iop->ibufsize) {
i = 0;
}
if (*(int *)(iop->ibuf + i) == CONTROLC) { /* had one */
iop->ibufhead = iop->ibuftail; /* effectively clears the buffer */
return (bool)TRUE;
}
}
return (bool)FALSE;
}
Some remarks:
a) Lattice has int == 4 bytes, short == 2 (Megamax I thought int == 2).
So you should replace the *(int *) by *(long *), and the short by int.
b) The buffer struct contains:
ibuf: start of the buffer
ibuftail: index of write position
ibufhead: index of read position
ibuflow : index of low water mark
ibufhigh: index of high water mark
Each character is stored as a (4-byte) int, the scancode in the high
word, the ASCII code in the low word. This is the same int as you get
from gemdos(7) (character in without echo). Note that old BIOS versions
used 2 bytes int to store a character (I know, I had TOS in RAM!), so
there may be portability problems (i.e. between Ataris).
c) An empty buffer is indicated by ibufhead == ibuftail.
d) The xbios call returns a pointer to the structure.
e) It would have been possible to define ibuf as (int *); the trouble is
that then the indexes have to be converted (being byte-offsets).
f) Of course, you can also use gets() or fgets(ptr,size,stdin) to read
a line or use gemdos(10) (READLINE), but that is not very raw; several
characters are interpreted and there must be a termination character
(mostly Newline).
I hope this helps and is raw enough? Have a nice byte ( %-) !
(please mail me if not).
Leo. (What you C is what you get).
Technical Details
Message-ID:
<478@philmds.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!mcvax!philmds!leoReferences:
<4215@dasys1.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!mcvax!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.sys.atari.st Subject: Re: st keyboard buffering Message-ID: <478@philmds.UUCP> Date: 4 May 88 10:45:32 GMT References: <4215@dasys1.UUCP> Reply-To: leo@philmds.UUCP (L.J.M. de Wit) Organization: Philips I&E DTS Eindhoven Lines: 103 Keywords: keyboard input Crawcin Bconin