Path: utzoo!attcan!uunet!husc6!mailrus!ames!hc!lll-winken!lll-lcc!unisoft!gethen!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: RS-232 & MWC:  Help....
Message-ID: <326@bdt.UUCP>
Date: 31 May 88 18:03:32 GMT
References: <56200002@bucc2>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 64

In article <56200002@bucc2> helix@bucc2.UUCP writes:
>	A couple of weeks ago, I had started to program a Bulliten
>Board System for my ST.   I have, however, run into a few problems
>with the I/O routines for my RS-232 port.  
>	First, I tried to open files to "aux:" and use feof() to see
>if any characters were in the buffer, but that did not seem to work
>properly.  Then, I just changed the routines and used some GDOS functions
>like Cauxin, Cauxout, Cauxis, and Cauxos.  These seem to work fine, but
>they do not use buffers.  I would like to write this BBS so that it doesn't
>use too many system dependent functions.  Is there any way I can access the
>RS-232 port with the standard I/O functions or do I have to stick with 
>GDOS??  Also, I am using the right approach??

I'll give my recommendations, but remember as with everything else, there is
always more than one way to do it, and this is nothing more than an opinion.

The safest way to solve portability is to NOT assume UNIX style TTY I/O
exists and provide your own TTY interface ("glue") routines.  For example,
create a set of routines as follows:

	open_line
	read_line
	write_line
	ctrl_line
	...etc...

Make the library provide the fundmental functionality necessary for
your application.   Then put the system dependencies in one place,
isolated from the rest of the application code.   The reason I
recommend this instead of assuming UNIX style TTY I/O is two fold:
1) you may want to port to a non-UNIX system where the UNIX calls don't
work someday, and 2) the TTY I/O control calls aren't the same even between
the various flavors and versions of UNIX.

Now for the Atari ST specific stuff...  Depending on the level of control
needed, the BIOS calls may actually be preferable to BDOS (GEMDOS) calls.
If you need more control than these provide, you may have to write your
own interrupt and RS-232 device handlers (e.g. to toggle RS-232 control
lines).  Another reason BIOS calls might be better are performance;
they're slightly faster than the BDOS (Caux?? calls use the BIOS Bcon??
calls eventually).  The disadvantage to using the BIOS calls is that the
software then becomes more hardware dependent because it is assuming hardware
device 1 is the RS-232, and there is nothing else connectted there (e.g.
a MUX or network).

With RTX, the cleanest way to get both BIOS level speed and flexibility and
BDOS device selection flexibiloity is to open the device by name, using
a run-time selectable device name, and then use the RTX Ftype call to get
the BIOS level device number at run-time.  This also means that custom device
drivers can be installed supporting the device control operations (e.g.
toggling RS-232 control lines) at the driver level.

So in summary, you define a device independent I/O library.  Then you use
ST calls (probably BIOS, maybe BDOS) to write a ST specific version of
the library.   When you port to another system, you simply write a new
"glue" module, using that system's best RS-232 calls.

Hope this is somewhat informative.

	
-- 
David Beckemeyer			| "Reckon the Ball's plumb open now,
Beckemeyer Development Tools		| and it's `swing partner'!"
478 Santa Clara Ave, Oakland, CA 94610	|    - Unnamed Cowboy, upon seeing
UUCP: ...!ihnp4!hoptoad!bdt!david 	|      heap many Indians approaching