Help Wanted!

Greetings to all,

As you may have noticed the project has been stuck for quite a while, i am looking forward to bring it back to life, but and would like to ask for some help, obviously coders are very welcome, but also people willing to help writing docs, and even people looking forward to help us create a new look for the project website.
Looking forward to hear back from you.

regards

Miguel.

Hi Miguel,

I am very happy that you will attempt to do this, I have given up on ELKS since even a basic question like why is the mailing list archive link dead has remained unanswered.

However, before you start I think that you need a good set of obtainable goals. The reason is simple, you need to get hackers/hobbyist interested in the project so that they start contributing. The current target audience(?) of old XT/PC type of hardware systems is no longer viable. I might be wrong in this respect but I believe you should target embedded and home grown hobby systems. This requires a fundamental change in the development tools since BCC is limited to 8086/6809 systems only.

David Given had an idea to use the ACK compiler for ELKS since ACK supports a large range of 8 bits microcontrollers, however, I am afraid that by adopting ACK we add a huge amount of work and complexity to the project. I for one failed to build ELKS on my 64bits system and after a day of hacking I gave up since the system was too complex for me (I am a hardware designer and not a softie :-).

Why don't you start with a survey, how many people are on this list, what do they use ELKS for, what would they like to use ELKS for, who is in charge of the website etc..

Regards,
Hans.
http://www.ht-lab.com/

----- Original Message ----- From: "Miguel Bolanos" <[email protected]>
To: <[email protected]>
Sent: Saturday, September 24, 2005 6:30 AM
Subject: Help Wanted!

Hi Hans and Miguel,
3 months back i acquired a laptop with an 80C86 processor, and 640KB RAM, and tried running ELKS on it. Sometimes while booting I had some errors, and sometimes I did not. I do not remember the errors now, and instead I just used MS DOs (last resort !!) on the computer to see if it worked. I did not work on ELKS or on the computer after that. I am definitely interested in understanding ELKS and contributing something. I know C, C++ and am familiar with the x86 assembly instruction set. I also do know parallel processing, and once was wondering if ELKS can be made intelligent enough to connect few microcontrollers or 8086 type processors and do parallel processing. Of course a tcp/ip implementation would be required.

--
Vikas "Rex" Walburn

Hi Rex,

Thanks for that, perhaps I am wrong, perhaps old hardware is the only thing people are using ELKS for.

Any others, Chrysostomos? you seem to be doing some development, David, Harry?

Unfortunately the mailing archive is still giving me a 404 so my understanding of the ELKS "world" is just 6 people, surely there must be more?

Regards,
Hans.
www.ht-lab.com

----- Original Message ----- From: "Rex Walburn" <[email protected]>
To: <[email protected]>
Sent: Saturday, September 24, 2005 8:43 PM
Subject: Re: Help Wanted!

Well guys, I appreciate your efforts to bring elks back to life. I tried once to use elks in my hp200lx but with no luck at all. hp200lx still has a lot of users, if you could boot a hp200lx with elks I guess you would have a lot of guys trying elks for sure.

Unfortunately I couldn't run elks on mine, but hey it's just an idea!

Good luck you all, I'll be watching you! 8)

--
Isaque Galdino
"Beat to fit, paint to match..."

Have you tried ELKS' arch-rival, Minix? I'm not sure if Minix 2 will run on the i86, but Minix 1.5 certainly does, and works reasonably well.

The big trouble with ELKS is that it only really runs on i86 machines, and these are a right pain to deal with --- it's not just that they're really old, decrepit machines which cost more in electricity to run than a pocket calculator a thousand times more powerful does today, it's that no two are the same. Standards were pretty fuzzy in those days, and there's a huge variety of different kinds of hardware that needs supporting. Actually making ELKS work reliably would be a rather large undertaking just for test purposes...

