Path: utzoo!utgpu!watmath!clyde!ima!spdcc!husc6!ddl
From: ddl@husc6.harvard.edu (Dan Lanciani)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: CMU PC/IP WD8003 driver
Message-ID: <690@husc6.harvard.edu>
Date: 26 Nov 88 23:11:59 GMT
References: <Nov.21.22.46.50.1988.904@dorm.rutgers.edu> <686@husc6.harvard.edu> <Nov.25.21.14.10.1988.7198@dorm.rutgers.edu>
Organization: Harvard University, Cambridge MA
Lines: 115

In article <Nov.25.21.14.10.1988.7198@dorm.rutgers.edu>, dpz@dorm.rutgers.edu (David P. Zimmerman) writes:

| Yes, I did use CUSTOM.EXE to set the card's base memory address in
| NETDEV.SYS.  I set the base I/O address to 0x0360, the base memory
| address to 0xD0000 (which shows up as 0,D), the xmit and recv DMA
| channels to 0, and the interrupt vector to 5.  Every jumper I could
| find on the card is set correctly.  Theoretically, the PC/IP WD8003
| library should be delving into the hardware to set the base memory
| address on its own - i.e., you don't muck with jumpers for that.

	Ah, that address should be D0000000, the hex representation
of a far pointer to D000:0000.  I should probably note that in the
custom menu...

| I got the new NETDEV.SYS to work - but you guys may want to note
| something.  I was using
| 
| 	device=d:\pcip\obj.4d\netdev.sys
| 
| in my CONFIG.SYS and nothing worked.  CUSTOM.EXE spat out
| 
| 	Error opening netcust.sys: No such file or directory
| 
| and all the network programs said
| 
| 	Error: open failed for netcust
| 	Check for improper NETDEV.SYS installation
| 
| When I put
| 
| 	device=d:\pcip\obj.4d\netdev.sys 1
| 
| in my CONFIG.SYS, suddenly birds are singing and flowers are blooming.
| Well, mostly.  Anyway, I can play with the NETCUST1: (but not the
| NETCUST: !) device via CUSTOM.EXE, have the software find it, etc.
| I end up having to set NETCUST=NETCUST1 in my AUTOEXEC.BAT.
| 
| What really blows my mind is the minuscule differences between the old
| NETDEV.ASM and the new one.  I've come to the preliminary conclusion
| that what you guys think you are getting isn't really what you're
| getting.  The only significant difference between the old and new
| versions is in the parsing of the command line ([si]*).  I stared at
| the code for a while (learning 8088 assembly along the way) and
| followed the logic.
| 
| The differences in the parsing start when you hit a space.  The old
| version will skip all the characters until a space, skip that space,
| and take the character after it as the network device number if the
| character was 0x20 or greater.  Otherwise it will return a space as
| the interface number.  The new version will skip all the characters
| until a space, skip all the spaces, then take the next character
| unconditionally.  Additionally, and most importantly, both versions
| will return a space as the interface number if they didn't find a
| space on the command line (i.e., you had "device=foo<cr>").
| 
| Both algorithms *should* work if MSDOS is doing the expected thing
| with the command line.  I claim that I _shouldn't_ be seeing the
| effects that I'm seeing, and that MSDOS is slapping one or more spaces
| onto the end of the
| 
| 	device=d:\pcip\obj.4d\netdev.sys
| 
| line.  Then, the new version of NETDEV.SYS would skip the space(s) and
| unconditionally return the CR as the interface number, *not* a space!
| The old version would do the "right" thing, which is to end up
| returning a space.  My bugfix would be to just keep using the old
| version of NETDEV.ASM, unless someone has an emotional attachment to
| the new version.  I don't see any technical reason to have mucked with
| it.

	The technical reason to "muck" with it is that the old routine
doesn't work with DOS 3.3, always ignoring its argument.  Of course,
I failed to test the new routine with DOS <= 3.1 and no argument.  If
someone would like to tell me exactly what various versions of DOS pass
here, I'll fix it...

| 
| What setup do you guys have your WD8003 stuff running successfully on?
| I'm bashing on a 5M Compaq 386/20, 360M disk in 12 partitions, a
| WD8003 (of course :-), and a VGA card/monitor.  I'm using MSDOS 3.3x,
| MSC 5.0 and MASM 5.0.
| 
| Incidentally, I had to hack both versions of NETDEV.SYS, new and old,
| due to what I think is an OBOB in MASM 5.0.  Both instances of
| 
| 	mov	es:status[bx],00100H
| 
| became
| 
| 	mov	WORD PTR es:status[bx],00100H
| 
| If I tried using 00101H as a test, it compiled fine, but using 00100H
| made it complain and die bitterly.  00099H to the assembler is,
| understandably, not obvious whether it should be a byte or a word, but
| 00100H is most certainly a word.
| 
| Also, MSC 5.0 made me put some /NOE flags into the link phases of some
| of the makefiles, specifically monitor.4d, custom.4d, netwatch.4d,
| term.4d, and tn.4d.  The linker says:
| 
| 	d:\pcip\lib\[argle].LIB(_wbyte.c) : error L2044: __wbyte :
| 	symbol multiply defined, use /NOE
| 
| So I did :-).  [argle] is different libraries at different time - for
| TERM it is H194D, for CUSTOM it is NET4D.  I'm not sure if this would
| have anything to do with my WD8003 problems.
| 
| Also also, \srccmd\monitor\monitor.c needed a ; on line 642 for MSC 5.0.

	Yup, I know about the problems with 5.0 versions of C and MASM.
One of these days I'll grit my teeth and "fix" them.  Now that /NOE
is described in the manual and I can stop calling it /NOERROR :)

				Dan Lanciani
				ddl@harvard.*