Path: utzoo!mnetor!uunet!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: st keyboard buffering Message-ID: <1054@atari.UUCP> Date: 6 May 88 19:14:19 GMT References: <478@philmds.UUCP> Organization: Atari Corp., Sunnyvale CA Lines: 33 Leo@philmds's description of keyboard input on the ST is imaginitive, but totally off the wall. The ST has INTERRUPT-DRIVEN keyboard input: when a character is pending at the keyboard port, the processor is INTERRUPTED (no Vblank). The character is read from the port, and placed in the keyboard input buffer (the one whose address you can get from the Iorec Xbios call). You don't need to use this buffer, however, if you understand the interactions between BIOS and GEMDOS I/O. The potentially confusing part is that if you do GEMDOS cooked input or output, the BIOS buffer is COMPLETELY EMPTIED into a GEMDOS buffer. So if you follow GEMDOS output with BIOS input you will get "no characters waiting." GEMDOS "cooked" I/O is Cconin, Cnecin, Cconout, Cconws, and Cconrs, and Fread and Fwrite on handles which refer to the console, such as handles 0 and 1 (stdin, stdout), handles DUP'ed from those, or -1, which always refers to the console, even if handles 0 and 1 are redirected. If you don't want ^C to terminate your program, you can either (A) use only BIOS calls, or (B) use only GEMDOS raw calls (Crawcin, Crawio, Cconis), or (C) use a terminate-vector handler which longjmp's to your recovery code. The best reason to use the buffer structure returned by the Iorec call is as a quick check for input keys pending. Checking to see if in == out (meaning the buffer is empty) is lots quicker than the equivalent BIOS call. This only works if you use NO GEMDOS console I/O calls. (I haven't forgotten about critical sections: I investigated, and they don't matter here.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt