home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / lanman / drivers / os2 / UBNEI / UBNEIO.ZIP / README.TXT < prev    next >
Encoding:
Text File  |  1991-08-29  |  9.5 KB  |  178 lines
  1. ;        Sample PROTOCOL.INI for UBNEI
  2. ;        -----------------------------
  3. ; This is a sample PROTOCOL.INI file for the UBNEI Ungermann-Bass NDIS MAC
  4. ; driver.  The [UBNEI] section shows examples of UBNEI configuration parameter
  5. ; settings.  Comments at the end of the file explain these parameters and give
  6. ; their default, minimum and maximum values.  The [protocol manager] and
  7. ; [netbeui] sections aren't meant to be complete or realistic examples, except
  8. ; for the "BINDINGS = UBNEI" line in the [netbeui] section.
  9.  
  10. [protocol manager]
  11.     DRIVERNAME = PROTMAN$
  12.  
  13. [netbeui]
  14.     DRIVERNAME = NETBEUI$
  15.     BINDINGS = UBNEI
  16.     SESSIONS = 32
  17.     NCBS = 100
  18.  
  19. [UBNEI]
  20. ;    Note that many of these parameters have default values (which are
  21. ; given below under "Comments about UBNEI parameters"). A parameter need not
  22. ; be specified in your PROTOCOL.INI if its default value is satisfactory.
  23.     DriverName = UBNEI$
  24.     AdapterType = NIUpc
  25.     MemoryWindow = 0xD8000
  26.     IO_Port = 0x368
  27.     IRQ_Level = 3
  28.     SlotNumber = 4
  29.     MaxRequests = 6
  30.     MaxTransmits = 6
  31.     ReceiveBufSize = 600
  32.     MaxMulticast = 16
  33.     ReceiveMethod = ReceiveLookahead
  34.     ReceiveBuffers = 64
  35.  
  36. ;  Comments about UBNEI parameters:
  37. ;  --------------------------------
  38. ;  DriverName:
  39. ;        This parameter's value must be UBNEI$, or, in the case where
  40. ;    multiple adapters are installed, UBNEI$ for the first adapter's
  41. ;    DriverName, UBNEI2$ for the second one, UBNEI3$ for the third, and
  42. ;    so on.
  43. ;  AdapterType:
  44. ;        This specifies the type of Ungermann-Bass adapter.  The possible
  45. ;    values are shown below.  You should use:
  46. ;
  47. ;    AdapterType = NIUpc          for the NIUpc or 3270 NIUpc adapter;
  48. ;    AdapterType = Personal NIU    for the 128K Personal NIU adapter;
  49. ;    AdapterType = Personal NIU/ex for the 512K Personal NIU/ex adapter;
  50. ;    AdapterType = NIUps          for the NIUps or NIUps/EOTP adapter;
  51. ;    AdapterType = NIUpc/EOTP      for the adapter which is known variously
  52. ;                    as NIUpc/EOTP, NIUpc Plus, and GPCNIU.
  53. ;        Some Ungermann-Bass adapter types are called by various names in
  54. ;    special contexts and in older documentation.  To support these other
  55. ;    naming conventions, the driver will accept the following synonyms for
  56. ;    AdapterType.
  57. ;    Synonyms            Meaning
  58. ;    --------            -------
  59. ;    PCNIU                Personal NIU
  60. ;    PCNIUex, Personal NIUex        Personal NIU/ex
  61. ;    NIUps/EOTP            NIUps
  62. ;    GPCNIU, NIUpc PLUS, NIUpcPLUS    NIUpc/EOTP
  63. ;  MemoryWindow:
  64. ;        This specifies the physical base address in the PC memory address
  65. ;    space of the "window" through which the adapter's RAM will be refer-
  66. ;    enced.  This parameter's value must agree with the jumpered configur-
  67. ;    ation of the adapter. (For the NIUps, "MemoryWindow" is not needed and
  68. ;    will be ignored.)
  69. ;  IO_Port:
  70. ;        This specifies the base address in the PC I/O address space of the
  71. ;    adapter's I/O ports.  Its value must agree with the jumpered configur-
  72. ;    ation of the adapter.  (For the NIUps, "IO_Port" is not needed and
  73. ;    will be ignored.)
  74. ;  IRQ_Level:
  75. ;        This specifies the IRQ level that will be used by the adapter-to-
  76. ;    PC interrupt.  Its value must agree with the jumpered configuration of
  77. ;    the adapter.  (For the NIUps, "IRQ_Level" is not needed and will be
  78. ;    ignored.)
  79. ;  MaxRequests:            (Default = 6; Min = 1; Max = 10.)
  80. ;        This specifies the maximum number of "GeneralRequest"s that can be
  81. ;    simultaneously outstanding.
  82. ;  MaxTransmits:        (Default = 6; Min = 1; Max = around 400.)
  83. ;        This specifies the number of "TransmitChain"s that the MAC driver
  84. ;    guarantees to accept without giving an "OUT_OF_RESOURCE" response.
  85. ;  MaxMulticast:        (Default = 16; Min = 0; Max = 255.)
  86. ;        This specifies the maximum number of multicast addresses that can
  87. ;    be in effect simultaneously. (NOTE that there's no 's' on the end of
  88. ;    this keyword.)
  89. ;  ReceiveBufSize:        (Default = 600; Min = 256; Max = 1514.)
  90. ;        This specifies the size of the receive buffers the MAC driver will
  91. ;    use. This should be large enough to hold the normal expected received
  92. ;    frame. It need not be large enough to hold the largest expected frame.
  93. ;    The MAC driver will handle large frames in multiple receive buffers.
  94. ;    The value of ReceiveBufSize must be even.
  95. ;  ReceiveMethod:    (Default = ReceiveLookahead;
  96. ;             other choices:    ReceiveChain, AdapterBuffered
  97. ;             and        ReceiveChain, HostBuffered
  98. ;        This determines the method of received frame delivery the MAC
  99. ;    driver will use. The possibilities are described below. Which one
  100. ;    is best to use depends mainly on how the Protocol driver you're using
  101. ;    works.  Use number (1) if you don't know anything about the Protocol
  102. ;    driver.
  103. ;   (1) ReceiveMethod = ReceiveLookahead
  104. ;        When a received frame is available and Indications are On, the
  105. ;    MAC driver will call the Protocol driver's "ReceiveLookahead" routine.
  106. ;    "ReceiveLookahead" will be given the total length of the frame and a
  107. ;    pointer to the "lookahead" data in a receive buffer in the adapter's
  108. ;    RAM. The Protocol driver must copy the frame (possibly using the MAC's
  109. ;    "TransferData" routine) before returning from "ReceiveLookahead". When
  110. ;    "ReceiveLookahead" returns, the MAC driver frees the receive buffers
  111. ;    in the adapter's RAM for use in receiving more frames.
  112. ;        This method works well if the Protocol driver is able to copy the
  113. ;    frame to the Protocol driver's client's buffers at the time "Receive-
  114. ;    Lookahead" is called.  It is also a good method if the Protocol driver
  115. ;    always copies frames into internal buffers of its own.
  116. ;   (2) ReceiveMethod = ReceiveChain, AdapterBuffered
  117. ;        When a received frame is available and Indications are On, the MAC
  118. ;    driver will call the Protocol driver's "ReceiveChain" routine, passing
  119. ;    it an "RxBufDescr" which points to the frame in the receive buffers in
  120. ;    the adapter's RAM. The Protocol driver can either (a) immediately copy
  121. ;    the frame or (b) save a copy of the "RxBufDescr" and leave the frame
  122. ;    in the buffers in the adapter's RAM, to be copied at a later time. In
  123. ;    case (b), the Protocol driver must copy the frame as soon as possible
  124. ;    and call the MAC's "ReceiveRelease" function to make the buffers in
  125. ;    the adapter's RAM available for receiving more frames.
  126. ;        This method of operation can be the most efficient.  It's a little
  127. ;    better than the "ReceiveLookahead" method if the Protocol driver can
  128. ;    copy the frame immediately, because the overhead of calling "Transfer-
  129. ;    Data" is avoided.  Also, it has the advantage over "ReceiveLookahead"
  130. ;    that the Protocol driver doesn't have to copy the frame immediately --
  131. ;    the frame can be left for a short time in the adapter's buffers. But
  132. ;    if frames are left in the adapter's buffers long, it will run out of
  133. ;    buffers and start losing frames. Also, there's the overhead of calling
  134. ;    "ReceiveRelease" to consider.
  135. ;   (3) ReceiveMethod = ReceiveChain, HostBuffered
  136. ;        When a received frame is available and Indications are On, the MAC
  137. ;    driver will copy the frame from the receive buffers in the adapter's
  138. ;    RAM into receive buffers in the Host memory and call the Protocol
  139. ;    driver's "ReceiveChain" routine, passing it an "RxBufDescr" which
  140. ;    points to the Host-memory buffers.  The Protocol driver can copy the
  141. ;    frame immediately or leave it in the Host-memory buffers.  It must
  142. ;    eventually call the MAC driver's "ReceiveRelease" routine to free the
  143. ;    Host-memory buffers for reuse.  The buffers in the adapter's RAM are
  144. ;    made available for receiving more frames as soon as "ReceiveChain"
  145. ;    returns.
  146. ;        In this mode, the MAC driver allocates receive buffers in the Host
  147. ;    memory.  These buffers are allocated at driver INIT time. Their number
  148. ;    and size are determined by the "ReceiveBuffers" and "RcvBufSize" para-
  149. ;    meters.  The only advantage of this mode is that in it the MAC driver
  150. ;    provides a possibly large amount of long-term frame buffering in which
  151. ;    a Protocol driver can leave received frames until it can deliver them
  152. ;    to its clients.  This advantage comes at the cost of the space devoted
  153. ;    to the Host-memory buffers.  This is an inefficient mode if the
  154. ;    Protocol driver always copies frames into its own internal receive
  155. ;    buffers or if it can quickly copy frames from the adapter's buffers to
  156. ;    its client's buffers.
  157. ;  ReceiveBuffers:        (Default = 64; Min = 16; Max = 512.)
  158. ;        This specifies the number of receive buffers that the MAC driver
  159. ;    will allocate in the Host memory.  This parameter is meaningful only
  160. ;    if "ReceiveMethod = ReceiveChain, HostBuffered" is specified.  For
  161. ;    other values of "ReceiveMethod", no receive buffers will be allocated
  162. ;    in the Host memory -- the "ReceiveBuffers" parameter will be ignored.
  163. ;  SlotNumber:            (Min = 1; Max = 8.)
  164. ;        This parameter is needed only when multiple NIUps adapters, and
  165. ;    multiple instances of the UBNEI driver, are installed. Even then, this
  166. ;    parameter is required only if it is necessary to override the default
  167. ;    association between driver instances and adapters.  By default, the
  168. ;    UBNEI driver instance that comes first in PROTOCOL.INI will be associ-
  169. ;    ated with the NIUps adapter in the lowest numbered slot, the UBNEI
  170. ;    driver instance that comes second will be associated with the NIUps
  171. ;    adapter in the second lowest numbered slot, and so on.
  172. ;  PermanentAddr:    The value is a string of 12 ASCII hexadecimal digits,
  173. ;            for example:    PermanentAddr = "00DD01AABBCC"
  174. ;        This parameter provides a way to override the "Permanent Station
  175. ;    Address" that's built into the adapter's ROM. Note that this parameter
  176. ;    is normally not needed, and shouldn't be used.  The NDIS specification
  177. ;    strongly discourages configuring the "Permanent Station Address".
  178.