From: bitbangr@moosevax.cojones.com (Anthony W. Hursh)
Newsgroups: comp.bbs.waffle
Subject: Re: if (++moves > 255) logout ("SiN"); ?!?!
Date: 7 Oct 92 16:14:26 GMT
Organization: Dead Moose Enterprises

dawson@willard.UUCP writes:

>bitbangr@moosevax.cojones.com (Anthony W. Hursh) writes:
>
>> dawson@willard.UUCP writes:
>> 
>> > If Waffle is bum-fuddled by hardware limitations, and that has been pointed
>> > to by various posts to this group (or have you simple MISSED the posts that
>> > have agreed with mine?), then, simply put, Waffle is not robust.
>> 
>> Come now. If your modem isn't lowering CD reliably there's nothing Waffle
>> can do about it. Waffle can only work with the signals coming in from the
>> modem.

>I admit that I am CURRENTLY having problems with my modem.  However, the
>behaviour I've described happened well in the past, and with other modems
>as well as my current one.

Problems with call waiting are well-known. In fact, one of the more
popular local bulletin boards (*not* a Waffle system, one might add)
has, as part of its signup screen, something similar to: "If you have call
waiting on your modem line, get rid of it. Call waiting is only an excuse
ONE TIME." This system will *delete your account* if you have call waiting
on your modem line. There are a number of modems that can be sent into
screaming hysterics by call waiting. Sometimes this behavior can be improved
by setting S registers or the like. Sometimes not. This is a hardware
problem. On an IBM PC (I assume you are running DOS Waffle) you can detect
carrier by two methods:

1) Do a byte input from the hardware port at (baseaddress + 6),
mask it with 0x80, and check for zero or non-zero value. Baseaddress
is the port base address of the serial port in question.

2) If you're using a FOSSIL driver, load the AH register with 3 and
the DX register with FOSSIL port number, then execute an INT 14H
instruction. Mask the return value with 0x80 and test for zero or
non-zero value. I haven't poked around in FOSSIL guts, but I strongly
suspect that the FOSSIL call uses method 1, above.

Note that method 1 uses a direct call to the PC hardware, and that method
2 most likely does the same. If the serial port is operating properly, the
bit masked value is directly equivalent to the state of the modem carrier
detect line. Perhaps you have some magic technique for telling if
the hardware carrier detect line is lying or not?

>then readily apparent to the casual observer that there is confirmation of
>the existence of a problem.

Yes. But the claim that the problem lies in the BBS software rather than
in the modem hardware is not at all "readily apparent".

>Suppose I were writing BBS software that was to be used with a variety of
>modems, each of which might have different characteristics regarding DSR
>timing.  How much variation should I allow in order for my software to
>reliably run with the greatest majority of these modems?  If some few
>modems had documented difficulty in certain circumstances, do you think
>I'd still be justified in claiming that the software was "robust" ?
>
>If you have ready answers to these and other questions, then you either
>have great experience in writing real-world applications and have a great


I'm not Chuck Forsberg, but do have *some* experience in writing real
world serial communications applications. Author of QWK'n'Dirty,
a combination QWK reader and terminal program (just released), Bdexx,
a hypertext search engine that will work either over a serial port
or with direct screen writes, using a serial port windowing library
written by myself, WWCP (see signature), and numerous other projects
going waaaay back to the time I hacked an Atari 8 bit C compiler
so it would generate binaries compatible with BBS Express. That required
a rewrite of the standard library, runtime package, and linker, much of
it in 6502 asm. That machine also had a 64K address space and the BBS
ate most of it. Making everything fit was "interesting". What have
you written lately?

I've written enough stuff to know that there are oddball modems
out there, and that writing code that will work on all of them
is difficult, sometimes impossible. The job becomes very difficult
if you don't have an identical modem to work with. On the other hand,
writing code that will work on 95% of the modems out there is easy.
You mention "real world". In the real world people write code for a
living. If you can write code in 1 hour that will work for 95% of the
customer base, and writing code for the other 5% takes 50 hours
(the other 5% aren't all the same. Tracking down a modem that
exhibits the problem and/or debugging by phone or email can easily
take a day or more), you tell me how cost effective that is. 1 hour
for 95%, 10 hours for each additional percent.

Short answer: it depends on how many "some few" is.

It also depends on how polite the customer is, and the financial
situation. If the customer has paid actual money, I will fix the
problem (if it can be fixed... some modems are beyond hope) or
refund the customer's money. If it is a shareware program and the
customer hasn't paid any money as yet, everything depends on the
customer's politeness. If he is polite, I will fix the problem (again,
if it can be fixed) or devise a workaround. If he is rude, I'll suggest
that since he's not happy, he should write his own software. There's
nothing stopping him, after all. If he writes something better than mine
I may even use it myself. Isn't the free market a wonderful thing?

>understanding for the problem at hand, or you must be an assuming, self-
>aggrandizing fool with an appetite for public embarrassment.

I'll give that highly rational statement the response it deserves. If
you're going to do that please direct your followup to alt.flame
(which I don't get).



--
Author of WWCP, Waffle-WWIV gateway software. Send email for info.
Internet: bitbangr@moosevax.cojones.com 
WWIVnet:bitbangr#moosevax.cojones.com@500 or: 1@500
UUCP: ..!uunet!coldbox!moosevax!bitbangr