Martin_Koehling@do.maus.de (Martin Koehling) (05/06/91)
Richard Scott Hall heavy @ zip.eecs.umich.edu wrote: <1991Apr27.171053.29034@zip.eecs.umich.edu> >>>Is there a standard filename for the serial port? >> >>AUX: >> >>For a full list, check the guide to Atari BASIC that should have come >>with your ST, I think it's in there somewhere. >> > >I have tried this in GCC, but I get a NULL FILE pointer >when I do an fopen() on it...I am not too sure it works >unless I did something wrong... > >Richard Hall >University of Michigan When you tell GEMDOS to Fopen("AUX:",2 /*read/write*/), it will return 0x0000fffeL. This is the "device handle" for the serial port; it's WORD-negative, but LONG-positive (BTW: this is _not_ the same as handle 2, which can be redirected; device handles can't be redirected !). I think that GCC's fopen() mistakes this for an error code. Most (if not all) GEMDOS function return LONGs; in particular, the Fopen() and Fcreate() system calls should always be treated as returning a LONG. GCC's Fopen should do something like this: long err ; int handle ; err = Fopen(fname,2) ; if ( err < 0 ) { return (FILE*)0 ; /* ... open error ... */ } else { handle = (int)err ; } I suggest you try to find & fix it in the lib sources... Martin Koehling
ytsuji@wucc.waseda.ac.jp (Y.Tsuji) (05/09/91)
It's up to you whether to make use of the TOS Fopen() or not when you
implement your own open() in your own C library. For ordinary files,
the value returned will be similar to what other OS (i.e. unix) expects,
but when it comes to raw devices (/dev/tty,/dev/lpt,/dev/fd0 etc), you
need to be a bit inventive. What I have done is this:
(1) for keyboard/monitor, parallel port, and RS232C port, the returned
value by Fopen will be respected but not used. Instead values 128,
129,130 will be given. (The returned value of fffe etc will be kept
internally).
(2) for other devices e.g. disk drives and midi ports, the same trick
will be applied. drive A will be assigned 256, drive B 257 etc.
However, as drives are block devices, read/write and lseek can be
done only in units of 512. And we must keep a file pointer for each
device. There is no way of knowing the basic features of the device
as read/write is normally done to disks that are physically formatted
but may lack boot sector info. I simply followed the nomenclature of
minix.
At any event, I needed a file descriptor table internally that keeps info
to be given to stat() and fstat(). That table also keeps the name of the
file descriptor (I sometimes needed to know the name of the file from the
file descriptor). Read/write of raw device is necessary in such cases as
reformatter(re-initialises the boot sector,FATs and directory) and TAR.
Another thing I needed to use my brain a bit is giving i-node numbers(
real id number of files). I think I better keep this secret to myself so
as not to bore you to death.
Dr Y. Tsuji
ytsuji@cfi.waseda.ac.jpbammi@acae127.cadence.com (Jwahar R. Bammi) (05/09/91)
In article <1912@do.maus.de> Martin_Koehling@do.maus.de (Martin Koehling) writes: > When you tell GEMDOS to Fopen("AUX:",2 /*read/write*/), it will return > 0x0000fffeL. > This is the "device handle" for the serial port; it's WORD-negative, but ... > I suggest you try to find & fix it in the lib sources... > This problem is fixed in the lib. I belive it was first fixed at Patchlevel 63, but the fix is certainly there at the current Patchlevel 65. to determine if you have a fixed version, look in fcntl.h and it should contain the following lines at around line 81: #ifdef __MSHORT__ #define __SMALLEST_VALID_HANDLE (-3) #else #define __SMALLEST_VALID_HANDLE (0) #endif #define __OPEN_INDEX(x) (((short)(x)) + 3) cheers, -- -- -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155