;		Sample PROTOCOL.INI for UBNEPS
;		------------------------------
;   This is a sample PROTOCOL.INI file for the Ungermann-Bass NDIS MAC driver
; for NICps/2 cards ("UBNEPS").  The [UBNEPS] section shows examples of UBNEPS
; configuration parameter settings. Comments at the end of the file explain
; these parameters and give their default, minimum and maximum values.
;   The [protocol manager] and [netbeui] sections aren't meant to be complete
; or realistic examples, except for the "BINDINGS = UBNEPS" line in the
; [netbeui] section.
;
;[protocol manager]
;    DRIVERNAME = PROTMAN$
;
;[netbeui]
;    DRIVERNAME = NETBEUI$
;    BINDINGS = UBNEPS
;    SESSIONS = 32
;    NCBS = 100
;
;[UBNEPS]
;	Note that many of these parameters have default values (which are
; given below under "Comments about UBNEPS parameters"). A parameter need not
; be specified in your PROTOCOL.INI if its default value is satisfactory.
    DriverName = UBNEPS$
;    SlotNumber = 4
    MaxTransmits = 6
;    TransmitBuffers = 2
    ReceiveBufSize = 600
    MaxMulticast = 16
    ReceiveMethod = ReceiveLookahead
    ReceiveBuffers = 64

