From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
Subject: Re: Non-Blocking reads
Organization: SAR Systems Development & Processing, JPL
Date: Sat, 26 Sep 1992 21:46:12 GMT

In article <1992Sep25.203233.1046@csi.uottawa.ca> cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
>
>I've got a program I'm trying to get ported to the Atari from the big
>wide world out there, and seem to be down to two "missing" functions:
>
>(1) Something called kbhit(), more particularly:
>
>int kbhit(void)
>{  /* code omitted */
>}  /* This function returns TRUE if there is a key code waiting to be */
>   /* read, and FALSE otherwise */
>
>(2)
>int getch(void)
>{
>}
>/* This function returns the keycode that was waiting to be read */
>/* Yup, it's supposed to return an integer, not a char.  That's NOT a */
>/* typo. */
>
>Ideally, I'd LOVE to get something that's portable between MiNT and
>TOS both.
>
>There's a Unix implementation that looks like the following:
>------Cut Here--------

Ah, looks like you're porting from MSDOS... On the ST, the GEMDOS function
Cconis() will serve for kbhit(), it returns true/false depending on if there
is a character available on the console, and Cconin will read 1 character.
Cconin returns a long (not just an int) with the high word containing the
keyboard scan code of the character read. You can get more info on the GEMDOS
calls from most ST programming books. (It also sounds like you're not using
any ST programming books in your current effort, otherwise you might have
bumped into this solution already... It would be a good idea to get hold of
some real documentation before you proceed any further...)

Since MiNT is backward compatible with TOS, you'll be pretty safe using these
GEMDOS functions with either TOS or MiNT. Also you should note that these
GEMDOS functions can have their target devices redirected, e.g. someone
starting up your program can decide to point Ccon at the RS232 port and your
program will work using the serial port instead of the console, and all of
that is transparent to you... (i.e., you don't have to do anything special
to make it work). 

Finally, you should be careful about how you do I/O in this program. As an
example, in Unix you can use the stdio library (printf, putchar, getchar,
etc.) or you can call the Unix system directly (read, write, lseek, etc.).
The stdio library is built with the Unix system calls, but adds its own
layer of buffering between your program and the system. On the ST you have
the same situation, but with several more possible levels of indirection.
Most C compilers for the ST come with an ANSI/Unix-style library, which will
include an stdio implementation. They will also include Unix read/write/lseek
emulation, but now you have to realize that both stdio and read/write are
library level, and the actual "system level" is one level deeper, at the
GEMDOS function level. In fact, for functions like getting a character from
a tty-style device, there's yet another lower layer, the BIOS level. Unix
programming manuals warn you not to mix stdio calls with system calls,
because the stdio buffering will get fouled up when you go directly to
the system. You have to keep this mind on the ST as well, and realize that
you have to make sure not to mix up any of BIOS, GEMDOS, read/write, or
stdio. Every level of that list provides its own buffering, so mixing calls
between them is definitely a bad idea.

(Actually, whether or not the read/write emulation does any buffering
varies depending on whose C library you use. As I think about it, most of
them simply translate this set of Unix system calls directly to their GEMDOS
equivalents.)

The main point of this spiel is to make sure you choose only one level of
I/O routines to use, and stick with it. If you really know what you're
doing you can mix and match, but it's a real pain when you get it wrong.

Usually when I port stuff I tend to use GEMDOS level or higher, that way the
programs will behave properly when run from the console or run remotely
over the serial port.
-- 
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA

California, land of dreams. For many, moving out to CA is their first step
toward fulfilling their dreams. For most of them, it's also their last.