Path: utzoo!lsuc!ncrcan!brambo!wwg
From: wwg@brambo.UUCP (Warren W. Gay)
Newsgroups: comp.sys.mac
Subject: Re: The ROM serial driver
Message-ID: <260@brambo.UUCP>
Date: 3 Feb 88 15:38:57 GMT
References: <4906@watdragon.waterloo.edu> <7305@apple.UUCP>
Reply-To: wwg@brambo.UUCP (Warren W. Gay)
Distribution: comp
Organization: Bramalea Software Inc., Bramalea, Ont.
Lines: 27

In article <7305@apple.UUCP> han@apple.UUCP (-- Byron B. Han --) writes:
>In article <4906@watdragon.waterloo.edu> palarson@watdragon.waterloo.edu (Paul Larson) writes:
>>
>>Has anyone else had trouble with the ROM serial driver?
>>Is it unreliable?  I need help.
>>
>There is nothing inherently wrong with the ROM serial driver (that I am aware
>of).  It lacks some of the nicer features that the RAM-based serial drivers 
>have, like manipulation of DTR, break stuff, parity error character 
>replacement, etc etc etc....

I wrote a terminal program as a Desk Accessory once, and I recall that I had to 
resort to RAM drivers.  The ROM drivers (I think) prevent you from specifying
your own buffers, and certainly do not handle the full buffer case correctly.
The default serial buffer is very, very TINY!  In the case of a desk accessory
there was always a chance that the program would be inactive while traffic
suddenly rushes in - bursting the TINY buffer, and eventually creating a bomb.
The RAM drivers permitted me to specify my own LARGE buffer, and enable automatic
flow control, so that if the buffer should get full, an XOFF was immediately
sent even if the desk accessory was put to sleep.

But check this information out first - its been over a year since I hassled 
with this.
-- 
Warren W. Gay - Bramalea Software Systems Inc...!utgpu!telly \ !brambo!wwg
                ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan /
                "Life is a compromise.  So lets be #pragma-tic."