;  Comments about UBNEPS parameters:
;  --------------------------------
;  DriverName:
;	    This parameter's value must be UBNEPS$, or, in the case where
;	multiple adapters are installed, UBNEPS$ for the first adapter's
;	DriverName, UBNEPS2$ for the second one, UBNEPS3$ for the third, and
;	so on.
;  SlotNumber:			(Min = 1; Max = 8.)
;	    This parameter is needed only when multiple NICps/2 adapters, and
;	multiple instances of the UBNEPS driver, are installed.  Even then,
;	this parameter is required only if it is necessary to override the
;	default association between driver instances and adapters. By default,
;	the UBNEPS driver instance that comes first in PROTOCOL.INI will be
;	associated with the NICps/2 adapter in the lowest numbered slot, the
;	UBNEPS driver instance that comes second will be associated with the
;	NICps/2 adapter in the second lowest numbered slot, and so on.
;  MaxRequests:			(Default = 6; Min = 1; Max = 10.)
;	    This specifies the maximum number of "GeneralRequest"s that can be
;	simultaneously outstanding.
;  MaxTransmits:		(Default = 8; Min = 1; Max = around 400.)
;	    This specifies the number of "TransmitChain"s that the MAC driver
;	guarantees to accept without giving an "OUT_OF_RESOURCE" response.
;  TransmitBuffers:		(Default = 2; other choice = 4.)
;	    This specifies the number of transmit buffers that will be
;	allocated in the adapter's memory.
;  MaxMulticast:		(Default = 16; Min = 0; Max = 255.)
;	    This specifies the maximum number of multicast addresses that can
;	be in effect simultaneously. (NOTE that there's no 's' on the end of
;	this keyword.)
;  ReceiveBufSize:		(Default = 600; Min = 256; Max = 1514.)
;	    This specifies the size of the receive buffers the MAC driver will
;	use. This should be large enough to hold the normal expected received
;	frame. It need not be large enough to hold the largest expected frame.
;	The MAC driver will handle large frames in multiple receive buffers.
;	The value of ReceiveBufSize must be even.
;  ReceiveMethod:	(Default = ReceiveLookahead;
;			 other choices:	ReceiveChain, AdapterBuffered
;			 and		ReceiveChain, HostBuffered
;	    This determines the method of received frame delivery the MAC
;	driver will use. The possibilities are described below. Which one
;	is best to use depends mainly on how the Protocol driver you're using
;	works.  Use number (1) if you don't know anything about the Protocol
;	driver.
;   (1) ReceiveMethod = ReceiveLookahead
;	    When a received frame is available and Indications are On, the
;	MAC driver will call the Protocol driver's "ReceiveLookahead" routine.
;	"ReceiveLookahead" will be given the total length of the frame and a
;	pointer to the "lookahead" data in a receive buffer in the adapter's
;	RAM. The Protocol driver must copy the frame (possibly using the MAC's
;	"TransferData" routine) before returning from "ReceiveLookahead". When
;	"ReceiveLookahead" returns, the MAC driver frees the receive buffers
;	in the adapter's RAM for use in receiving more frames.
;	    This method works well if the Protocol driver is able to copy the
;	frame to the Protocol driver's client's buffers at the time "Receive-
;	Lookahead" is called.  It is also a good method if the Protocol driver
;	always copies frames into internal buffers of its own.
;   (2) ReceiveMethod = ReceiveChain, AdapterBuffered
;	    When a received frame is available and Indications are On, the MAC
;	driver will call the Protocol driver's "ReceiveChain" routine, passing
;	it an "RxBufDescr" which points to the frame in the receive buffers in
;	the adapter's RAM. The Protocol driver can either (a) immediately copy
;	the frame or (b) save a copy of the "RxBufDescr" and leave the frame
;	in the buffers in the adapter's RAM, to be copied at a later time. In
;	case (b), the Protocol driver must copy the frame as soon as possible
;	and call the MAC's "ReceiveRelease" function to make the buffers in
;	the adapter's RAM available for receiving more frames.
;	    This method of operation can be the most efficient.  It's a little
;	better than the "ReceiveLookahead" method if the Protocol driver can
;	copy the frame immediately, because the overhead of calling "Transfer-
;	Data" is avoided.  Also, it has the advantage over "ReceiveLookahead"
;	that the Protocol driver doesn't have to copy the frame immediately --
;	the frame can be left for a short time in the adapter's buffers. But
;	if frames are left in the adapter's buffers long, it will run out of
;	buffers and start losing frames. Also, there's the overhead of calling
;	"ReceiveRelease" to consider.
;   (3) ReceiveMethod = ReceiveChain, HostBuffered
;	    When a received frame is available and Indications are On, the MAC
;	driver will copy the frame from the receive buffers in the adapter's
;	RAM into receive buffers in the Host memory and call the Protocol
;	driver's "ReceiveChain" routine, passing it an "RxBufDescr" which
;	points to the Host-memory buffers.  The Protocol driver can copy the
;	frame immediately or leave it in the Host-memory buffers.  It must
;	eventually call the MAC driver's "ReceiveRelease" routine to free the
;	Host-memory buffers for reuse.  The buffers in the adapter's RAM are
;	made available for receiving more frames as soon as "ReceiveChain"
;	returns.
;	    In this mode, the MAC driver allocates receive buffers in the Host
;	memory.  These buffers are allocated at driver INIT time. Their number
;	and size are determined by the "ReceiveBuffers" and "RcvBufSize" para-
;	meters.  The only advantage of this mode is that in it the MAC driver
;	provides a possibly large amount of long-term frame buffering in which
;	a Protocol driver can leave received frames until it can deliver them
;	to its clients.  This advantage comes at the cost of the space devoted
;	to the Host-memory buffers.  This is an inefficient mode if the
;	Protocol driver always copies frames into its own internal receive
;	buffers or if it can quickly copy frames from the adapter's buffers to
;	its client's buffers.
;  ReceiveBuffers:		(Default = 32; Min = 16; Max = 512.)
;	    This specifies the number of receive buffers that the MAC driver
;	will allocate in the Host memory.  This parameter is meaningful only
;	if "ReceiveMethod = ReceiveChain, HostBuffered" is specified.  For
;	other values of "ReceiveMethod", no receive buffers will be allocated
;	in the Host memory -- the "ReceiveBuffers" parameter will be ignored.
;  PermanentAddr:	The value is a string of 12 ASCII hexadecimal digits,
;			for example:	PermanentAddr = "00DD01AABBCC"
;	    This parameter provides a way to override the "Permanent Station
;	Address" that's built into the adapter's ROM. Note that this parameter
;	is normally not needed, and shouldn't be used.  The NDIS specification
;	strongly discourages configuring the "Permanent Station Address".
;
;  How Much Host Memory UBNEPS Uses
;  --------------------------------
;	   You can compute the amount of PC memory UBNEPS will use. It depends
;	on the "ReceiveMethod" you select and on the values you choose for the
;	"MaxRequests", "MaxTransmits", "MaxMulticast", "ReceiveBuffers", and
;	"ReceiveBufSize" parameters.  The total space used will be the sum of
;	the following five items.
;   (1)	For driver code and data:  10210 (2566 data + 7644 code)
;   (2) For request queueing:	   16 + MaxRequests * 22
;   (3)	For transmit queueing:	   16 + (MaxTransmits - TransmitBuffers) * 146
;   (4)	For multicast addresses:    4 + (MaxMulticast * 16)
;   (5)	For receive buffers:	   16 + ReceiveBuffers * (ReceiveBufSize + 8)
;	Item (5) does not apply unless you use "ReceiveMethod = ReceiveChain,
;	HostBuffered".  Item (3) does not apply if the value of "MaxTransmits"
;	is less than or equal to the value of "TransmitBuffers".
;	    The total you compute may not be exactly correct but it should be
;	close.  The reasons for inexactness are: (a) the value for item number
;	(1) will vary with different versions of the drivers; and (b) the
;	other items may take up a little more space than the formulas imply,
;	because of the need to allocate buffers and other data structures at
;	doubleword-aligned or paragraph-aligned boundaries.
;	    Under DOS, all the space used by the driver is allocated in one
;	contiguous piece.  It will be in "conventional" memory (that is, in
;	the first 640K) if the driver is loaded by a normal "DEVICE=" line in
;	CONFIG.SYS, or in "upper" memory (above 640K) if the driver is loaded
;	by "DEVICEHIGH=" or by "LOADHI".  Note that if the total memory used
;	is large (because of a large value for item (5)), there may not be
;	room to load the driver into "upper" memory.
;	    Under OS/2, item (1) is allocated in low memory, and the other
;	items are allocated in high memory if possible.
