From: ridder@zso.dec.com (Hans Ridder)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Baudbandit.device?
Date: 15 Oct 92 18:58:45 GMT
Organization: Digital Equipment Corporation - DECwest Engineering
Originator: ridder@zowie.zso.dec.com

In article <jbickers.0gwi@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:
>    Somewhere the article I was replying to said how the serial.device
>    sacrificed speed for features. I was trying to point out how bogus
>    this claim would be if it STILL didn't support dropping DTR.

I don't believe I said it that way.  I believe I said that
BaudBandit.device left out some features (of the serial.device) to get
it's speed.  I never said that serial.device has everything you'd ever
want and thus has a good excuse to be slow.

I too would like better control of the modem signals, but if we had
them, people would do *all sorts* of ugly things things with them.  At
least this way there is *some* reasonable modem signal behavior from the
serial.device. 

I'd like to point out that C= is well within the spirit of the EIA232
standard to only support lowering of DTR by closing the device.

>    No, but then BaudBandit.device doesn't have people going about
>    claiming how wonderful its features are.

Well I *certainly* wasn't claiming that the serial.device features were
"wonderful," as you say.  Again, I merely stated the fact that
BaudBandit.device achieved its increase in speed by leaving out some
features that serial.device has.  Then everyone starts telling me that
those missing features aren't needed.  I took that as being a rather
silly assertion, since some segment of the user population needs those
features.  I don't think you or I can make any good estimate of that
population's size.

>    It's not the quantity of the examples, it's the quality. Hands up
>    everyone whose only comms is BBSing. Hands up everyone who has
>    more than 50% of the comms time spent BBSing. Around people I
>    know, virtually everyone would have raised their hand.

I didn't raise my hand for either question, honest, although I'm only
one person.  You and I obviously know different sorts of people because
in my circles, I'm not the only one who would have had my hand down.
This just makes the point that the world is a big place, and we (you and
me) can't make the assumption that our experience is "typical."

>    It turns out VLT supports the Unix box simply by stripping the
>    8th bit, and not relying on the serial.device to do the job. So
>    one doesn't even need 7E1 for that...

That's true.  There are other systems which *check* parity, and they
wouldn't work with that solution.  I think parity is silly, and
apparently you do too.  Unfortuatly, some people in the world forgot to
ask either of us if they should be using it.  ;-)

>    Frankly no, I don't think this is the case. Writing a fast
>    general purpose piece of code is just a matter of writing more
>    specialized chunks, which would increase the size of the thing
>    but not slow it down.

In the case of the serial.device, things like parity, break detection,
overrun detection, XON/XOFF, etc. are all in the critical path.  They
don't just add to the size of the code, they add to the number of
instructions which *must* be executed for every character received.
That slows it down.  You can't just take your "specialized chunk" out
without a conditional test, and that's part of what slows it down.

The only solution for the serial.device would be to have separate
interrupt routines for every possible combination of desired "features,"
or to have a separate driver altogether (hence BaudBandit.device.)  C=
at partially addressed the problem with RADBOOGIE, but that of course
adds another conditional in the critical path....

>*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***

-hans
-- 
  Hans-Gabriel Ridder				Digital DECwest Engineering
  ridder@rust.zso.dec.com			Bellevue, Washington, USA
  {pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
Newsgroups: comp.sys.amiga.datacomm