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