 NetMail (1:321/238)  NETMAIL001 
 Msg  : 6 of 22                             Snt Pvt Cra Loc                     
 From : David Baird                         1:321/238       Mon 25 Oct 93 02:38 
 To   : Dave Wendling                       321/227         Mon 25 Oct 93 02:43 
 Subj : Question                                                                

Hi David,

 > Hi dave,
 >   Thanks again for the help with the echos. I have my own BBS
 > 'HomeBrew' which I wrote running ok under windows. The help
 > file you suggested I FREQ from you was great! I am still
 > having problems with FrontDoor 2.11 picking up the line when
 > someone calls in and I have FD running in the background. Any
 > thoughts on this? I tried the ZCOMM31.DRV that came with the
 > windows file I FREQed from you but It doesn't seem to make a
 > difference. Any thoughts on this?

Well the problem with FD 2.11 is a multitude of factors:

First is the multi-tasking/time-slicing awareness that it supposedly
has.  It stinks! So you have to force it to actually share time slices. You do
this by starting FD with the /forceint28 switch.

Second is your fossil. I have tried several and fd2.11 is finicky with certain
combinations of fossils and hardware. I never could get
X00 to work well with it at all. Bnu version 1.89H gave me flakey performance,
especially using the tm-win.com task managager that came with it. I rolled
further and further back on fossil versions till the session handshake values
went away... Ended up back with version 1.70. Bill Cheek in Calif uses 1.89 H
with great effectiveness on one machine and it will not work with another... you
figure that one out...

Third: is your com driver and the 16550 support it does or does not provide a
DOS Window. Most do not. A combination of shareware will get you there... CHCOMB
and WFXCOM for instance.

The best drivers that eliminate the 16550 problem are of course not free. I have
tried KINGCOM, Bill swears by TurboCom. In either case they substitute the com
driver with one that provides greater control over the serial port with fine
tuning for the trigger point of the fifo and the size of the buffers... Getting
good throughput is a matter of compromise to a certain extent. You can not
maximize for through-put establishing high trigger points and large receive
buffers without creating some lag in delay for servicing the port. With lots of
experimentation Bill and I have discovered that setting the trigger point at the
16550 default of 14 bits is NOT a good idea. More like 8 is better and 4 is okay
if you have a reasonable fast machine. Both TurboCom and Kingcom give you that
ability to use dialogue boxes to set the buffer sizes and trigger points,
eliminating you having to directly edit the system.ini file...

Major difference between the two... TurboCom requires a device driver in the
config sys, Kingcom does not...

Last issue is giving Windows that amount of time to relaibly service the port
and your foreground task at the same time. Two things can be done to help...
There are some arcane Windows system.ini settings that can make a major
difference, they include:
    keyboostime=
    comboosttime=
    com#buffer=
    com#fifo=

these are the major ones if I remember correctly...

Look in the various system.ini files that came with the win-fd3 file. I found
the keyboosttime one was a god-send in getting command of the keyboard back.

Wintimeslice= is an overworked solution thta frankly Bill and I have discovered
does not really matter much performance wise. Better not to tinker with it.
Background and foreground priority the same ting. I can't tell you how many
times I got suggestions to boost the priority from well meaning people. As long
as you give FD about 2-1 priority with your foreground task, you have given it
enough. Setting it to such values as 1000 5000 or 10000 only screws thigns up
and accomplishes very little. Setting the Mintimeslice to a too small figure (ie
10) causes the processor to thrash between tasks unnecessarlily. Leave it at 20
if you can.

One way to boost the issue of sharing resources is using a program like TAME to
provide surrendering of un-necessary polling clock ticks back to the foreground.
Version 3.0 (commercial) and version 3.61 (newest shareware) both will work well
in converting Frontdoor's Deskview multi-tasking awareness into Windows
awareness. David Thomas the author has logged onto my board and sent me stuff
directly inthe mail to help solve this "lazy answer" problem so I can attest to
his support of the product and of you the end user. I have his latest version of
shareware 3.61 available here for freq under the magic name of TAME.

Here are some of my critical settings in my system.ini file, working with
KINGCOM and Tame and BNU 1.70 and Frontdoor 2.11

[boot]
;comm.drv=COMM.DRV

[386ENH]
DEVICE=KINGBUFF.386
DMABufferSize=64   ; Increases input buffer for hard drive, reduces
; CRC errors for fast downloads...
KeyBoostTime=.005 ;this provide foreground app's better perfomance
;servicing the keyboard, made a big difference!
SystemROMBreakPoint=false ; setting required by QEMM
FasterModeSwitch=1        ; Old standard mode command that helped
; before
32BitDiskAccess=on
DEVICE=KINGVCD.386
MinTimeslice=20
WinTimeslice=200,100
WinExclusive=0
Comboosttime=4 ; higher thatn 8 did not really effect performance
COM2FIFO=40    ;this is Kingcom's way of setting the fifo trigger
;point and teling itelf there is a 16550 to work with
Com1AutoAssign=0
Com2AutoAssign=0
VirtualHDIRQ=false
COM2BUFFER=1024 ; Setting this higher results in greater delays...

Hope this helps, it is 2:45 am and my head is a bit foggy, if I have forgotten
something I'll netmail you with it later in the week!

David


