JK> It's been years since I ran binkley.. maybe it's a
JK> corrupted file in something like fastlst or whatever
JK> nodelist compiler he's got running.. you know, where
JK> the passwords are entered for the node, that kind of
JK> thing.
That looks like a modem problem to me. It looks like there is noise during the
EMSI/YooHoo handshake. The corruption is happening during the handshake.
There's nothing wrong with the nodelist or session password.
Maybe you can fix the problem by just sending a normal "CONNECT 19200" without
the extended modem status string (or get Bob's modem/system to understand
extended strings).
I can reproduce one-sided-only handshake problems between FrontDoor and
Binkleyterm (where FrontDoor->BinkleyTerm is problematic but
BinkleyTerm->FrontDoor is successful).
FrontDoor initiating call:
=======================================================================
---------- Sat 01 Sep 12, FD 2.02
+ 22:53:19 Event 0-@
- 22:53:19 Preparing outbound mail
22:53:19 No messages to send in this event
+ 22:54:20 Calling ypan.dyndns.org, 3:712/104, 12700000000100024
= 22:54:24 CONNECT 38400
? 22:55:04 No response from remote system
22:55:04 Terminating call
=======================================================================
This is between two Virtual Modems on the same computer.
There is no problem when BinkleyTerm initiates a call to FrontDoor. The
handshake is fast and smooth to observe and completes successfully.
I have found that this problem is determined by which window is in the
foreground while the handshake is in progress. CPU is 100% if FrontDoor is in
the foreground while a handshake with BinkleyTerm is in progress, and I suspect
that this causes a delay with sending data during the handshake to BinkleyTerm.
FrontDoor is 16-bit DOS and probably not giving enough timeslices. I am using
BinkleyTerm 16-bit DOS but I suspect that even the 16-bit DOS version of
BinkleyTerm handles timeslices better than FrontDoor.
--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
