X-Authentication-Warning:	delorie.com: mail set sender to opendos-bounces using -f
Message-ID:	<B028C6AEE47AF14AADF1F1EA2486297208DB48@zet02.meters.com.au>
From:	"da Silva, Joe" <Joe DOT daSilva AT ampymetering DOT com DOT au>
To:	"'opendos'" <opendos AT delorie DOT com>
Subject:	RE: NE2000 driver, DPMS (was: PNW, etc.)
Date:	Tue, 1 Feb 2005 10:54:26 +1100
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2653.19)
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id j0VNo3lV010515
Reply-To:	opendos AT delorie DOT com

Please see below ...

Joe.

> -----Original Message-----
> From:	Michal H. Tyc [SMTP:mht AT bttr-software DOT de]
> Sent:	Saturday, January 29, 2005 6:06 AM
> To:	opendos AT delorie DOT com
> Subject:	Re: PNW vs NetWare (and NE2000 drivers, Client32)

> > So, it seems there is a bug (actually, two bugs, as you
> > will see) with the VLM ODI NE2000 driver. It performs
> > some sort of test to check if the network is correctly
> > terminated, but then misinterprets this as a hardware
> > configuration conflict. Furthermore (and this is the second
> > bug I alluded to), it then neglects to restore the interrupt
> > vector for the card's IRQ, even though it isn't loading. As
> > a result, attaching a cable or terminating resistor to the
> > card's BNC connector will subsequently invoke a call to
> > this interrupt vector, resulting in a hung PC - nasty!
> 
> Interesting... I'm using an NE2000 clone (Genius IIRC) in one
> machine and it was happening from time to time that the cabling
> was broken somewhere outside my room, or that I had to disconnect
> the cable to use it with another machine. The driver loaded and
> I didn't experience any problems of this kind, just observed
> a noticeable delay during startup.
> 
	[Joe da Silva]  

	Interesting indeed. Well, since my original posting, I've
	acquired a NE2000 clone (no brand name, model no. or
	FCC ID, so no way to find configuration software for it;-).

	Although you didn't say explicitly, I presumed you tried
	the V2.10 driver, as supplied with DR-DOS 7.XX PNW
	(as you will recall, the older V1.XX driver didn't exhibit
	the above problem).

	So, I did a quick check last night with the NE2000 clone
	and the V2.10 driver - no "hardware configuration conflict"
	error with the network disconnected! It seems this problem
	only occurs with an original Novell NE2000 card, not with
	clones (well, at least, not with this or your clone card). It
	appears Novell either never tested the driver with an original
	NE2000 card or didn't try it with the network disconnected
	(to ensure the driver didn't misbehave as above).

	From a bit more experimentation, my theory is that the
	V2.10 driver performs some sort of test to see if the IRQ
	setting of the card is correct. An original NE2000 card
	doesn't seem to generate an interrupt if unconnected to
	a network (ie. unterminated), so the driver assumes the
	IRQ is wrong. It then fails to restore the interrupt vector.


> -----Original Message-----
> From:	Michal H. Tyc [SMTP:mht AT bttr-software DOT de]
> Sent:	Saturday, January 29, 2005 6:05 AM
> To:	opendos AT delorie DOT com
> Subject:	Re: protman.dos and DR DOS

> > Of the various components used in PNW, only the server component
> > seems to make use of DPMS, so if you aren't using DPMS with
> > any other driver/TSR, don't bother loading it for a client-only boot.
> 
> NWCACHE and NWCDEX are the most commonly used DPMS clients.
> 
	[Joe da Silva]  

	Yes, although since Novell created DPMS, it's a shame
	they didn't use it more extensively with their VLM/ODI
	stuff, which would certainly have benefited from it.

	NWCACHE and NWCDEX are indeed the main DPMS
	clients, but if you need EMS for other applications anyway,
	you have the option to use this for them instead of DPMS.





-------------------------------------------------------------------------------------------------------
This email (including any attachment) is confidential. If you are not the intended recipient,
you must not disclose or use this email or the information contained herein for any purpose.
If you have received this email in error, please immediately advise us by reply and delete this email.
This email may not be altered, forwarded or re-issued without our consent. AMPY Email Metering is
not responsible for any changes made to this email or the effect of any changes on the email’s meaning.
It is the responsibility of the recipient to scan this email for viruses and faults prior to processing.
AMPY Email Metering shall not be liable for any loss or damage caused by this email from transmission,
viruses, faults or the use of data accompanying this message. AMPY Email Metering reserves all its
rights, including copyright,in this email.

- Raw text -