(DOS gets away with it because, basically, DOS is crap. It relies on the BIOS to do a lot of the work, which ELKS can't really do. Minix manages a bit better but it's a bit picky on the kinds of hardware it'll support for just this reason.)

Can ELKS be ported to *other* architectures that i86? Would it be feasible to use it on a modern, flat architecture like ARM?

+- David Given --McQ-+ "Hydrogen fusion, the sun makes shine
|  [email protected]    | Vascular pressure makes the ivy twine.
| ([email protected]) | Because of Rayleigh, the sky's so blue.
+- www.cowlark.com --+ Hormonal fixation is why I love you." --- Zarf

I assume you're talking about PCs based on the 8088/8086, as I'm sure new machines could be built using the processor as well. There were standards... but a lot of hardware that came with some sort of DOS driver to make it work (CD-ROMs, tape drives, and network cards come to mind).

I know the BIOS is sometimes lacking for what we're trying to do, but DOS isn't crap for reling on it, that's the way the machine was designed, and the idea isn't that bad at all, as hardware would have it's own BIOS and the OS doesn't need to support everything ever built. Plus, now we have hindsight, I mean, we can choose to support only two or three network cards, the most popular hard drive controllers (Don't know how they work with the BIOS bypassed), and things of that nature. If you don't have the supported hardware, you'd have to go to eBay and buy it :)

I suppose at some point it would be easier to start from scratch, but I'm sure some porting could be done.

Dan

Why not?

I actually like the BIOS :-) since it is the BIOS which enables me to write a debug style monitor which runs on my FPGA board and with very minor modifications on my 64bits desktop. I actually believe that the success of ELKS relies on the definition of an easy to port BIOS/HAL layer. I would even suggest that we define a standard set of BIOS calls. If your processor doesn't support software interrupt then perhaps a CALL instruction would work?

I assume with flat you are referring to a segment/offset style of architecture, I haven't check the ELKS code in any detail but I assume this issue can easily be resolved?

I would forget about ARM since they have a very good uCLinux port and gcc support.

Regards,
Hans
www.ht-lab.com

+- David Given --McQ-+ "Hydrogen fusion, the sun makes shine
|  [email protected]    | Vascular pressure makes the ivy twine.
| ([email protected]) | Because of Rayleigh, the sky's so blue.
+- www.cowlark.com --+ Hormonal fixation is why I love you." --- Zarf
----- Original Message ----- From: "David Given" <[email protected]>
To: <[email protected]>
Sent: Tuesday, September 27, 2005 9:13 PM
Subject: Re: Help Wanted!

On Tuesday 27 September 2005 22:06, Hans wrote:
[...]

The short answer is because the BIOS is not reentrant, which means it can only do one thing at a time. Remember the bad old days when accessing the floppy disk would make the system freeze? That's the BIOS' fault.

Also, the BIOS is *extremely* basic. The BIOS elevator algorithms for MFM hard disks sucked hugely; I once ran big Linux on a 386 with an MFM drive, and was amazed at just how much faster Linux' disk access was, simply because it was scheduling the I/O transfers more efficiently. I'm not even sure the BIOS does DMA. Remember that the B stands for Basic...

Now, it *might* be possible to multitask during a BIOS call provided only one task was accessing the BIOS at any time. You still wouldn't be able to, e.g., access the hard disk while the floppy drive was in use, but at least the system shouldn't just freeze.

[...]

Yeah, but uCLinux is still very large compared to an ELKS kernel.

(BTW, someone has told me via email that they have Minix 2 running on a i86 machine, but the TCP/IP stack tends to eat most of the available memory. So it does actually work.)

+- David Given --McQ-+ "Information wants to be free, but my mail client
|  [email protected]    | does not want to be chock-full of herbal pot
| ([email protected]) | alternative spam." --- Sant Lupus on Slashdot
+- www.cowlark.com --+ 

Hi All
I have a few points to make

1) The BIOS of 8086/8088 systems and the earlier x86 systems were very basic and used extremely less memory. To make ELKS depend on the BIOS would not be a good move, in any case.
2) Minix requires atleast 1MB RAM or even more to actually run. But for those people who would wanna use ELKS for microcontroller programming or 8086 processor programming and for systems that use these. Such systems (either old hardware or home-brewed hardware or FPGA systems etc.) have limited memory usage they can support. Something of the order of 640KB or so. This is where ELKS can score over Minix, because the memory required is much less.
3) As far as supporting different architectures goes, one architecture which is more common among microcontrollers/small scale processors (either Motorola 6800.. or 8086 ) can be chosen. Finally, as high level programmers we do know that in the end it will just be a matter of modifying a few instructions.

And Hans, people will use ELKS more if it works properly according to their requirements. There are always crazy guys out there who would love to use it given the opportunity. And who knows even if few of us work together and get something done, people doing embedded systems could start using ELKS because of low memory capabilities.

So what's the plan ?

--
Vikas "Rex" Walburn

Hi there,

	I'm running Minix 2.0.2 on both a 8088 and 80286 (with 640k). With 

