home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / lan / drivrs30 / readme.503 < prev    next >
Text File  |  1989-02-13  |  6KB  |  124 lines

  1. README.503
  2. 14 Feb 89
  3. Bob Clements, K1BC
  4.  
  5. This is the README file that goes with the 3C503 device driver,
  6. 3C503.ASM and 3C503.COM.
  7.  
  8. I wanted to include this file for two reasons:
  9.    1) to give credit where credit is due, and
  10.    2) to say something about this implementation's details.
  11.  
  12. CREDIT WHERE CREDIT IS DUE:
  13.  
  14. The ancestry of this driver is as follows.  The effort was inspired
  15. by Phil Karn's TCP/IP implementation, NET.EXE.  Phil included a
  16. built-in driver for the 3C501 in early versions of NET, up to around
  17. version 871225.30 or so.  
  18.  
  19. I wrote a driver (in C) for the WD8003E which I released in
  20. version 871225.25.EW.  I based this on technical information which
  21. my dealer, Ken Hahn of Micros Unlimited in Woburn MA (a 3-Com
  22. network distributor), was able to get from Western Digital after
  23. some effort.  Credit to Ken and to Western Digital.
  24.  
  25. Shortly after that, Phil saw the need to support more devices without
  26. modifying NET.EXE and he decided to do it by way of the "Packet
  27. Driver" specification publicly promoted by FTP Software of 
  28. Cambridge MA, to whom we owe due credit, too.
  29.  
  30. Russ Nelson at clarkson.edu began implementing and collecting
  31. drivers written to that specification, including a derivative of
  32. Phil's 3C501 driver.  Russ wrote the outer levels of the driver
  33. to meet the FTP Software spec.  Credit to Russ for that and for
  34. the job of collecting other drivers to go with it.
  35.  
  36. I rewrote the built-in C version of the WD8003E driver in 
  37. assembler, fitting it into Russ's structure (as a TSR), 
  38. and released it back to Russ for inclusion in his collection.
  39.  
  40. I wanted to write a version for the 3-Com 3C503 because the 3C501
  41. was continually rumored to be becoming obsolete.  Further, since
  42. it uses the same National DS8390 controller chip as the WD8003E,
  43. I figured it couldn't be TOO different.  Ken and I had been unable
  44. to get programming info for the 3C503 through sales channels or
  45. usenet.  I lamented this fact publicly in early December on usenet.
  46. 3-Com saw the note and immediately provided the necessary info
  47. to me.  They sent me a pre-publication draft of the 3C503's
  48. technical manual and some sample code for a different environment.
  49. Credit to 3-Com in the persons of Jack Moses and Eric Siegel.
  50.  
  51. After a delay due to vacation (K1BC/KH6), winter lethargy and
  52. work schedules, I finally got around to writing the driver in
  53. February 1989.  Sure enough, it wasn't TOO different from
  54. the WD8003E driver.  But see the next section.
  55.  
  56. To all the above named persons, "Thank you".
  57.  
  58.  
  59. DETAILS ABOUT THIS IMPLEMENTATION:
  60.  
  61. The 3C503 is rather versatile.  It allows you to move packets to/from
  62. the card in three ways:  1) By a shared memory buffer;  2) By using
  63. a DMA channel of the PC bus;  3) by I/O instructions per byte or word.
  64. As it comes from the factory, the card has the shared memory jumper
  65. set to "disabled".  This probably prevents phone calls from people
  66. who have address conflicts with their video cards or disk bootstraps.
  67. 3-Com's software includes code to handle all three cases, depending
  68. on the rest of the configuration.
  69.  
  70. I chose to implement ONLY method 1 above for this initial version
  71. of the driver.  Not only is this the fastest transfer method but
  72. it is the method used for the WD8003E driver that I did before.
  73. So I had less work to do.  You MUST set the shared memory to one of
  74. its four possible enabled addresses.  Pick one that doesn't conflict
  75. with your other hardware.  The segment numbers available are:
  76. c800, cc00, d800 and dc00.  The driver can read your selection
  77. from the card, so you don't have to tell it.
  78.  
  79. The 3C503 has jumpers for the above memory addresses and for the I/O
  80. port addresses.  It occupies a block of 16 addresses at one of a
  81. number of jumperable bases.  The default is 300.  You can change
  82. it if you have to.  Supply the actual address as an argument
  83. when you start the driver.
  84.  
  85. The 3C503 interrupt level is programmable.  No jumpers.  Only
  86. levels 2,3,4 and 5 are supported by the hardware.  Tell the driver
  87. what level you want as an argument when you start the driver.
  88. The default level is two.
  89.  
  90. I start the driver on my system with the following line:
  91.     C:>  3c503 0x7e 2 0x300
  92. which means "Install on software interrupt 7E (for NET.EXE to use),
  93. use interrupt level 2, and find the board at ports 300-30F".
  94.  
  95.  
  96. There are differences between the way WD's and 3-Com's software 
  97. handle the DS8390.  I changed some of them over to 3-Com's way
  98. for this driver and left some as I had them in the WD driver.
  99. So far, they seem to be working OK.  For one thing, they treat
  100. the "boundary" register differently.  Details available on request.
  101.  
  102. 3-Com also includes a lot of garbled-packet detection in their
  103. driver, based on their experience of failures of the DS8390
  104. under heavy load.  They describe some pretty bizarre things.
  105. I have not included that logic in this driver, since the IP and
  106. TCP checksums should save you in the applications I am
  107. writing for.
  108.  
  109. So my point is that this driver is not as complete an implementation
  110. as the one 3-Com provides for their network systems.  I take the
  111. blame for these compromises.
  112.  
  113. One last note:  This driver, and the WD8003E driver, mask OFF all
  114. the multicast addresses.  They will accept frames addressed to
  115. the broadcast address and to this station's hardware address,
  116. but no Multicast frames.  (Yes, BBN's ethernet has a lot of
  117. DECnet devices...)  A later version of these drivers may add
  118. support for enabling/disabling multicasts.  At present, NET.EXE
  119. doesn't make any use of them.
  120.  
  121.  
  122. Bob Clements,  K1BC,  clements@bbn.com,  rcc@k1bc.UUCP
  123.  
  124.