Re: Is ELKS a good idea for teaching O.S.
On Tue, 29 Feb 2000, Alegria Loinaz. Inaki wrote: I am a new participant in the list and after reading FAQs I have a couple of questions: - Is ELKS able to run executable programs from standard Linux? Not directly, since standard Linux programs are in 32bit code, ELKS is mainly for 16bit CPUs. Also, Linux uses ELF headers, ELKS doesnt. However, if your Linux code is small enough, there is no reason you cant compile it for ELKS, depending on what it does. - Is possible with ELKS to read the File System in the hard disk (I suposse no, but I don´t know sure) You can read the minix filesystem on the harddisk. As yet this is the only fs that ELKS really supports. Both Linux and ELKS can read this, as can many other systems. I am looking for a simple OS to use teaching (modifying the kernel) and despite simplicity is very important, I'd like to be possible to load pre-compiled programs and to have a file system in hard disk. Is ELKS a good choice for this or it is better an old version of the Linux kernel? Either would be good. The main benefit of ELKS is that it is a LOT smaller and easier to demonstrate parts of the kernel. For example, the floppy driver in ELKS is ~1500 lines, in Linux, its around ~4500 lines. Which would you rather try and explain? :) Davey
Re: 8086/88 80286 ||| 80386 80486 Pentium ...
On Wed, 1 Mar 2000, Ken Yap wrote: For the definitive list of Linux distributions, go to lwn.net/bigpage.phtml There are a few tiny distributions listed there that may install and run in as little as 2 MB. We used to run a very useful system (6 concurrent users) on 3.5mb, mainly running mail clients and mud clients. The record holder may be Paul Gortmaker's 896kB on a 2.0 kernel. Because it could be done, as they say. Also as another issue, ELKS will only address 640k of RAM will it not, in which case you're better off getting a couple more 386 boards without RAM and making multiple systems with the extra memory you've got. Davey
Re: Dos Binary Compatibility WAS Re: elksfs status
On 4 Feb 2000 [EMAIL PROTECTED] wrote: I'd be interested in any information/documentation on the MSDOS binary compatibility in ELKS. Oh god, is that still there? I put it in as a joke 2 years ago :) What purpose does it serve in the project? For the project, it had no real purpose. How is it being accomplished? Basically, its simply a binary format handler, which simply processes the exe header from a file, and claims that its valid or not. It was more an excercise for me learning how to parse exe headers. What could it be used for? It can basically be used for putting an EXE header on a binary. How compatible and with what versions of DOS? I dont think its compatible at all. I dont think it even works. What is its current status and where is it going? Who is doing it? I dont think it was ever really seriously going. Feel free to develop it further if you wish. You wont really be able to run applications properly in there anyway, without modifications to the kernel anyway. Davey
Re: Dos Binary Compatibility WAS Re: elksfs status
On Sat, 5 Feb 2000, Greg Haerr wrote: Yes. I'm quite familiar with MSDOS EXE format and the current code doesn't do anything near what's required. And even if it did, there's the problem of having linking with a Linux8086 libc but producing .exe files... I know. I guess someone obviously missed the word 'joke' distributed throughout my email. Now I know how kr felt when people took C seriously. Davey
Re: Updated files in elkscmd
On Wed, 2 Feb 2000, Alistair Riddoch wrote: If anyone has contributed code to this directory and is not credited, please let me know and I will put you into the files headers. I've got a new fdisk just about ready to go into elkscmd, which should fix a number of bugs people have reported. Should also be easier to use too. I'll send you a URL or the .c file when I'm done and you can stick it in cvs. Whens the new elkscmd coming out? I'll try and get it in before it comes out. Davey
Re: making a second primary partition
On Sat, 22 Jan 2000, Matt Balaun wrote: I can create the partition without any problem, but how do I figure out how big it is in MB simply from the sector information ELKS fdisk displays? I wrote the fdisk program, but I've basically forgotten how it works. You should find that it prints the number of sectors in the partition. Divide this number by 2 to find the number of kb, or by 2048 to find the number of mb. Partitions work on a cylinder basis though, not a mb basis as such, so you should have enough information there. So is there some standardized way to figure out MB information from sectors? Is it HD specific? Its not disk-specific at all. Sectors are 512 bytes in size. Maybe its time for an update to the fdisk program, and some documentation on it too. Look out for that real-soon-now :) Davey
Re: Call for a README file
On Fri, 21 Jan 2000, Alistair Riddoch wrote: Anyone who wants to contribute to the project, but can't code, here is your chance. Don't worry about discussing in depth what the files should contain. I was thinking this could also be a good place for an (almost) howto. If people try to install, then report on the methods they found to work, and any problems they had. Infact we could almost compile a list of systems that are known to work, eg. V30 with 2 MFM drives and a single 720k floppy, etc. with contact details for someone who has done it, willing to answer any questions. Any thoughts? Davey
CVS back
Hi all, As some of you may have noticed, CVS on elks.doa.org came back up a couple of hours ago (around midday GMT). Simon had a 3 hour yelling match with the ISP who finally fixed his connection. Feel free to start using CVS again, and feel free to try out the networking code and play spot-the-bug-and-send-davey-a-patch. :) Davey
Re: elkscmd/(sys_utils|file_utils|sh_utils)
On Sun, 5 Dec 1999, Mario Frasca wrote:
login.c removes the trailing '\n' from the password, passwd.c doesn't do
it. I don't know what is the reason for removing the '\n', but I assume
there must be one, so I added the following lines to passwd.c
Yes, there is a reason for it. The password is simply "foo" not "foo\n".
while (pwd != NULL) {
if (pwd-pw_uid == uid) {
+ int i = strlen(nbuf1);
+ if(nbuf1[i-1]=='\n')
+nbuf1[i-1] = 0;
pwd-pw_passwd = crypt(nbuf1, salt);
}
I'd suggest something like:
char *p=strchr(nbuf1,'\n');
if(p) *p='\0';
one more: in file_utils/mkdir.c the default permission for the directory
is 666. this does not allow entering the directory. I changed it to
777, but maybe something less could be more appropriate. what is the
role of umask(0)?
IIRC, you simply xor the given mask with the umask. However, this is done
in kernelspace, not userspace.
Davey
Re: Y2k
On Sat, 20 Nov 1999 [EMAIL PROTECTED] wrote: That's SICK! How the h... can anyone take a patent on a time format?! This is only in America, the land of the free and the stupid. Davey
Re: Intro
On Wed, 17 Nov 1999, Alan Cox wrote: We dont really have a networking layer. I don't that is in itself a problem since you can prove you send/receive frames correctly and the rest is someone elses problem. Agreed. My ne[12]000 code (which should be in the CVS tree by now), should in theory let you send/receive frames. The fact that it doesn't properly work is a minor problem, however I'm suspecting only a tiny bug. There are some ideas for the stack kicking around. One thing for sure. The stack will be a userspace app. I dunno about this. I think that a stack is fittable into kernel space, and this is how I intend to write the bits of it when I get ethernet stuff working. Develop using DOSemu on Linux. It saves that annoying reboot cycle, and you can use the DOSemu ioport logging to debug it ;) DOSemu is great, but it has the problem that I can't talk to physical hardware. For developing other code, such as tty code, or userspace apps, I gotta agree dosemu is great. I tried vmware too, but it seemed a bit excessive. Davey
Re: Networking and stability (Was: Intro)
On Fri, 19 Nov 1999, Alistair Riddoch wrote: Agreed, but for initial coding, it may be best to run in user space till code fairly near to completion. There is alot to be said for this as an idea. Its much easier to debug user space code, and it doesn't bring the system down when it crashes. Sure about that? :) I think the stability at the moment is that if any programs do the wrong thing, the system is gonna crash either way :) Anyone tried crashme on ELKS yet? :) Davey
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
On Sat, 13 Nov 1999, Stefan Pettersson wrote: So we are back to the usual problem, where in the 640 kB should we put or own EPROM. On x86 you've got 20 address lines, this is 0-1mb. What do you think the space is reserved for from 640k-1024k? ROMs. When the system boots, it will probe various address, in 2k blocks, from c800:0 to f400:0, looking for a ROM. So basically, stick your ROM anywhere in that range that isn't otherwise used. Davey
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
On Sat, 13 Nov 1999, Blaz Antonic wrote: All you have to do is to insure your ROM image uses correct format (utils in netboot package create correct images from executable binaries) and BIOS will do the rest of the job Actually, 'format' simply means 0x55aa at the start of the image, and the 3rd byte contains the number of 256 byte pages in the ROM. Nothing else is involved in the 'format'. it will detect the ROM fetch its size and start address and start executing code from it. It is up to you (ROM) to return control to BIOS (and let it boot normaly) or execute kernel and boot into your OS (that's the way you want it if you imaplnt a ROM inthere). I'd suggest that you don't do it this way, and that you actually hook interrupt 0x19. This allows BIOS to detect various hardware, and call any other important ROMs, such as video and disk controller. While you (in theory) can boot directly from the ROM, ELKS won't like you much. Apart from anything else, quite a few drivers, notably the disk and console drivers generally use BIOS calls. Davey
Re: KISS networking for elks
On Thu, 11 Nov 1999, Vali Dragnuta wrote: As I knew about ELKS acute need for networking /* :-) */, here is an idea I have to deal with the problem quite in a simple way. Ideas are fine, but I got sick of people talking about networking and just wrote it. Writing code is much faster for development than yakking about it. The main impediment in doing that is that it's quite (_very_) hard to make a _real_ network terminal (more than telnet or serial terminal) with a 640k ram 8086,BECAUSE -It-s a laptop so only a parallel net adaptor could be used. Does it have a PCMCIA slot? Does it have a serial/parallel port for PPP or PLIP? -Even a for a desktop it would be hard to find a net card to _work_ in it. Not at all. 8086 simply means it's only got an 8bit slot so you get an 8bit card, such as an ne1000 or a wd8003. Over the years, I've found that quite a few 16 bit cards will work in 8bit slots. -If somehow we could deal with theese, the BIGgest problem is the memory a IP+TCP+UDP implementation would be _very_ expensive in memory I dunno about that. My ethernet driver is 3k, which is quite 'expensive', but is quite possible to shrink it. Remember that the etherboot supports ethernet, IP, UDP, rarp/bootp and tftp in under 16k, along with quite a few extras in there too. and this does not include my frontend-backend postgres protocol, and does not include the frontend application. Firstly, the network stuff will be in kernel space, not user space, so this isn't a problem. However, you'll be pushing it very hard if you can get your postgres library into a single 64k segment. What is this all about: We're clear that a full TCP implementation would be expensive. Read what I just said above about etherboot. While I admit that TCP is a bit more overhead, it's not impossible. Because IP is quite stuffy (quite many options to care about), and TCP is even more complex for a 8086 toy. You don't need to recognize all the options, infact even Big Linux doesn't recognize them all. [ SNIP: Information about KISS ] The big problem I see with KISS is the same problem that happened with term and socks similar programs. Old protocols are unable to work without modification and linking against the KISS library. The next question is would the overhead of the library justify the saving of not having TCP code in the kernel? I don't think it would. Anyway, the main idea is to create a much simpler but safe protocol for local low distance communication,and a protocol translator on the real linux side. While this does look good for it's task, I think it looks unusable as a permanent replacement for full TCP/IP stack. So if you find this could be useful for elks, let's discuss about the lower level stuff, so that eventually both my msdos kiss tcp and elks kiss tcp would be inter-operable. I wouldn't think there'd be any lower-level stuff at all. At least as far as ELKS is concerned. As far as an application, you'd need to design the protocol, but this can all be done over the existing serial driver in ELKS. Davey
Re: Stupid licensing thread (Was: Request for comments - Microwindows)
On 4 Oct 1999, Vidar Hokstad wrote: I still personally think the MPL is the only standard license that fits the linked in case at all I agree, but on the other hand I'd gladly support licensing the code under both the GPL and the MPL, so that those who wants to develop free software can do so and still use other GPL'd software in their programs. IMHO, the simple/obvious answer is GPL. If someone wants to write commercial/closedsource programs, there's nothing at all stopping them from writing their own library, under their own license. I very much dislike the thought of someone making money off any code I've written, without giving something back to the opensource community, and I'm sure quite a few people would agree. As long as the API and/or messaging protocol are open spec, then anyone can write their own library. X is an example, XFree uses opensource license, metrox and accelx used closed. Same function, same result, but they had to write their own library. Davey
RE: new version of nano-X/microwindows
On Mon, 4 Oct 1999, Greg Haerr wrote: On Monday, October 04, 1999 1:32 PM, Araujo, Isaque G. [SMTP:[EMAIL PROTECTED]] wrote: : Would be nice if you had some screenshots of nano-X/microwindows running ! : Yes, it would be. Sometime ago this was discussed on this list, and IIRC, all that had to be done was that /dev/fb0 was read to get the bits, and then they need to be written out in some bitmap format... Heck, even easier than that, just run it under dosemu, or vmware, and get an X snapshot. Davey
Re: Year 2000 bug support ??
On Fri, 1 Oct 1999, Luciano [ISO-8859-1] José Alves wrote: I have a question. Does have ELKS support for Year 2000 bug ? How about a y2k statement? "Your computer will die before ELKS" sounds appropriately correct. Davey
Re: Fdisk
On Fri, 1 Oct 1999, Werner Heuser wrote: for me 0.0.79 worked with 'fdisk /dev/bda1' on a C286LT Don't use /dev/bda1, use /dev/bda. bda1 is partition 1 on the 1st disk, which is not what you want. Davey
Re: Getting off this list
On Wed, 22 Sep 1999, Benjamin Hauger wrote: Forget it. I've asked to be unsubscribed about three or four times and I've tried. Once you're on this list, there's no escaping it. You might want to try setting up a procmail script to bounce all incoming list messages back at the list. I'm about ready to. Great way to get your name, as well as your ISP blacklisted. Just about all list servers are the same in the way you subscribe/unsubscribe. At least all majoromo-run servers are. Simply send mail to [EMAIL PROTECTED] (where x is whatever is after the @ on the list, in this case vger.rutgers.edu), and put "unsubscribe list-name", where 'list-name' is what's before the @. Simple. If you want to be removed and this doesn't work, don't just sit and whinge, email [EMAIL PROTECTED] (again where 'list-name' is whatever is before the @). Davey
Re: [Fwd: syntax doc. about as86]
On Tue, 7 Sep 1999, Thierry DELHAISE wrote: movb4(di),*36; (What mean the * prefix of value 36) ; does 4(di) means [di+4] ??? Simple answer. Assemble it under as86 and see what comes out :) Davey
Re: OS development
On Tue, 7 Sep 1999 [EMAIL PROTECTED] wrote: Does anybody on the list know where some docs, HOWTO's, books, etc are(preferably on the net) on the theories behind OS/kernel development and maybe how to implement them? I'm hoping there's something out there not necassarily on linux but on OS/kernel development in general. I know at the university here, they offer a course in OS development. It's a 3 year course I believe, and it covers all the aspects of development, from the theories to actually writing the system/apps. I've been told that it's possible to sit in on some of the lectures of this course, so you might find a university/college near you has similar courses which you may be able to sit in on. Failing that, simply look at ELKS from the very beginning (ELKS 0.0.10 is available, and linux-86 before that), and look at how things have been implemented since then. Davey
Re: Custom BIOS?
On Sat, 31 Jul 1999, Grant Stockly wrote: Does anyone know if there is source code on the internet for a BIOS? It doesn't matter how detailed it is, all I want to know is basically what is done. There is one on simtel. I forget where exactly, but I've put it up on the web, at http://doa.org/~davey/bios-asm.zip Davey
Re: Turbo C
On Thu, 29 Jul 1999, Perry Harrington wrote: I brought up a thread a long time ago on this, Borland wasn't interested then, but they just released Turbo C for free. Source, or just free binaries? If it's only binaries it's not much use to us. This means we can use it for compiling in the ELKS project. You mean 'cross-compiling' (if it's not source). Davey
Re: ELKS 0.0.78 released
On Tue, 20 Jul 1999, Blaz Antonic wrote: I have already suggested to use BIOS console instead of direct one on PS/2 machines long time ago, but noone tried it. So, disable dircon and enable bioscon support in config, recompile and try again. Please let us know whether it works or not (in case it does it should be added to the faq). I can tell you that it won't work. I know this because I wrote it :) Al fixed a small part of it a while ago, but afaik, it still doesn't work properly. Feel free to debug it if you want though, it's fairly simple to navigate through the source. Davey
doa.org administrivia
Hi all, At 10:32am GMT, 18th July 1999, a host on the domain shared by doa.org was entered into the ORBS database. As a result, some users have had mail bounce from the developers mailing list. Any mail address which bounces to this list with an error such as the ORBS error, or a 'user does not exist' error will be removed from the mailing list. This is what happens when you use automatic mail rejection, it saves you 1 spam a day and sends me 10 bounces a day. Davey
RE: rfs (new filesystem for ELKS)
On Mon, 19 Jul 1999, Greg Haerr wrote: Why has elks chosen a 16 bit inode number for stat when the rest of the world has 32 bit inode numbers? It probably is a good idea to use 32bit inode numbers. I'd say the simple answer is that because ELKS is targetted at 16bit (or less, ie. not 32bit) machines, that 32bit inode numbers aren't a good idea. Same reason that under Linux/x86, we use 32bit instead of 64bit, simply because we've got a 32bit CPU (or 16bit in the case of ELKS). Davey
RE: ELKS bugs fixed
On Wed, 14 Jul 1999, Luke (boo) Farrar wrote: bcc -0 -O -ansi -s -ansi fsck.c -o fsck -H undefined symbol: _S_ISSOCK It would be nice as a hard disk filing system is fairly useless without it. Well, ISSOCK is checking if stat() was done on a socket. Not much use at all until the OS supports sockets :) It'll go in sys/stat.h. Davey
doa.org
Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. Also, the [EMAIL PROTECTED] kernel mailing list is now back online. Davey
Re: doa.org
On Thu, 15 Jul 1999, Jakob Eriksson wrote: On Thu, 15 Jul 1999, David Murn wrote: Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. The web message is not very friendly though! I know, I stuck a rocket up him yesterday, hopefully that will be fixed today. I've got a feeling he changed machines recently and hasn't setup the virtual host stuff properly yet. Simon? Davey
Re: compile 0.0.77 problems
On Wed, 14 Jul 1999, Scott Lanning wrote: 3) Also FAQ Q2.5, it says 'mkfs -t minix -n14 /dev/fd0 1440', but my mkfs has no -n14 option. However, 'mkfs.minix -n14 /dev/fd0 1440' works okay. (Maybe it's just my (Redhat 5.1) distribution.) Must be a redhat issue, in slackware (and also when I compile mkfs from the original source (ie. non-redhat source)), it works fine, and just passes the -n14 on to mkfs.minix. I guess this is a problem when you use source modified from the author's original works. Davey
RE: ELKS bugs fixed
On Wed, 14 Jul 1999, Greg Haerr wrote: The issue here is that the size of the libc.a file itself is 512k, so the filesystem won't let ld86 read it... It is? I dunno where you got your libc.a from, but mine is 82k. libc under Linux is 512k, but under ELKS, it's tiny. Davey
RE: signals
On Mon, 12 Jul 1999, Greg Haerr wrote: : This is debugging info from the kernel which basically means that signals : are working. Actually signals don't work well yet. Try ^C in a variety of programs, and you'll find yourself logged out with the original still running, etc. Well, close enough, at least ^C killed SOMETHING. :) I'm assuming this means that something isn't handling a SIGCHLD properly? This could also be fixed so that when a process dies, it sends a signal to all it's children. Davey
RE: ELKS bugs fixed
On Mon, 12 Jul 1999, Greg Haerr wrote: Killed your baby? Why, it seems this one died from neglect ;-) try typing ESC [ H on the console. Nothing happens. Yep, it won't do anything. The only commands supported, are: m (color), s (save location), u (unsave location), A (up), B (down), C (right), D (left), K (clear EOL). Mainly because these functions were already existing in the dircon code so it was very easy to interface to them. : The reason bcc wouldn't run was because it was too large ( 64k) to even : link. Yes, but I created a version with the -Mf model that will compile into less than 64k. So I have a bcc that runs. Ooooh, sounds fun. As an example, strcat is coded to strcpy(d+strlen(d), ...) By the time that strlen has finished, the strcat could have nearly completed. Yep, unfortunately there's no real way to make this faster is there? Except maybe by optimising strlen. Yeah I agree. But the ANSI or vt52 driver shouldn't care about the low-level character output method. As I said above (had to re-read my code because I'd forgotten how it worked), I basically just called the functions that were already there. I wanted to make the patch as easy to write as possible. Well, the bell code was 200 bytes or so, and I think most of the other kernel changes amounted to very little. I see all sorts of areas that the kernel size can be reduced... I agree, but of late I've had little enthusiasm to try and trim the fat off the larger areas of the code. In particular, the inode hashing code in fs (or is it specific to minixfs) is basically redundant. Firstly, we can do without hashing for a slight speed decrease. Also, the hashing method causes 2 hash look-up tables to be kept, which not only uses up RAM, but also code space, and clock cycles. Thanks. So - do you want me to rewrite the ansi console driver so that it works? Also, should elks have a ansi as its default console ( I vote yes, and will do the work) 'rewrite' isn't really needed. Simply check the HandleAnsi function, around line 400 of (the original) arch/i86/drivers/char/dircon.c, and add the functions to that for extra commands. Davey
RE: ELKS bugs fixed
On Tue, 13 Jul 1999, Greg Haerr wrote: : I agree, but of late I've had little enthusiasm to try and trim the fat : off the larger areas of the code. Hmm.. I haven't got to that yet. What other areas are bloated? I basically did an: ls -lS `find -name *.a` to find all the large bits and then pick on them. Also a find on *.o finds some bulk too. Davey
Re: ELKS bugs fixed
On Tue, 13 Jul 1999, Luke (boo) Farrar wrote: Do we still have the 512k file size limit? I thought that libc was bigger than this or something, and that was one of the limiting factors on a self hosted bcc. Not quite. I didn't actually know about the 512k limit, but greg says it's there. libc is tiny, as all ELKS programs are statically linked, so libc+program must be less than 64k. Davey
Re: ELKS problems
On Mon, 28 Jun 1999, Greg Haerr wrote: I can't get Micro-Windows to work with the serial mouse driver. It appears there's still possibly a bug in select(). Basically, the mouse works for about 1 second and then freezes. As I read this, the first thing that pops into my head is that you're not re-setting the struct timeval. Try setting up strace in the kernel, and see what happens when you run it. It appears the serial driver queues stuff inbetween close/open's. Have you seen any of this activity? My guess here (maybe) is a flow-control issue. You might find the buffer/queue is actually in the mouse, and as soon as you open the device, the flow-control lets the data come in. Davey
Re: SV: Capabilities
On Tue, 1 Jun 1999, Thor Harald Johansen wrote: Okay. I need a reasonably good text editor. Point me to one, please. ;) levee comes with the elkscmd package. Davey
Re: SV: Capabilities
On Tue, 1 Jun 1999, Thor Harald Johansen wrote: Oh, by the way, the standard shell, is it very poor compared to other shells? Actually, it's not, if you look at all it's doing. Sash as a shell is very basic, but internal to that one executable are a LOT of prorgams. From small programs such as cat, echo, cp, etc. up to ls, ed and tar. Can I make ELKS boot from ONE disk instead of a boot + root disk? Yes. Get the 'combo' disk image in the images.zip file. Davey
Re: Web space for developers
On Tue, 1 Jun 1999, Robert Amstadt wrote: As you may know, I run one of the mirrors for the ELKS project. I was browsing around the web pages and noticed that at least one of the ELKS developers was using Geo Cities with their annoying pop-up ads. I have a 384k connection to the Internet to my Linux system at home. Assuming that traffic isn't too heavy, I would be happy to offer accounts and web space to any of the active ELKS developers. Any of the web stuff can (and should?) be put into the web tree on the CVS. This way all the mirrors can update from the CVS server, and keep it all in one place. Davey
Re: Capabilities
On Tue, 1 Jun 1999, Ross Vandegrift wrote: ed would be a good start, but I'd rather see a vi implementation. ed, is called (surprisingly) ed. vi is called levee. Those 2 programs are already there in the elkscmd package. Davey
Re: 0.0.76 Question.
On Thu, 27 May 1999, Luke (boo) Farrar wrote: Is it a config option? It doesn't happen using sash, but does with ash. Probably because sash's inbuilt ls isn't using signals, so doesn't need to setup a signal handler. And why doesn't 286 protected mode stuff compile? Did it ever? I'm just shoving my networking code start across. Not fun! This is part of the reason why CVS was made. As you write your code, keep it up-to-date in the CVS tree. This way before alistair checks new code in, he's gotta make sure it'll merge cleanly with the CVS tree. Which is generally a better idea since he knows what he know how much the new code affects other parts of the code. Davey
RE: ELKS video drivers...
On Mon, 17 May 1999, Greg Haerr wrote: 1. IBM MDA. no graphics support... Umm, are you sure? We used to run windows 3.0 on amber monochrome monitors at college. Davey
RE: NanoX version 0.3 released
On Wed, 12 May 1999, Greg Haerr wrote: The point about ELKS being currently limited to 64k code is a very good one. I think we're kind of nearing that limit, aren't we? We've been over this issue many times. There are many reasons to limiting the size like this, and that is simply the fact that machines of this era don't have many megs of RAM to waste. The target machines of ELKS are running on 256k or 512k of RAM, with some running on 640 or with an extra memory card. If you increase the limit, by allowing multiple segments then people will start to slacken off a bit with their code. Also, a few of the ideas being thrown around, such as swap and stuff are made easier by the fact that only one segment is in use by a program. The simple answer is for app developers to write smaller code, not for kernel developers to handle larger code. If you try and use the argument about "but I simply can't get it any smaller", then take a look back 10-20 years ago when people were writing programs of similar functionality in a LOT less ram than 64k. For example, I've got a simple BW terminal here with full window manager capabilities, which is running entirely in 640k. I doubt it needs this much RAM, but it shows that with proper protocol development, it's possible to do such an application in little RAM. Come to think of it, this would be a nice target for ELKS. 1024x1024 screen, 68000 CPU and 640k RAM. Davey
Re: I am a novice
On Mon, 10 May 1999, Enzo Humberto De Lucca Alday wrote: I dont now so much about computers,i am the tipical student that use the computer for text only... For someone who uses it for text only, why did you use a graphical mail program which HTML encodes your mail? In response to your question, check out the FAQ and webpage, you'll find good information there on the installation process. Davey
Re: some questions
On Sun, 9 May 1999, Alessio Morale wrote: Dan Olson wrote: Well, I'm sure that your correct in that most Z80s only have = 64k, but there are some exceptions, such as the TRS-80 Model IV and the Commodore 128 (as the name implies). But isn't a 65XX based computer the Commodore 128? The C128 is a 6510 CPU. There are 128k machines around though, such as the Microbee. The Z80 can't address 64k though, as it only has 16 address lines, so it must do this with a trick called bank-switching. I know a guy who managed to do some software tricks to get his Z80 to bank-switch across 2mb of RAM, so its not limited to only 2 banks, just a little more magic. Davey
Re: I/O port on HP200LX
On Sat, 8 May 1999, Tadayoshi Kubo wrote: I know the I/O port No.00-0F is DMA controller and the port No.20-21 is interrupt controller. But I don't know how to use the port No22 and 23. Anyone know the I/O port No.22,23 meaning on the HP200LX? Assuming it's simply an 8259, you can find the relevant information in the package called HelpPC (in the hardware section), available from: ftp://ftp.cdrom.com/pub/simtelnet/msdos/info/helppc21.zip This package also has info on a lot of other chips, such as various UARTs and keyboard controllers and so on. Under Linux, the PIC is shown as using ports 0x20-0x3f, so it's definitly part of the PIC. Davey
Re: I/O port on HP200LX
On Sat, 8 May 1999, Blaz Antonic wrote: Under Linux, the PIC is shown as using ports 0x20-0x3f, so it's definitly part of the PIC. Actually it's not. Ports 0x22 and 0x23 are used on many chipsets (mostly non-intel chipsets, cyrix/AMD processors settings and stuff like that) and do not belong to PIC. So why does Linux reserve this entire block? Davey
Sorry about bouncing mail
Hi all, I've had a problem recently with my mail which may have caused some of you to get bounces when sending mail to either me or to a mailing list. That problem has been fixed, so bounces from me should stop. If anyone has sent anything directly to me, you'll need to resend it, and I'll just check up on the archives for the list stuff. Davey
RE: Booting ELKS from DOS Re: your mail
On Tue, 4 May 1999, Araujo, Isaque G. wrote: Shane, I don't know if you read my old mails which I've sent to Alistair Riddoch and to the ELKS-list, but this already exists (BOOTELKS by Steffen Gabel), what is need is a effort to change this code for don't write any VII, just start ELKS. The wheel is almost complete. No, this is the whole problem, we DO need to change the VII, because DOS changes some of the hooks, such as int 13 (apparently). Without changing this back to BIOS, there's no telling what might happen. Davey
Re: Off-Topic: EPROMs?
On Thu, 29 Apr 1999, Dustin Lang wrote: Anyways, I have a bunch of EPROMs that I'd like to program, but I can't get the silly things to erase. They're supposed to be UV-erasable, but I don't have a good source of UV. I tried sunlight but apparently the ozone is too thick here. Can anyone suggest a source of UV suitable for erasing EPROMs, preferably without too much skin cancer :) Firstly, check if they're UV erasable or electronically eraseable, when you're sure they're UV erasable, then try the following ideas.. make sure the UV filter is off before you try and erase it, even if there's a bit of pastic sticker there that looks clear, it may still be a UV filter. If you can, try an eprom eraser, they cost around A$100 or so, and will do the job properly. Failing that, find a good source of UV light, such as a UV light globe. These cost around about A$10 at an electronics shop, and fit into a standard light socket. As a last resort, try and find a tanning studio, and ask if you can stick your eproms in one of their tanning machines for a little bit, on ultra high. Davey
Re: your mail
On Thu, 29 Apr 1999, Wenzel Jakob wrote: my palmtop boots from DOS from ROM (argh) and i can't create a boot disk for generating the ints.bin file. i need a dos-version of this program or perhaps somebody can explain me how to generate this file and I'll write the program. I'm guessing that it's simply a dump of your vector table, in which case, you should be able to just write a little .com file, to create a file, and copy 0x400 from 0: into a file. If you want, I could send you a little .com file to do this (assuming that's what needs to be done). Davey
Re: GEM (WAS Re: vgalib)
On Thu, 22 Apr 1999, Joshua E. Rodd wrote: The GEM code is neat, and it *is* GPL'd, so maybe we can play with it, but it's always more fun to write our own code than port. =) Sure, it's more fun, but if you port code, then you can actually get some sort of relatively fast turnover of applications. Davey
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
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
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: some questions
On Tue, 13 Apr 1999, Molenda, Mark P wrote: 1) My assumption is that the port of linux to 8086 processors is called ELKS. Where would I get a tar for that? Yep, it's called ELKS. The current tgz is available at Alistairs site, which is ftp://ftp.ecs.soton.ac.uk/pub/elks/ 2) How many working parts are there now? Does it have an editor, networking ( ppp, slip etc.). Is there mail on it? It has an editor (levee, a vi clone), it has a few basic tools, such as grep and text utils compiled for it. There are also a few shells ported (sash and ash in particular). There is no networking as yet, but every man and his dog claims to be working on it :) 3) Is there a Matthew Welsh ( I hope I got his name right) type doco project going on, or is it too early? Who is Matthew Welsh, and what sorta docs has he made? Most of the documentation is available either from the kernel source tree, or from http://elks.doa.org/ (when it's up). 4) What compilers are working, and are there any cookbook type steps to get this up and running? The main compiler we're using is called bcc. The b is for 'Bruce' and not for Borland. The compiler called zcc is being used for the z80 port (which is all but stopped). A couple of people are working on getting bcc to run under ELKS, but as yet, no luck has been had. 5) How can I help? Read through the section on the website about how to help. Porting useful little programs from Linux to ELKS is always helpful. Running ELKS on a system and finding/reporting bugs in it is also helpful. Hope this answered the questions you had and any others that you didn't ask but wanted to know. Davey
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: Limiting amount of memory used for disk caching in Linux
On Sun, 4 Apr 1999, Ted Pavlic wrote: Does anyone know how to limit the amount memory used for disk cache by Linux? Firstly, this is the wrong list to ask it on. Try linux-kernel. I've wanted to do this for a long time too, and the basic answer is "you can't". Linux has a nice little bug where when the sound driver tries to allocate it's buffer space, and the disk cache is using it, it fails because of being out of memory. The solution to this, is to write a simple little program to malloc space, and free it. This will flush all the disk cache out of memory. Davey
Re: [OT] asm in bcc
On Tue, 23 Mar 1999, Stacy D. Coil wrote: uint32 v; uint32 m; #asm mov v, eax mov m, ebx #endasm But this returns and no symbol for v and m. Could someone be kind enough to show me how to pass varibles from c to assembly and back? You can't just say "mov v, eax", because that's not being passed through the compiler. There's 2 ways you can try it.. prefix the 'v' with an underscore: mov _v,eax Alternatively, you simply find out where abouts in memory that variable is, and write there. For example: int c,d; c=0x123; d=0x456; Compiles into: pushbp mov bp,sp pushdi pushsi add sp,*-4 mov ax,#$123 mov -6[bp],ax mov ax,#$456 mov -8[bp],ax So, you use "mov -n[bp],ax", where n is the offset into the stack of the variable you want (plus 6 (sizeof(bp)+sizeof(di)+sizeof(si)), in bcc's case). So if you've got 3 int's, and 4 char's, and you want the offset of the 4th char, you say 6+(3*sizeof(int))+(4*sizeof(char)), which works out to 16. At least that's how I understand it to work. Anyone got anything to add/correct? Davey
Re: Merced/Linux??
On Thu, 4 Mar 1999, H.Oura FCT Headquarters?? wrote: I'm very interested in the development status of Merced/linux. If there's someone who knows about that, please inform me. Unless merced is some device for the 8086, ELKS will probably never support it. Davey
Re: Merced/Linux??
On Thu, 4 Mar 1999, Jonathan Hall wrote: Unless merced is some device for the 8086, ELKS will probably never support it. Merced is Intel's new-fangled attempt at making a good processor (64-bit). Quite the opposite of the 8086. In that case take it off our list :) Davey
Re: PRO-120(B) PCI Fast ethernet adapter
On Wed, 3 Mar 1999, Jonathan Hall wrote: But for your question... you might look at the card itself and see what chipset it uses, then look in the Kernel configuration or in /usr/src/linux/drivers/net for a driver that matches the chipset. I've found drivers for a few of my cards that way. One trick that hardly ever fails is booting the slackware 'scsinet.i' bootdisk. I've seen this trick used dozens of time without failure. Davey
Re: USA residents beware
On Sat, 27 Feb 1999, John Oram wrote: The Federal Communications Commission ruled yesterday that dial-up internet connections are interstate in nature and should therefore be subject to federal jurisdiction. Firstly, this is not the appropriate forum to be discussing this. Secondly, there's actually a low percentage of USA residents on this list. Around about 1/3 are US residents. But in relevance to your topic, the main reason for this I think is that so many people are using the net for voice stuff and video stuff. Personally I think that US residents have been getting free phone calls for far too long. There is one obvious solution to this problem. Radio networks. No more phone calls, no more modems, and best of all, a card which is fairly easily supported with ELKS. Davey
Re: Embedded MS-Windows NT
On Tue, 23 Feb 1999, John Oram wrote: (3) Microsoft begins embedded NT beta Welp, and I thought cisco held the record for the largest roms at 8meg. I guess if nothing else, the ROM industry will like this. Some of you have probably heard this joke before, but anyway Apparently they're talking about using these NT systems in aircraft. Brings a whole new meaning to the word 'crash', IMHO. Davey
Re: ELKS 0.0.75 released
On Tue, 16 Feb 1999, Alistair Riddoch wrote: A single make command can now be used to build a complete filsystem image, or a (nearly) bootable floppy image, including configuring and building the kernel and bootblocks code. How was this different to before? Make used to create that stuff before didn't it? Davey
Re: kernel fission was: msdos/umsdos support?
On Thu, 11 Feb 1999, Dan Olson wrote: Huh? Not to open up a large can of worms here, but in my opinion the ONLY reason for ELKS is for something fun for its participants to do. The relative utility of 8086-class computers goes down every day. If you don't like it, then get off the list. Consider that you can buy a used computer with a Pentium 60 with onboard video, IDE, serial, and parallel, 16 Mbyte of RAM and a 270 Mbyte hard disk for around $75, and run REAL Linux on it (check it out for yourself on any of the on-line auction web pages). Say if you wanted to buy 100 of these machines. Or 1000 of these machines. You couldn't really do it as easily. Besides, why spend $75 for a machine for students in a school for example, when an old XT (which is being discarded) can be used instead. Also, if you've got say a dozen old XTs, you'll wanna get them to work. If you don't want to get them to work, there's lots of people who will quite gladly take it off your hands and get it to work. Davey
Re: TCP/IP stack on ELKS
On Fri, 29 Jan 1999, Gaurav Lochan wrote: About ELKS, well, i wanted to know WHY you havent been able to write a TCP/IP stack for it ? To start with, there IS the beginnings of a TCP/IP stack. I think the author managed to get it to reply to pings, but I'm not sure if he did or not. The big problem is that we're very tight on memory space, so the code has to be small. ps whats this about Coke machines being operated off the net ?? I dunno about that, but I know that coke machines plug into a phone line so that when they have a fault, or when they need to be re-stocked, they contact coke, and someone comes out to deal with it. Davey
Re: Kernel 2.2.0 too big on RH5.2 system...
On Thu, 28 Jan 1999, David D.W. Downey wrote: Uhh, excuse me but the list says it is for linux 8086, which even to me means it's a list for Linux machines based on the 8086 processor. ie 386, 486, 586 ect. ect. Not quite. Not "Linux machines based on the 8086" more "Linux based on the 8086". If you can't distinguish the difference between 8086 and 80x86 maybe you should read up on it some more. So, until the name is changed to linux-elks, expect 8086 linux questions to pop in. We don't mind 8086 linux questions, that's 100% what the list is for, but 8086, NOT x86 (as the list implies). The dosemu list is called linux-msdos. We never have a problem with people posting there saying they can't get DOS and Linux working on the same machine, so why should we have people posting here about problems which are unrelated to the list? Davey
Re: Intro
On Thu, 18 Nov 1999, Giles Russell wrote: OK, call me stupid, but how can I get to the CVS tree ??? Someone else (Simon) should be able to answer this. I've forgotten how to, actually :) The stack will be a userspace app. I dunno about this. I think that a stack is fittable into kernel space, Agreed, but for initial coding, it may be best to run in user space till code fairly near to completion. Well, the TCP bits, maybe. But I intend writing the socket code, and raw/(udp?) layer in kernel space. Who is Beau Kuiper, and is he still working on the networking stuff ??? Or is David working on it Beau just sorta disappeared into the wilderness. He came up with some good concepts, but didn't put anything into place. I got sick of all the talk and no coding, and simply wrote the code. These may seem like simple questions, but I am getting the feeling the docs are little out of date :) Correct, some of the docs aren't even remotely correct anymore :) Davey
Re:
On Mon, 14 Dec 1998, Stephen Bowyer wrote: Just my personal opinion, if you don't like it then as far as I'm concerned you can log in as root and enter "rm /* -R". If you don't like it, you could hit the 'd' key. Davey
Re: unsuscribe linux-8086
On Mon, 7 Dec 1998, David Schleef wrote: Is this a cruel joke by microsoft to automatically "correct" the accepted spelling of the word that will cause unsubscription so as to be gratuitously incompatible with Majordomo and leverage their own mailing list software? No, this is someone accidently mis-typing a word in an email. Believe it or not, it does happen. majordomo@vger doesn't do administrivia anyway, so even if it was spelt correctly, it'd still come to the list. Davey