TCP/IP enabled, there is RAM space for only a couple of extra processes (I can't remember the exact amount; I mean "extra" as appart from the minimal getty's, sh's and so on), so you can not even type "make", since if spawn some extra subprocesses (compiler, linker,...) and runs out of memory.
Minix 2.0.3 and 2.0.4 are supposed to swap to disk, but are said to be
too large to run on 640k.

Javier Sedano Jarillo: [email protected]
Agora Systems, S.A.
C/Aravaca 12
E-28040 Madrid (Spain)
Tel.: +34 676 48 29 55
Tel.: +34 91 533 58 57
Fax.: +34 91 534 84 77
--------
< Se alquila este espacio para Publicidad. Interesados preguntar Aqui >

Well, I've been on the mailing list since... the '90s some time I guess. My origional thinking is that it'd be cool to have a Linux like system on an XT or 286, I have a collection of old systems and it'd be neat to use ELKS on them. I finally was able to get a DOS packet driver and a program called Minuet working on my XT and NCSA telnet/ftp on my 286, both using 3Com network cards, so I hate to say but ELKS would really need that functionality to be useful to me on the old machines. Building an 8088 or 8086 system would be neat to do too but at this point I don't really think I'll be doing that.

Dan

I'm still "lurking", but haven't had time to do anything serious with ELKS since getting it running on a Compaq Portable II.

I have some XT, 286 and stripped-down 386 machines I'd like to use as firewalls, printer servers, file servers, etc., but that would require ethernet capability. National Semiconductor has an application note with 8086 assembly code for the DP8390, which would probably work with NE1000/NE2000 ethernet cards. The application note is:

	AN-874
	Writing Drivers for the DP8390 NIC Family of Ethernet Controllers
	National Semiconductor
	Application Note 874
	July 1993

National's AN-937 (Loopback Diagnostics Using the DP8390/901/902/905) has some C code that might be helpful. This is only the lowest-level hardware stuff, and would require a great deal more to work with a real ethernet card, but maybe the rest could be translated from Linux. If Harry's still out there, maybe he could help.

I, too, was wondering what happened to the mailing list archive.

Hello from Gregg C Levine
I, as well, have stayed with this group for the same reasons. I also have here a Compaq Portable as well.
It is a Portable III.

Now as to your Nat Semi, applications note, have you actually implemented it? It happens I have the parts here, probably have the note as well.

Incidentally has anyone tried building the current ELKS source code using today's Linux toolchain, and BCC?
---
Gregg C Levine
[email protected]

----- Original Message -----
From: <[email protected]>
To: "Hans" <[email protected]>
Cc: "Rex Walburn" <[email protected]>; <[email protected]>
Sent: Wednesday, September 28, 2005 5:29 AM
Subject: Re: Help Wanted!

thing

...

No, I didn't.

By the way, note that the routine "pkt_recv_rt" (page 12 of AN-874.PDF) *ends* with the line:
NICtoPC
and the routine "ring_ovfl" *contains* an identical line (on page 13 of AN874.PDF). I presume that these are macros that translate to:
call _NICtoPC
which is a subroutine on page 9 of AN-874.PDF.

I also suspect that the label "Writing_Word:" in _NICtoPC should be "Reading_Word:" (page 9 of AN-874.PDF), that the "seq" in:
mov es,seq recv_pc_buff
should be "seg" (in "pkt_recv_rt", page 12 of AN-874.PDF), and that "_INTERRUPTSTATUS" in:
mov dx,_INTERRUPTSTATUS
should be "INTERRUPTSTATUS" (in ring_ovfl, page 12 of AN-874.PDF).

In addition to the application notes I mention previously (AN-874 and AN-937), you might also want to look at two other documents I found online --
AN-475.PDF, "DP8390 Network Interface Controller: An Introductory Guide"
and
DP8390D.pdf, "DP8390D/NS32490D NIC Network Interface Controller"
The latter is a 56-page datasheet.

Hi!

I don't think I will be of much help, but the ELKS project has interested me enough to keep myself subscribed to the list (and the list hasn't received enough spam to annoy me ;) ) My _personal_ opinion is that ELKS as it stands (8086-specific) will never have enough support to become an interesting project. Supporting more architectures means that there is the need for a flexible compiler, and very portable code.

I think portable code is equivalent to "gcc-like" in this case, but gcc itself seems far too complex to ever work in a "small" environment. The TinyCC [1] compiler comes close, and already has non-i386 code generators. It lacks a pure 8086 generator, however. I also think that the compiler should implement a 32 bit int (and in fact adhere to the limits as given in susv3 [2]). That way there could be more code-sharing with other "modern" projects, in particular dietlibc, uClibc, Busybox.

Anyhow: Good Luck :)

btw. Who is the maintainer of this list?
Majordomo says:

regards,
Alexander

[1] http://fabrice.bellard.free.fr/tcc/
[2] http://unix.org