yes, it is pure magic! I have been meaning to write a process for
figuring this out for a while but there are so many variables it is
tough. i have sent this to ct-user also to try to spread the word a bit
more. if anyone wants to help make it more specific or knows of other
things to check or ways to check them please let me know.... and if you
have experience writing procedures for software and would like to make
this more organized i'd love to talk to you.
to sort out tsr's...
1. take notes. make a table of devices, irq's, hardware addresses,
software interrupts and keep it with the computer for later reference.
2. check hardware irq assignments. check jumpers on dvp, use msd, or
norton sysinfo, your system bios(on newer machines) to see what irq's
are used and to be sure there are no conflicts. irq conflicts are
commonly recognized by one-way links. usually the computer can send to
a com port or network card but will not receive, or will lock up on the
first receipt of data.... so it can be delayed failure or strange
behavior. note that in pci bus machines you may have to manually set
the bios to exclude irq's used by old isa cards from automatic
assignment by the bios.
3. check hardware memory address assignments. these are the usually 3
digit hex addresses like 0x2fb, 0x300, or like 304h, etc that often are
talked about along with setting irq's in setup instructions. note, most
devices use more than one address. many use 4 addresses, like 0x300
through 0x303, or 8 addresses. but some (like one nic i have heard of
recently) uses 32 addresses... so it would use 0x300 through 0x320.
These addresses can not be shared or strange things may happen like
devices do odd things. these are set by jumpers or by running network
card setup programs to set them in eeprom on the card.
4. check software interrupts. software interrupts are a method of
communication used between (usually dos) programs. most often used
between tsr's that are resident in memory and other programs (including
other tsr's). these are similar to irq's in that they can not normally
be shared. they are often described by a 2 digit hex number in a format
like 0x60 or 60h.
now it gets messy. there are some ranges of addresses that are
'reserved' or commonly used by certain pieces of software for
communications by default. these are often not advertised or not
obvious in the software documentation. the following are common
defaults and ranges of interest for ct and nettsr use:
0x60 dvptsr default, some packet drivers default
0x61 comtsr1 default
0x62 comtsr2 default
0x63 comtsr3 default
0x64 comtsr4 default, nettsr default
0x60-0x6f is the normal range used by packet drivers, they often default
to 0x60 if you don't specify anything else which will kill the dvp.
nettsr will only search this range to find the packet driver, if you
assign the packet driver one outside this range the nettsr will fail to
load.
note, these are usually entered as hex numbers.. but nettsr takes this
argument in decimal so remember 0x64 = 100 decimal if you want to
change it. (just to add to the confusion nettsr reports the interrupt
number in hex when it loads)
The most frequent problem seems to be that the packet driver takes 0x60
which kills the dvp or vice versa. also note that you can not load the
comtsr that you set nettsr for.. so you can not use comtsr4 if you load
nettsr with the default interrupt.
conflicts in sw interrupts are hard to find. norton sysinfo may report
which interrupts are used if you run it after each tsr is loaded. there
may also be other programs that report which ones are being used (i
don't remember if msd has those or not). but note that they will not
find conflicts, they will normally only report the last program that was
loaded that wanted to use that interrupt. symptoms are usually bad,
either programs won't work or will crash outright. these are usually
fairly crude communications between programs and don't have much room
for error checking or reporting so results are often simple crashes.
5. Check IP address assignments. Each machine must have a uniqe ip
address. IP addresses are normally written in a format like
204.245.55.5 which is 4 decimal numbers between 0 and 255 separated by
periods. Don't confuse this with the number the nic setup program uses
or that the packet driver load may report that looks like:
00:44:5e:10:44:00 this is your unique world wide hardware address for
that card, it is used by very low level network protocols and is not
related to the IP address in any way. (note that this unique id code
was around long before intel decided to put one in the pentium 3 chip).
IP addresses have some odd rules. in most cases it is best to stay away
from using 255 for any of the 4 values. it is also best to avoid 0 for
either the first or last numbers. using a value of 10 for the first
number uses a block of addresses reserved for experimental use which is
why i use them. i prefer to set addresses like 10.0.0.10, 10.0.0.15,
10.0.0.20, etc for my 10m, 15m, and 20m stations respectively so when i
run a sniffer program or use ping to test the network i can tell which
machine is sending what packets. WARNING! if you share a wire or
router with another network you should contact the network administrator
to be sure that you don't do something that will confuse the rest of the
network. they are the best ones to talk to about manually setting
broadcast addresses and masks if you must do that. assigning bad ip
addresses will normally be seen as one-way or no data transfer, it can
also cause windows 95/98/nt machines to barf when connected to the
network. NOTE that once the nettsr is loaded you can use a windoze
machine on the network to 'ping' the nettsr to see that the wire
connection is proper and that the software is running. to do this open
a dos window and use a command like 'ping 10.0.0.10' to check the
connection and round trip time.
another part of the IP address that is often ignored is the 'port'.
different ports are used by different pieces of software by default.
i.e. telnet normally uses port 23, http normally uses 80 and/or 8080.
nettsr defaults to 9870 which is normally not used, but again if you are
sharing the network with other services check with the network
administrator to be sure that port won't cause something else on the
network to barf. there are some of the fancy new network security
programs that will report unusual activity on certain ports and
addresses.
6. other things:
a. loadhi or lh, these may or may not work with packet drivers or other
tsr's like nettsr or comtsr's.
b. memmaker often tries to loadhi or change the order of loading
drivers.
c. nettsr can not be removed from memory, and neither can most packet
drivers. therefore after each change you attempt in parameters you must
reboot.
d. for some reason nettsr may not work unless at least one comtsr is
also loaded. i have not figured this out yet, but if everything seems
to load but doesn't work try loading a comtsr even if you don't need it.
e. i recommend using a minimal config.sys and autoexec.bat file for
starting ct with all the tsr's.
f. normally an nic can not be shared between a packet driver and other
network protocols. so you should not expect to be able to run other
networking programs at the same time as the packet driver/nettsr.
g. there is a driver for win-95 that simulates a packet driver to let
you run nettsr in a dos window. it does work, but in my testing was not
exceptionally stable... which was probably more of a win-95 problem that
with the driver.
--
David Robbins K1TTT (ex KY1H)
k1ttt@berkshire.net or robbins@berkshire.net
http://www.berkshire.net/~robbins/k1ttt.html
--
Submissions: ct-user@contesting.com
Administrative requests: ct-user-REQUEST@contesting.com
WWW: http://www.contesting.com/ct/
Questions: owner-ct-user@contesting.com
|