Re: ELKS Networking
Hi Dan. >>> I am a programmer and would like to help out I can. I have >>> a 4 computer ethernet local area network at home I would be >>> happy to test out any network drivers you come up with. I >>> would also be willing to help on the coding if needed. >> The obvious question is what network adapters do you use? > 3Com Etherlink and Etherlink II (3c501 and 3c503). I believe the people currently working in this area are looking at either NE1K/NE2K clones or the WD8003 card, so if you plan on developing drivers for those cards, I expect you'll be welcomed. > I guess I have some Arcnet cards toothough I don't see > arcnet in Elks' near future :) If nobody develops support for it, it won't be, but once again, a developer with the hardware is likely to be welcomed. Best wishes from Riley. * Copyright (C) 1999, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
Re: ELKS Networking
On Tue, 23 Nov 1999, Riley Williams wrote: > Hi Ed. > > > I am a programmer and would like to help out I can. I have a 4 > > computer ethernet local area network at home I would be happy to > > test out any network drivers you come up with. I would also be > > willing to help on the coding if needed. > > The obvious question is what network adapters do you use? 3Com Etherlink and Etherlink II (3c501 and 3c503). I guess I have some Arcnet cards toothough I don't see arcnet in Elks' near future :) Dan
Re: ELKS Networking
Hi Ed. > I am a programmer and would like to help out I can. I have a 4 > computer ethernet local area network at home I would be happy to > test out any network drivers you come up with. I would also be > willing to help on the coding if needed. The obvious question is what network adapters do you use? I have NE2000 clones myself, but there's plenty of non-NE2k cards around nowadays, and the more diversity we have, the better in that we have more people to test (or even code) the various drivers. > -- > Are you paying for internet access? Why? > * NetZero - http://www.NetZero.com > * AltaVista - http://www.AltaVista.com > > Chat live online FREE! with AOL Instant Messenger without > an AOL ISP account. > * Get your FREE! account - http://www.aol.com/AIM > > Have you been to my home page lately? > * Autologon - > http://www.geocities.com/SiliconValley/Hills/5230/index.htm > > Get a FREE! POP mail account > * SoftHome - http://www.softhome.net > > Contact me. > * My AOL/IM Screen Name is - EdJohnson99 > * My e-mail address - mailto:[EMAIL PROTECTED] Do you really need to attach that much junk to your emails? Best wishes from Riley. * Copyright (C) 1999, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
ELKS Networking
I am a programmer and would like to help out I can. I have a 4 computer ethernet local area network at home I would be happy to test out any network drivers you come up with. I would also be willing to help on the coding if needed. -- Are you paying for internet access? Why? * NetZero - http://www.NetZero.com * AltaVista - http://www.AltaVista.com Chat live online FREE! with AOL Instant Messenger without an AOL ISP account. * Get your FREE! account - http://www.aol.com/AIM Have you been to my home page lately? * Autologon - http://www.geocities.com/SiliconValley/Hills/5230/index.htm Get a FREE! POP mail account * SoftHome - http://www.softhome.net Contact me. * My AOL/IM Screen Name is - EdJohnson99 * My e-mail address - mailto:[EMAIL PROTECTED]
Re: ELKS Networking: TCP/IP?
Brian D Chase wrote: > I don't want to seem overly abrasive here... but in my totally speculative > opinion... THERE'S NO WAY IN [HECK] you could do that in 2K of memory! You'd be surprised--16-bit Intel assembler is pretty compact. > if you're using lots of self-modifying code, I don't think it's possible. Self-modifying code probably wouldn't help. Self-modifying code is usually used either to workaround a limitation of a processor or to improve performance. > There's a certain theoretical limit of the functionality that can be > implemented in a given amount of space, and I think that what it takes to > run SLIP/IP/ICMP/UDP exceeds what can be done in 2K. It's quite possible. Running TCP would be a bit more difficult, esp. if you wanted to implement a sliding-window protocol. I would find it very difficult to do with 36 bytes of memory. I won't even begin to discuss the joys I had trying to process IP packets in BASIC where BASIC has a maximum string length of 255 bytes. Take a look at netbooting code. It implements 802 encapsulation, a network adapter device driver, IP, UDP, TFTP, BOOTP/DHCP protocol modules, and a kernel loader all in around 8K of memory on a PROM.
Re: ELKS Networking: TCP/IP?
> Instead of using usual buffers for each layer, I decode all data on the fly. > It is easy since we have a position pointer and can make a decision as each > byte arrives. Thats a lot like IP stacks for DSP chips (real men also do IP routing in DSPs 8)). > For the disbeliever: you can see the thing on "http://www.ipsi.nu". I can believe it is possible. That you did it is most impressive. Thats probably harder than ethernet where you can use the packet buffer on the card for your thinking space. Alan
Re: ELKS Networking: TCP/IP?
>Stefan Pettersson > >I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program >and 36 bytes RAM (not KILObytes) including operating system and device >drivers, >that fits in a PIC 16F84. > >So it isn't a problem to implement networking in limited memory. Not to spoil anybodys fun, but with a PIC all instructions fit in less than 16bits (all memory available can be addressed in just one instruction) and that is considered one unit of memory. RAM is still RAM in that one byte is and always should be 8bits and addressed as such and still only takes one instruction. PIC chips are beasts of all speed and i/o think of an Intel type chips as pigs wallowing in the mud and PIC chips as horses galloping at full speed, there is no competion. Besides we all know Micro$oft missed the course on how to trim the fat! I am no expert, but I do believe what is said above is at least possible. I am the nut case that said elks could run on a PIC chip a while back, I am still woking on it and still believe the possibilities. Time Marches On... [EMAIL PROTECTED]
Re: ELKS Networking: TCP/IP?
On 23-Apr-99 Alistair Riddoch wrote: > =?ISO-8859-1?Q?Fr=E9d=E9ric_Renet?= writes: >> > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program >> > and 36 bytes RAM (not KILObytes) including operating system and device >> > drivers, >> > that fits in a PIC 16F84. >> > >> > So it isn't a problem to implement networking in limited memory. >> > >> Is it possible to have a look on your code ? > > I too would be very interested in looking at this code. I suspect it is in > assembler, and very PIC specific, but interesting anyway. My understanding > is that UDP is a very thin layer on top of IP, and does not require much > buffering, whereas implementing TCP is altogether more difficult. Well, I can't release the source since it is made for a proprietary project, but I can talk about it. I have intentionally left out TCP since it requires a lot of different states and timeouts in each of them. The buffering and windowing is not as much problem, since you can turn off windowing and tell the other end how much buffers you have. The code is written entirely in Microchip assembler. (Real men program everything in assembler :-) Microchip assembler is quite compact and special, but the real problem in this project is to use 36 bytes of RAM as 1: IP-buffers 2: General data for the whole system 3: Credit card buffer (iso track 2 alone is 40 bytes), at the same time! The solution is to compress card data and IP data. Instead of using usual buffers for each layer, I decode all data on the fly. It is easy since we have a position pointer and can make a decision as each byte arrives. For the disbeliever: you can see the thing on "http://www.ipsi.nu". (and it seems that I have to install a unit so you all can ping it :-) Not much of this technology is applicable to elks, but the point is: much can be done with limited resources if you use your thinking organ. -- Stefan Pettersson Voice +46-70-5933800 Kanard AB [EMAIL PROTECTED] ([EMAIL PROTECTED]) Fax +46-221-50180 Vretberga finger [EMAIL PROTECTED] for my public key S-732 96 ARBOGA "What a scary world it must be, for those with no UID:GID" /OZ9ABN
Re: ELKS Networking: TCP/IP?
On Fri, 23 Apr 1999, Brian D Chase wrote: > I don't want to seem overly abrasive here... but in my totally speculative > opinion... THERE'S NO WAY IN HELL you could do that in 2K of memory! You've never seen etherboot, have you? Hardware driver, IP layer, UDP layer, tftp layer, bootp (or dhcp), pretty menu system and boot loader, in 8k. It's not impossible. etherboot fits the whole lot into 8k with gcc, and 6k with bcc, so by trimming some of the fat (such as kernel loader, and ANSI graphics support), 2k is quite achievable. > I can accept being wrong about that, but it would require solid proof. Is etherboot solid enough proof? http://www.slug.org.au/etherboot/ if you want to see the actual results yourself. Davey
Re: ELKS Networking: TCP/IP?
Stefan Petterson wrote: > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program > and 36 bytes RAM (not KILObytes) including operating system and device drivers, > that fits in a PIC 16F84. Brian D Chase wrote: > I don't want to seem overly abrasive here... but in my totally speculative > opinion... THERE'S NO WAY IN HELL you could do that in 2K of memory! -I write: Sorry Stefan, but I must agree with B.D.Chase here. I find this very hard to beleive. (Did you *really* mean 2036 bytes totally, and not just for the program code and its internal vars/stack?) I asked a couple of friends that code a lot, and they said the same thing. But, please don't feel offended Stefan. I'd really like you to proved me wrong :) Lev väl Stefan, and peace to the world. --Tobias Ekbom.
Re: ELKS Networking: TCP/IP?
On Fri, 23 Apr 1999, Stefan Pettersson wrote: > On 19-Apr-99 Tobias Ekbom wrote: > > What I wanted was a discussion about TCP/IP in computers with very > > limited memory. > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program > and 36 bytes RAM (not KILObytes) including operating system and device drivers, > that fits in a PIC 16F84. > > So it isn't a problem to implement networking in limited memory. I don't want to seem overly abrasive here... but in my totally speculative opinion... THERE'S NO WAY IN HELL you could do that in 2K of memory! I don't believe it. I've great faith in the ability of competent embedded systems programmers to achieve amazing feats of compact coding. But even if you're using lots of self-modifying code, I don't think it's possible. There's a certain theoretical limit of the functionality that can be implemented in a given amount of space, and I think that what it takes to run SLIP/IP/ICMP/UDP exceeds what can be done in 2K. I can accept being wrong about that, but it would require solid proof. -brian. --- Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!
Re: ELKS Networking: TCP/IP?
On Fri, 23 Apr 1999, Stefan Pettersson wrote: > On 19-Apr-99 Tobias Ekbom wrote: > > --Murn wrote: > >> On Sun, 18 Apr 1999, Tobias wrote: > > > > What I wanted was a discussion about TCP/IP in computers with very > > limited memory. > > > > --Tobias Ekbom > > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program > and 36 bytes RAM (not KILObytes) including operating system and device drivers, > that fits in a PIC 16F84. > :would like a copy of it. Will
Re: ELKS Networking: TCP/IP?
=?ISO-8859-1?Q?Fr=E9d=E9ric_Renet?= writes: > > > > > > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program > > and 36 bytes RAM (not KILObytes) including operating system and device drivers, > > that fits in a PIC 16F84. > > > > So it isn't a problem to implement networking in limited memory. > > > Is it possible to have a look on your code ? > I too would be very interested in looking at this code. I suspect it is in assembler, and very PIC specific, but interesting anyway. My understanding is that UDP is a very thin layer on top of IP, and does not require much buffering, whereas implementing TCP is altogether more difficult. Al
Re: ELKS Networking: TCP/IP?
> > I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program > and 36 bytes RAM (not KILObytes) including operating system and device drivers, > that fits in a PIC 16F84. > > So it isn't a problem to implement networking in limited memory. > Is it possible to have a look on your code ? Thnks. Frédéric Renet Mipsys 19c Av des Indes 91969 Les Ulis (France) Tel: +33 1 64 86 26 00 Fax: +33 1 64 86 26 09
Re: ELKS Networking: TCP/IP?
On 19-Apr-99 Tobias Ekbom wrote: > --Murn wrote: >> On Sun, 18 Apr 1999, Tobias wrote: > > What I wanted was a discussion about TCP/IP in computers with very > limited memory. > > --Tobias Ekbom I have written a SLIP/IP/ICMP/UDP-stack that fits in 2000 bytes program and 36 bytes RAM (not KILObytes) including operating system and device drivers, that fits in a PIC 16F84. So it isn't a problem to implement networking in limited memory. -- Stefan Pettersson Voice +46-70-5933800 Kanard AB [EMAIL PROTECTED] ([EMAIL PROTECTED]) Fax +46-221-50180 Vretberga finger [EMAIL PROTECTED] for my public key S-732 96 ARBOGA "What a scary world it must be, for those with no UID:GID" /OZ9ABN
Re: ELKS Networking: TCP/IP?
Hi Tobias. > The computers I had in mind was those with (say) 128 to 256 kb > of RAM; x86 or not. (Running an Atari Portfolio with TCP/IP in > Linux-8086, for example :) > I had already heard that 512 kb was enough ta handle TCP/IP, but > I find it hard to beleive that AT's would run the software > mentioned in 128 kb of total RAM. > (At speeds higher than 2400 bits/s, anyways. Remember that > Linux-8086 probably uses more memory than early DOS versions). I can't speak for higher speeds, but I once ran a SLIP link across a 2400 Baud modem on an 8086 with 192k of RAM, so it's certainly possible within that spec. > What I wanted was a discussion about TCP/IP in computers with > very limited memory. But if the discussion about network > capabilities was targeted directly at the standard AT/XT, I > guess there's no need for it. Sorry? It needs to be considered, but I would suspect buffer space to be a bigger constraint on low memory machines. > Anyone ever tried putting ELKS in ROM for computers with tiny > memory? No, but I like the idea. Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking: TCP/IP?
Dan Olson writes: > > > PS. > > Has anyone written a GUI (X or not) that runs under ELKS? > > I have a *tiny* VGA16 GUI function set with bitmapped fonts, written in > > assembler for the 80186. (Part of an OS project called "Mooph OS" that I > > had a year ago) -I am thinking about porting it for 8086 Linux, but > > surely there must be better projects to waste my time with. If there's > > any GUI at all for the ELKS, I'd like to know more about it. Please :) > > > Just a thought, how about porting Linux's VGAlib? > I think it would be more useful to have some kind of framebuffer device to make sure that the hardware is dealt with cleanly, and then use the kmem device to actually write to the framebuffer itself. A thin graphics library could then be written on top of these drivers. Al
Re: ELKS Networking
Hello, just some thoughts: I don't know any public sources for a simple and small TCP/IP stack, portable for ELKS. But eventually the WATTCP programmer libraries (http://www.supro.com/wattcp/wattcp.html) may be of interest for getting some ideas. But instead of development of new NIC drivers - how about porting Crynwr's (http://www.crynwr.com) packet drivers? Bernd-M. Stejskal
Re: ELKS Networking: TCP/IP?
> What I wanted was a discussion about TCP/IP in computers with very > limited memory. > But if the discussion about network-capabilities was targeted directly > at the standard AT/XT, I guess there's no need for it. Sorry? Remember the first "stardard PC" came with 64k of ram, so I don't feal that this discussion is really that bad of an idea. Dan
Re: ELKS Networking: TCP/IP?
> PS. > Has anyone written a GUI (X or not) that runs under ELKS? > I have a *tiny* VGA16 GUI function set with bitmapped fonts, written in > assembler for the 80186. (Part of an OS project called "Mooph OS" that I > had a year ago) -I am thinking about porting it for 8086 Linux, but > surely there must be better projects to waste my time with. If there's > any GUI at all for the ELKS, I'd like to know more about it. Please :) > Just a thought, how about porting Linux's VGAlib? Dan
Re: ELKS Networking
On Mon, 19 Apr 1999, David Murn wrote: > On Sun, 18 Apr 1999, Luke(boo) Farrar wrote: > > > An ne2000 is a lot easier to get hold of than an ne1000 > > I don't know if that statement is entirely true. ne2k is easier because > you can settle for a clone, of which there are LOTS. > > Davey > What I mean is that you can still buy them. They even still make them! Luke(Boo) Farrar.
Re: ELKS Networking: TCP/IP?
Hello world... :) --Murn wrote: > On Sun, 18 Apr 1999, Tobias wrote: > > t> I remembered reading about that older computers didn't have enough > t> memory to handle the TCP/IP stack. > > Oops, I wish I'd known that before I used cutcp on my XT for a year. > > t> -Where the memory limitation is a bigger obsticle than the cpu > t> performance, we could use a fast compression algoritm to compress all > t> the packets in-memory. > > I don't really think this is an issue. Packets aren't supposed to remain > in memory. If you've got a fast enough CPU, you should work on getting > the socket layer getting the packets out of memory as fast as possible, > rather than working out the best way to leave them there. --JueyChong Ong wrote: >>From the perspective of someone who is unfamiliar with the ELKS architecture, >I don't think it should be a problem, since the early versions of >NCSA Telnet for MS-DOS ran on 8088 and 8086-based PCs. ... The computers I had in mind was those with (say) 128 to 256 kb of RAM; x86 or not. (Running an Atari Portfolio with TCP/IP in Linux-8086, for example :) -I had already heard that 512 kb was enough ta handle TCP/IP, but I find it hard to beleive that AT's would run the software mentioned in 128 kb of total RAM. (At speeds higher than 2400 bits/s, anyways. Remember that Linux-8086 probably uses more memory than early DOS versions). What I wanted was a discussion about TCP/IP in computers with very limited memory. But if the discussion about network-capabilities was targeted directly at the standard AT/XT, I guess there's no need for it. Sorry? --Tobias Ekbom PS. Anyone ever tried putting ELKS in ROM for computers with tiny memory?
Re: ELKS Networking: TCP/IP?
At 10:22 PM +0200 4/18/99, Tobias wrote: >Reading the list messages about networking support in ELKS, >I remembered reading about that older computers didn't have enough >memory to handle the TCP/IP stack. >From the perspective of someone who is unfamiliar with the ELKS architecture, I don't think it should be a problem, since the early versions of NCSA Telnet for MS-DOS ran on 8088 and 8086-based PCs. --jc JueyChong Ong[EMAIL PROTECTED]http://www.didi.com Digital Image Design Incorporated"Real tools for Virtual worlds" 72 Spring Street Fl 6Phone: +1 (212) 343 2442 ext. 225 New York NY 10012-4019 US Fax: +1 (212) 343 0440
Re: ELKS Networking: TCP/IP?
On Sun, 18 Apr 1999, Tobias wrote: > I remembered reading about that older computers didn't have enough > memory to handle the TCP/IP stack. Oops, I wish I'd known that before I used cutcp on my XT for a year. > -Where the memory limitation is a bigger obsticle than the cpu > performance, we could use a fast compression algoritm to compress all > the packets in-memory. I don't really think this is an issue. Packets aren't supposed to remain in memory. If you've got a fast enough CPU, you should work on getting the socket layer getting the packets out of memory as fast as possible, rather than working out the best way to leave them there. > Has anyone written a GUI (X or not) that runs under ELKS? There is a program called Mini-X, which is designed to run under Minix, which I'm attempting to port to ELKS. XFree has no chance of getting ported, although I did port SuperProbe. Davey
Re: ELKS Networking: TCP/IP?
Hello. Reading the list messages about networking support in ELKS, I remembered reading about that older computers didn't have enough memory to handle the TCP/IP stack. (And we do want TCP/IP, don't we?) So, before continuing the discussion about "Which network card should be supported first", perhaps we should solve the problem with handling the connections and packet streams under extreme memory (& cpu) limitations. I haven't done much network programming, so I can't really say I know what I'm talking about. %) But I still want to share some of my thoughts on optimization for the sake of the debate. -Please forgive my ignorance... -Imho, the types of services should be as limited as possible. (Surprised?? :) -We could probably building (some of) the layers together to do optimization. -As much of the network functions as possible (and probably a lot) could be built in the manner that modems connect to ur ISP under Linux, for instance. With settings of "Expect"s and "Send"s. (and if-then's) -Where the memory limitation is a bigger obsticle than the cpu performance, we could use a fast compression algoritm to compress all the packets in-memory. -Assuming that there is some kind of disk device connected to the computer, packets in a chain could be swapped to disk (copied to disk, "just-in-case"), making it possible to handle packet chains to big to fit in memory. --Tobias Ekbom. PS. Has anyone written a GUI (X or not) that runs under ELKS? I have a *tiny* VGA16 GUI function set with bitmapped fonts, written in assembler for the 80186. (Part of an OS project called "Mooph OS" that I had a year ago) -I am thinking about porting it for 8086 Linux, but surely there must be better projects to waste my time with. If there's any GUI at all for the ELKS, I'd like to know more about it. Please :)
Re: ELKS Networking
Hi Luke. >> 2. Both NE1000 and NE2000 cards come in the following >> varieties (most of which I have examples of): >> 1. BNC connector for coax segments at 10 Mbps. >> 2. RJ45 connector for CAT-5 cable at 10 Mbps. >> 3. 15-pin D-type connector for whatever suits. >> 4. Any two of the above, selected by jumpers. >> 5. Any two of the above, auto-detected. >> 6. All three of the above, auto-detected. >> As a result, your second concern is basically irrelevant. > None of 4 my ne1000's, nor any I have ever seen have RJ-45 > connectors. Want me to send you one? They're easy enough to get hold of round here, as one of the local emporiums has a LARGE box full of them, and stated that they obtained them when actioning an order to upgrade one of the oil companies to a 100 Mbps network... As far as the cards in my collection go, I don't have an NE1k that is RJ-45 only, but I do have one that's both BNC and RJ-45, so I can confirm that combination cards were made. >>> An ne1000 driver can be done later, but to make sure that >>> everybody can join in for now, the more popular the card >>> the better. >> That sort of decision appears to be a geographically based one, >> so may not produce the result you are expecting... > An ne2000 is a lot easier to get hold of than an ne1000 Depends where you are - here, the opposite is true... >>> To start with, I intend to write the driver, and then some code >>> that will tell me when a packet has arrived, if it is for this >>> machine, and what protocol it is using. And I'll go from there. >>> (I haven't read that far ahead ;-) >> Probably a better decision would be to split networking into two >> layers, with the upper layer doing everything that can be done >> without accessing the card itself, and the lower layer doing only >> that which can't be done without accessing the card... > That is what I meant. There is no point at all having some > generic code being re-written. So that when a packet comes in, > the driver passes strait to the function that decides if it is > at the right machine. The whole picture comes in several layers. In that case, there shouldn't be much in the way of problems implementing NE1k's, NE2k's and 3C503's according to what's been said, as all three are apparently based on the same chipset, the 8390. Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
On Sun, 18 Apr 1999, Luke(boo) Farrar wrote: > An ne2000 is a lot easier to get hold of than an ne1000 I don't know if that statement is entirely true. ne2k is easier because you can settle for a clone, of which there are LOTS. Davey
OFF-TOPIC Re: ELKS Networking
On Sat, 17 Apr 1999, Riley Williams wrote: > >>> 1. You refer to an "NE2000" card. Presumably you're aware that > >>>those normally don't work in an XT as they require an AT style > >>>connector and the similar NE1000 card with its XT style > >>>connector has to be used instead. > > My main concern for development is to have a card which: > >Most people can get hold of, or already have. > I can't speak generally, but certainly in this part of Scotland, and > in the south Lincolnshire area of England, clones of both the NE1000 > and NE2000 are easily available. However, according to posts I've seen > on the Linux-Kernel mailing list, NEx000 clone cars are essentially > unknown in the USA, and the varius 3Cxxx cads are the ones that are > easy to get hold of... In my experience, NE1k and NE2k clones are readily available and common here in the USA. They generally run $5-$10 (as low as $3 in quantity,) with older models often given away rather than sold. Old 3-COM 3Cxxx cards are also readily available, but they are often more expensive than NE1k/NE2k clones, and I've heard they usually give better performance (although I've not verified this.) That being said, I doubt that the prices of these old cards will have any affect whatsoever on which drivers are written first for ELKS. [snip]
Re: ELKS Networking
On Sat, 17 Apr 1999, Riley Williams wrote: > Hi Luke. > > >>> 1. You refer to an "NE2000" card. Presumably you're aware that > >>>those normally don't work in an XT as they require an AT style > >>>connector and the similar NE1000 card with its XT style > >>>connector has to be used instead. > > > My main concern for development is to have a card which: > > >Most people can get hold of, or already have. > > I can't speak generally, but certainly in this part of Scotland, and > in the south Lincolnshire area of England, clones of both the NE1000 > and NE2000 are easily available. However, according to posts I've seen > on the Linux-Kernel mailing list, NEx000 clone cars are essentially > unknown in the USA, and the varius 3Cxxx cads are the ones that are > easy to get hold of... > > >Will work with my hub. > > In that case, were you aware of the following: > > 1. The basic difference between an NE1000 card and an NE2000 card > is that the NE1000 ports have to be read in 8-bit chunks, and > the NE2000 ports normally have to be read in 16-bit chunks. > > 2. Both NE1000 and NE2000 cards come in thee following varieties > (most of which I have examples of): > > 1. BNC connector for coax segments at 10 Mbps. > > 2. RJ45 connector for CAT-5 cable at 10 Mbps. > > 3. 15-pin D-type connector for whatever suits. > > 4. Any two of the above, selected by jumpers. > > 5. Any two of the above, auto-detected. > > 6. All three of the above, auto-detected. > > As a result, your second concern is basically irrelevant. None of 4 my ne1000's, nor any I have ever seen have RJ-45 connectors. > > > An ne1000 driver can be done later, but to make sure that > > everybody can join in for now, the more popular the card the > > better. > > That sort of decision appears to be a geographically based one, so may > not produce the result you are expecting... An ne2000 is a lot easier to get hold of than an ne1000 > > To start with, I intend to write the driver, and then some code > > that will tell me when a packet has arrived, if it is for this > > machine, and what protocol it is using. And I'll go from there. > > (I haven't read that far ahead ;-) > > Probably a better decision would be to split networking into two > layers, with the upper layer doing everything that can be done without > accessing the card itself, and the lower layer doing only that which > can't be done without accessing the card... That is what I meant. There is no point at all having some generic code being re-written. So that when a packet comes in, the driver passes strait to the function that decides if it is at the right machine. The whole picture comes in several layers. Luke(Boo) Farrar.
Re: ELKS Networking
On Sat, 17 Apr 1999, Riley Williams wrote: > However, I note that the original post specifically referred to the ne2k > and equally specifically excluded even the ne1k... Sure. In the same way the ne2k driver excludes the 3c503. It's the same basic nic chip, but there are little subblties difference, such as ethernet address being right, and so on. Davey
Re: ELKS Networking
Hi David. >>> An ne1000 driver can be done later, but to make sure that >>> everybody can join in for now, the more popular the card the >>> better. >> That sort of decision appears to be a geographically based one, >> so may not produce the result you are expecting... > Not true at all. All you need, is the 8390 code written. Once > you've got that, it's very very very easy to support the ne2k, > the 3c503 and the wd8003. All of these are available in some > part of the world. If that's how it's done, then I'd agree. However, I note that the original post specifically referred to the ne2k and equally specifically excluded even the ne1k, and my post basically said the same as yours: Make the code as generic as possible, rather than entwine details of a specific card throughout the code... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
On Sat, 17 Apr 1999, Riley Williams wrote: > > An ne1000 driver can be done later, but to make sure that > > everybody can join in for now, the more popular the card the > > better. > > That sort of decision appears to be a geographically based one, so may > not produce the result you are expecting... Not true at all. All you need, is the 8390 code written. Once you've got that, it's very very very easy to support the ne2k, the 3c503 and the wd8003. All of these are available in some part of the world. Davey
Re: ELKS Networking
Hi Luke. >>> 1. You refer to an "NE2000" card. Presumably you're aware that >>>those normally don't work in an XT as they require an AT style >>>connector and the similar NE1000 card with its XT style >>>connector has to be used instead. > My main concern for development is to have a card which: > Most people can get hold of, or already have. I can't speak generally, but certainly in this part of Scotland, and in the south Lincolnshire area of England, clones of both the NE1000 and NE2000 are easily available. However, according to posts I've seen on the Linux-Kernel mailing list, NEx000 clone cars are essentially unknown in the USA, and the varius 3Cxxx cads are the ones that are easy to get hold of... > Will work with my hub. In that case, were you aware of the following: 1. The basic difference between an NE1000 card and an NE2000 card is that the NE1000 ports have to be read in 8-bit chunks, and the NE2000 ports normally have to be read in 16-bit chunks. 2. Both NE1000 and NE2000 cards come in thee following varieties (most of which I have examples of): 1. BNC connector for coax segments at 10 Mbps. 2. RJ45 connector for CAT-5 cable at 10 Mbps. 3. 15-pin D-type connector for whatever suits. 4. Any two of the above, selected by jumpers. 5. Any two of the above, auto-detected. 6. All three of the above, auto-detected. As a result, your second concern is basically irrelevant. > An ne1000 driver can be done later, but to make sure that > everybody can join in for now, the more popular the card the > better. That sort of decision appears to be a geographically based one, so may not produce the result you are expecting... > To start with, I intend to write the driver, and then some code > that will tell me when a packet has arrived, if it is for this > machine, and what protocol it is using. And I'll go from there. > (I haven't read that far ahead ;-) Probably a better decision would be to split networking into two layers, with the upper layer doing everything that can be done without accessing the card itself, and the lower layer doing only that which can't be done without accessing the card... On this basis, the easiest inteerface to implement would be the loopback interface, which doesn't need any card at all. The low-level 'driver' for it would simply take whatever comes in to it on one side and return the same as having arrived on the other. Also, the advantage of splitting the code up as stated is that extra interface cards can easily be added by just writing the low-level driver routines, and the high-level routines, if done correctly, will need no tweaks at all... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
> On Wed, 14 Apr 1999, Riley Williams wrote: > > > 1. You refer to an "NE2000" card. Presumably you're aware that those > > normally don't work in an XT as they require an AT style connector > > and the similar NE1000 card with its XT style connector has to be > > used instead. My main concern for development is to have a card which: Most people can get hold of, or already have. Will work with my hub. An ne1000 driver can be done later, but to make sure that everybody can join in for now, the more popular the card the better. To start with, I intend to write the driver, and then some code that will tell me when a packet has arrived, if it is for this machine, and what protocol it is using. And I'll go from there. (I haven't read that far ahead ;-) Luke(Boo) Farrar.
Re: ELKS Networking
Hi David. >> Most cards that don't need the 16-bit bus don't come as 16-bit >> cards with the exception of those cards that are specifically >> designed otherwise. > Actually, there's a reason for some coming as 16-bit. That is > simply because they're capable of using IRQ > 7, or other > extensions like that. They still only use the 8-bit data bus > though. I proved this when I put a 1mb trident card into my XT. > The XT got it into 640x480x256, and was capable of > detecting/checking the full video memory. Memory says that the 16-bit extension connector was designed to enable cards to auto-detect whether they're inserted into an 8-bit or 16-bit connector, but few cards made use of this facility... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
Hi David. >> 1. You refer to an "NE2000" card. Presumably you're aware that >>those normally don't work in an XT as they require an AT style >>connector and the similar NE1000 card with its XT style >>connector has to be used instead. > Firstly, 16-bit cards can work in 8-bit slots. ^^^ Can, yes - but in my experience, NE2000-clone network cards NORMALLY do NOT work in 8-bit slots. I've used 16-bit 3COM network cards in 8-bit slots quite successfully, but never NE2000 cards. > I've used 16-bit network cards, video cards, IDE cards (on a 486 > board), etc in 8-bit slots without problems. So have I - but I've never managed to get NE2000-clone cards to work in 8-bit slots. As far as I'm aware, those and hard drive controllers are the only 16-bit cards that won't work in an XT. >> 2. Several people refer to reading from the ROM to positively ID >>the card. My network consists entirely of NE1000 and NE2000 >>cards, none of which have any ROM on board, and all are working >>fine. As a result, I would consider ANY code that relies on the >>contents of those non-existant ROMs to be highly suspect. > The 'ROM' is the ROM on the card. ie. the part of the card that > holds information such as the ethernet address, and the protocol > information for sending an ethernet frame. I stand corrected here - apparently, there's a serial PROM on most network cards that I hadn't noticed, and that's what was being referred to in the various quotes... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
On Wed, 14 Apr 1999, Jonathan Hall wrote: > Most cards that don't need the 16-bit bus don't come as 16-bit cards > with the exception of those cards that are specifically designed > otherwise. Actually, there's a reason for some coming as 16-bit. That is simply because they're capable of using IRQ > 7, or other extensions like that. They still only use the 8-bit data bus though. I proved this when I put a 1mb trident card into my XT. The XT got it into 640x480x256, and was capable of detecting/checking the full video memory. Davey
Re: ELKS Networking
> > 1. You refer to an "NE2000" card. Presumably you're aware that those > > normally don't work in an XT as they require an AT style connector > > and the similar NE1000 card with its XT style connector has to be > > used instead. > > Firstly, 16-bit cards can work in 8-bit slots. I've used 16-bit network > cards, video cards, IDE cards (on a 486 board), etc in 8-bit slots without > problems. That depens on the card. I have seen numerous network cards, and perhaps some IDE cards (as you suggest) that are 16- or 8-bit. Not ALL (in fact, most) 16-bit cards won't work in an 8-bit slot. Most cards that don't need the 16-bit bus don't come as 16-bit cards (i.e. internal modems are usually 8-bit cards unless they are PnP-capable or include other 16-bit peripherals such as a sound card), with the exception of those cards that are specifically designed otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Jonathan Hall * [EMAIL PROTECTED] * PGP public key available Systems Admin, Future Internet Services; Goessel, KS * (316) 367-2487 http://www.futureks.net * PGP Key ID: FE 00 FD 51 -= Running Debian GNU/Linux 2.0, kernel 2.0.36 =- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: ELKS Networking
On Wed, 14 Apr 1999, Riley Williams wrote: > 1. You refer to an "NE2000" card. Presumably you're aware that those > normally don't work in an XT as they require an AT style connector > and the similar NE1000 card with its XT style connector has to be > used instead. Firstly, 16-bit cards can work in 8-bit slots. I've used 16-bit network cards, video cards, IDE cards (on a 486 board), etc in 8-bit slots without problems. > 2. Several people refer to reading from the ROM to positively ID the > card. My network consists entirely of NE1000 and NE2000 cards, > none of which have any ROM on board, and all are working fine. As > a result, I would consider ANY code that relies on the contents of > those non-existant ROMs to be highly suspect. The 'ROM' is the ROM on the card. ie. the part of the card that holds information such as the ethernet address, and the protocol information for sending an ethernet frame. Davey
Re: ELKS Networking
On Wed, 14 Apr 1999, Riley Williams wrote: > with the other. > > 2. Several people refer to reading from the ROM to positively ID the > card. My network consists entirely of NE1000 and NE2000 cards, > none of which have any ROM on board, and all are working fine. As > a result, I would consider ANY code that relies on the contents of > those non-existant ROMs to be highly suspect. Is that not two different things? The ROM you are talking about is the BOOT ROM for diskless stations. Jakob
Re: ELKS Networking
Hi Luke. > I've finally started work on ELKS TCP/IP. > So far I've been making an ne2000 driver, but I've got some > books and stuff and I think its do-able. > Does anyone want to help? I'd be interested, and I have the pleasure of being a reasonably experienced C programmer as well. As a result, I'll start by mentioning a few points relating to various messages in this thread... 1. You refer to an "NE2000" card. Presumably you're aware that those normally don't work in an XT as they require an AT style connector and the similar NE1000 card with its XT style connector has to be used instead. I'm not sure that the code for one will always work with the other. 2. Several people refer to reading from the ROM to positively ID the card. My network consists entirely of NE1000 and NE2000 cards, none of which have any ROM on board, and all are working fine. As a result, I would consider ANY code that relies on the contents of those non-existant ROMs to be highly suspect. I'll also add that in my opinion, decent TCP/IP support and a working lpd daemon are all that's required to allow XT's and 286's to be used under ELKS as network print servers, and that would probably be the first marketable application for ELKS... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
On Tue, 13 Apr 1999, David Murn wrote: > On Tue, 13 Apr 1999, Tracy Camp (Hurrah) wrote: > > > the ne2000 chipset is I believe available from National Semiconductor > > under their part numbers, they have some really good documention on > > programming these chips in PDF format > > ne2000 uses the same ethernet controller as wd8003 and 3c503, being the > 8390. There is already a driver for the 3c503 sitting in the ELKS tree, > so modifying it to ne2000 should be fairly simple (just change the check > for the mac address, and make sure it works). > > Davey > I shouldn't have a problem finishing the ne2000 driver myself, and then I'll put it up for people to check. Ok? The problems are things like registering net devices. There has to be some code to register it to. Luke(Boo) Farrar.
Re: ELKS Networking
On Tue, 13 Apr 1999, Chris Starling wrote: > In the Linux ne2k driver, it checks the card's ROM for a couple of magic > bytes to positively ID the card. If you're using an el cheapo generic ne2k, > be aware that sometimes those magic bytes aren't what they should be. ne2k's aren't the only cards to do this. I've got 5 wd8003's that have done the same thing. The solution is to change the check for the checksum. Linux expects the checksum of the mac address (and the 2 extra bytes) to total to 0, however with these particular cards, the checksum is 0x40. This isn't too difficult to allow for though. Davey
Re: ELKS Networking
> ne2000 uses the same ethernet controller as wd8003 and 3c503, being the > 8390. There is already a driver for the 3c503 sitting in the ELKS tree, > so modifying it to ne2000 should be fairly simple (just change the check > for the mac address, and make sure it works). One thing I feel compelled to mention about ne2ks: In the Linux ne2k driver, it checks the card's ROM for a couple of magic bytes to positively ID the card. If you're using an el cheapo generic ne2k, be aware that sometimes those magic bytes aren't what they should be. On occasion I've had to mildly mung the Linux driver to get it to work with a card that was only 99.44% pure ne2000. This may have completely no relevance to writing an ELKS driver for these cards, but if it saves anyone the hours of headache that these cards have given me, then it was worth the bits spent on this message. :) -starling
Re: ELKS Networking
On Tue, 13 Apr 1999, Tracy Camp (Hurrah) wrote: > the ne2000 chipset is I believe available from National Semiconductor > under their part numbers, they have some really good documention on > programming these chips in PDF format ne2000 uses the same ethernet controller as wd8003 and 3c503, being the 8390. There is already a driver for the 3c503 sitting in the ELKS tree, so modifying it to ne2000 should be fairly simple (just change the check for the mac address, and make sure it works). Davey
Re: ELKS Networking
On Tue, 13 Apr 1999, Luke(boo) Farrar wrote: > I'm sure you can help. Porting driver's etc. isn't nearly as hard as > writing one from scratch. Actually it's not that difficult to write one for scratch (at least for any 8390 based cards). > We have the socket stuff so my plan is to hack up a cut down version of > the main Linux code. If Alan says anything other than "start from scratch" I'll be surprised. The Linux code is WAAAY too bloated to be of any real use, other than a guide. > I've made the functions in af_inet.c but they are all empty. Oh, goodie. My inet patch to libc might work now :) > I was planning to work from recieving a packet upwards, unless anyone has > any cunning thoughts on that one... I'd suggest the easiest way, is to handle ICMP, UDP and TCP.. in that order. ICMP means you can tune/test your code simply with ping, and is therefore much easier to debug (in my experience anyway). Davey
Re: ELKS Networking
> All the ne2000 driver does so far is detect the card and extract the mac > address but I haven't done much with it yet because I go back to school > tomorrow. the ne2000 chipset is I believe available from National Semiconductor under their part numbers, they have some really good documention on programming these chips in PDF format. I bring this up because I was sorta attemping to write a ne2000 driver for a homebrew ethernet card I was building for a 6502 machine and AS/OS65 (which uses SLIP as its default interface.) which incidentally brings up another good point, SLIP support should be easy, and would be quite handy. t. > > Luke(Boo) Farrar. > > > > > > > > > Tracy Camp 503.380.3218 Hurrah Internet Services [EMAIL PROTECTED] Consultants to the Networked World http://www.hurrah.com/
Re: ELKS Networking
> If you know anything about network cards I'm sure you'll be a help! > Porting a few of the major card drivers from linux should be do-able, but > the kernel internals should be the hard bit. The actual TCP/IP bit looks > ok though. I could attempt a western digital port. This is a really nice card that is quite often associated with older systems. This would have to wait until I had some time though. > If there is enough interest, (as there appears to be), I might even write > something to give people an idea of how I think things work, and what > needs doing in what order. Maybe somebody will tell me how things do work > 8-) that would make this easier. I too think that networking is an important step to making ELKS useful. Embedded systems are great, but they are much more useful if they are networkable. t. > > Luke(Boo) Farrar. > > > > > > Tracy Camp 503.380.3218 Hurrah Internet Services [EMAIL PROTECTED] Consultants to the Networked World http://www.hurrah.com/
Re: ELKS Networking
On Mon, 12 Apr 1999, Joseph Dunn wrote: > > > On Mon, 12 Apr 1999, Luke(boo) Farrar wrote: > > > > > I've finally started work on ELKS TCP/IP. > > > > So far I've been making an ne2000 driver, but I've got some books and > > stuff and I think its do-able. > > > > Does anyone want to help? > > > > I'd like to help, but I really am not a skilled programmer. I was > wondering if it would be possible to port Linux's TCP/IP software to > ELKS. If there's any way I can help, I'd be glad to. > I'm not "skilled" particularly either, but I'm learning. I've got a big TCP/IP bible now, and its not quite as bad as I thought. The main problem will be keeping it vaigly (sp???) compatible with the main Linux kernel. I'm sure you can help. Porting driver's etc. isn't nearly as hard as writing one from scratch. We have the socket stuff so my plan is to hack up a cut down version of the main Linux code. I've just mailled Alan Cox to get a few pointers, but I mean just. I've made the functions in af_inet.c but they are all empty. I was planning to work from recieving a packet upwards, unless anyone has any cunning thoughts on that one... All the ne2000 driver does so far is detect the card and extract the mac address but I haven't done much with it yet because I go back to school tomorrow. Luke(Boo) Farrar.
Re: ELKS Networking
On Mon, 12 Apr 1999, Michael A Hamblin wrote: > On Mon, 12 Apr 1999, Luke(boo) Farrar wrote: > > > I've finally started work on ELKS TCP/IP. > > > > So far I've been making an ne2000 driver, but I've got some books and > > stuff and I think its do-able. > > > > Does anyone want to help? > > I wish I could help but I'm not skilled enough. But this is in my > mind a very important project so I'm sure you'll hear a lot of verbal > support for it :) I've been trying to persuade people for yonk's but nobody seemed interested. Woohoo! Can you do any C? I'm not skilled enough either, which is why its going to be such a valuble learning experiance. ;-) I reckon I'd do it in the end, but a few more people should make things much easier. Luke(Boo) Farrar.
Re: ELKS Networking
On Mon, 12 Apr 1999, Jakob Eriksson wrote: > On Mon, 12 Apr 1999, Luke(boo) Farrar wrote: > > > > > I've finally started work on ELKS TCP/IP. > > > > So far I've been making an ne2000 driver, but I've got some books and > > stuff and I think its do-able. > > > > Does anyone want to help? > > > > Luke(Boo) Farrar. > > > > What kind of help do you want? > Maybe I should add that I don't know much about the kernel, > but a bit about hardware and programming in general. > > Jakob If you know anything about network cards I'm sure you'll be a help! Porting a few of the major card drivers from linux should be do-able, but the kernel internals should be the hard bit. The actual TCP/IP bit looks ok though. My actual programming is pretty poor, but my theory's ok :-) If there is enough interest, (as there appears to be), I might even write something to give people an idea of how I think things work, and what needs doing in what order. Maybe somebody will tell me how things do work 8-) Luke(Boo) Farrar.
Re: ELKS Networking
On Mon, 12 Apr 1999, Tracy Camp (Hurrah) wrote: > there is some VERY small TCP/IP code (6502 assembler) as part of AS/OS65 > which as an entire OS fits in something like 20K. The assember code > wouldn't be overly useful in and of itself, but it would be interesting as > an example of how to implement a very small tcp/ip stack. This is like etherboot. Except that the etherboot code fits in 8k (or is it 16k?) and is written in C :) Davey
Re: ELKS Networking
is etherboot snarfable code? Is so why not do so? It has to be under 16k because thats all the room you get on an ethernet ROM. There is probably other stuff that could be taken out such as tftp code so that would be smaller than 16k for sure. t. On Tue, 13 Apr 1999, David Murn wrote: > On Mon, 12 Apr 1999, Tracy Camp (Hurrah) wrote: > > > there is some VERY small TCP/IP code (6502 assembler) as part of AS/OS65 > > which as an entire OS fits in something like 20K. The assember code > > wouldn't be overly useful in and of itself, but it would be interesting as > > an example of how to implement a very small tcp/ip stack. > > This is like etherboot. Except that the etherboot code fits in 8k (or is > it 16k?) and is written in C :) > > Davey > > Tracy Camp 503.380.3218 Hurrah Internet Services [EMAIL PROTECTED] Consultants to the Networked World http://www.hurrah.com/
Re: ELKS Networking
On Tue, 13 Apr 1999, David Murn wrote: > On Mon, 12 Apr 1999, Joseph Dunn wrote: > > > I was wondering if it would be possible to port Linux's TCP/IP software > > to ELKS. > > Not really. The linux driver is WAY to big to fit in ELKS. Even the > minix driver (which is made for small memory machines), takes around 50k, > iirc. It would need to be a very small driver, such as the one used in > etherboot. This was what I based some of my code on. there is some VERY small TCP/IP code (6502 assembler) as part of AS/OS65 which as an entire OS fits in something like 20K. The assember code wouldn't be overly useful in and of itself, but it would be interesting as an example of how to implement a very small tcp/ip stack. I don't have the URL off hand for the OS web site, but if anybody is interested I could find it. Tracy Camp 503.380.3218 Hurrah Internet Services [EMAIL PROTECTED] Consultants to the Networked World http://www.hurrah.com/
Elks Networking
Hello, I noticed that someone mentioned that he was starting work on the TCP/IP stuff for Elks. There is a webpage which lists tons of relevant TCP/IP and networking stuff. It's at www.qnx.com/~mphunter/tcpip_resources.html. It's pretty interesting. -Joseph Dunn <[EMAIL PROTECTED]>
Re: ELKS Networking
On Mon, 12 Apr 1999, Joseph Dunn wrote: > I was wondering if it would be possible to port Linux's TCP/IP software > to ELKS. Not really. The linux driver is WAY to big to fit in ELKS. Even the minix driver (which is made for small memory machines), takes around 50k, iirc. It would need to be a very small driver, such as the one used in etherboot. This was what I based some of my code on. Davey
Re: ELKS Networking
On Mon, 12 Apr 1999, Luke(boo) Farrar wrote: > > I've finally started work on ELKS TCP/IP. > > So far I've been making an ne2000 driver, but I've got some books and > stuff and I think its do-able. > > Does anyone want to help? > I'd like to help, but I really am not a skilled programmer. I was wondering if it would be possible to port Linux's TCP/IP software to ELKS. If there's any way I can help, I'd be glad to. -Joseph Dunn <[EMAIL PROTECTED]>
ELKS Networking
I've finally started work on ELKS TCP/IP. So far I've been making an ne2000 driver, but I've got some books and stuff and I think its do-able. Does anyone want to help? Luke(Boo) Farrar.
