Re: Talk...
This isn't a normal PC linux list. Try elsewhere. Whats a LiNuXeRRR? Luke(Boo) Farrar. On Mon, 24 Jan 2000, r00t the LiNuXeRRR wrote: I have an Linux Red Hat 6.0 with kernel 2.2.13. I have instaled on it talk. Like a user talk works fine, but like a users is says somthing like this "[Target machine does not recognize us]" Thx... Seby
Re: Web browser ported to Microwindows
On Sat, 13 Nov 1999, Greg Haerr wrote: I'm happy to announce that I've just heard that Opera Software has just ported their fully functional web browser to Microwindows! They have sent me a screen shot, which I will post. The port uses the Nano-X API, and runs in client/server mode. Full color support, palette mapping, jpeg and gif image and font support is working, as well as transparent images. It actually works! The total size of the browser codefile is 667k, much, much smaller than most web browsers. This means that it's possible that Opera could port the software to any of the newer palmtop or LinuxCE [MIPS, StrongARM or SH3] devices for browser access, since Microwindows now runs on these processors. For more information on Opera Software, see www.opera.com. Whats the speed of microwindows like at the mo? any faster? Has it made it to the psion 5 yet? BTW: ftp://microwindows.censoft.com/pub/microwin/readme.txt has a typo: htpp:// ??? Luke(Boo) Farrar.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
Nice Anyone know where I can get a rom blowing thingy? Have you actually tried this? Is bios required? Luke(Boo) Farrar. Christian Mardmuller ([EMAIL PROTECTED]) has contributed the code required to build ELKS so that it can be booted from ROM. It is now possible by specifying an option in the config to build a kernel image which can be programmed into a ROM, installed in a network card or something similar and booted.
Re: Microwindows now has a web site
So microwindows now runs in color, with a touch screen on a palmtop! Luke(Boo) Farrar.
Re: 8086+linux project
On Wed, 6 Oct 1999, Leonardo Sampaio Cardoso wrote: Hi guys! I am taking the microprocessors class at the university. My professor wants us to build a small system using the 8086. I thought it would be real cool to get elks running on this system. My question: Is it possible to get elks to fit in 64Kb of rom and run in 64Kb rof ram? If it is, how can I get it done? Bye the way, anyone knows any links to 8086 projects? thanks in advance.. leosam. Sounds cool. What university? I'm looking at the mo, but predictions od ddc aren't in huge demand. 64k would be pushing it I think. Maybe a rather old version? Luke(Boo) Farrar.
RE: new version of nano-X/microwindows (not silly licence thing)
On Tue, 5 Oct 1999, Greg Haerr wrote: * wrote asm version of VGA driver for ELKS : : How much faster is this thing? Useable? It's definitely faster, and it works. I use it for the ELKS port, which runs on _slow_ systems. The old one was abismal even on my 386. Is the flickering/poor mouse movement on ELKS any better? Luke(Boo) Farrar.
Re: new version of nano-X/microwindows (not silly licence thing)
On Mon, 4 Oct 1999, Greg Haerr wrote: The major changes in this release are: * wrote asm version of VGA driver for ELKS How much faster is this thing? Useable? Luke(Boo) Farrar.
RE: your mail
On Tue, 28 Sep 1999, Greg Haerr wrote: : Or is there a better way to use the two cards together? DOS does not do this : very well (appart from a few utills that switch the screen, and a few apps : that support it (tcc).) : : There is no current support for this in the ELKS code, but it does appeal : to me. Any idea how it can be done at a low level anyone? If there is : source code available for the DOS software, then it could be ported. : I think the answer to this is that each virtual console needs to have a pointer to it's screen driver code, where there's multiple screen drivers running. I don't know how you'd want to specify which VC gets VGA vs herc though... Why not just have a /dev/2tty driver set for the new monitor and have init asign logins to /dev/tty and /dev/2tty? Luke(Boo) Farrar.
Re: MC68000
Bcc seems to support the 6809, whatever that is. Luke(Boo) Farrar. On Sat, 21 Aug 1999, Jakob Eriksson wrote: On Sat, 21 Aug 1999, thcg wrote: The linux m68k docs are very vague about the hardware that can run that OS port. It says the least is MC68020 which implies that MC68000 is useless. Can ELKS be run in the MC68000? If the MC68020 etc are higher class controllers of the order of 386 etc running 32-bit code... MC68000 must be a slightly lower class of say 8088 etc... I think the same way ELKS was produced from linux... an MC68000 port can be derived from standard linux-m68k .. any ideas? ucLinux runs on the 68832 (or whetever is in the PalmPilots) the 68332 is a processor very much like the 68000. No MMU... What they had to change for ucLinux was for example fork() to copy instead of fiddling with MMU. Jakob
Re: ELKS on a Net186?
On Thu, 19 Aug 1999, Gary Watson wrote: Hi, Has anyone put ELKS on an AMD Net186? This is the little Am186 demo board with 512k flash and 512k ram, no floppy drive or other peripherals, and a PC Net ISA-II 79C961A network chip. Does ELKS have the capability to run TCP/IP? No TCP/IP yet, but its something that people have talked about doing (I want to have a go, but I'm not up to it yet). Also ELKS isn't quite romable yet. We really need to sort that out. Luke(Boo) Farrar.
Re: Help installing elks...
On Wed, 18 Aug 1999, Tamer S. Embaby wrote: Hi, I can't get elks running under my system. It stops at Insert ROOT disk and dies. Machine specs? Step 5: I can't get bcc working neither in DOS nor Linux a) under DOS [Dev86dos-0.14.9.tar] Sod DOS. b) under linux [Dev86bin-0.12.0.tar] I followed the Docs and issued: tar zxvf Dev86bin-0.12.0.tar -C /usr/src the docs says I should get it under /usr/src/linux-86 but I get two dirs [usr and lib] under /usr/src. I put bcc on the path [export PATH = $PATH:/path/to/bcc/bin] then: # bcc -0 -O -s -ansi -o init init.c I get: bcc: exec of bcc-cc1 failed bcc: error unlinking /tmp/bcc0184 path to bcc: /usr/src/usr/bcc/bin path to bcc-cc1: /usr/src/usr/bcc/lib/bcc I don't whats gone wrong here, but this should be /usr/bcc not /usr/src/usr/bcc I would get Dev86 0.14 as well. It compiles nicely (or did for me) so get the src. Can anybody tell me what I'm missing here, or how to solve the problem, give me examples please if you could. I need to get elks running. Exeuse me for my poor english. Certainly not! ;-) Luke(Boo) Farrar.
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. This means we can use it for compiling in the ELKS project. The idea would be to get a real mode compiler that can do the things we want, but it would need a back end linker to produce ELKS executables. Where can I get it? I really would like Turbo C 1.0 for some old code I have. Luke(Boo) Farrar.
Re: Good news????
On Mon, 19 Jul 1999, Alistair Riddoch wrote: Luke writes: In the mtools directory there was this readme: 8 mtools - tools to read msdos floppies from unix pc Compiled with a couple of tweaks, but cannot read disks, even under dosemu. Al ([EMAIL PROTECTED]) Sun 11 Oct 1998 16:20 8 I just deleted one exit(1) (line 101 of init.c); and mdir works fine. The others seem to work too. Where it said Can't read FAT or whatever was all crap. Good news, but looking at the code I think we need to work out why the read() call the reads the FAT is not returning the correct value, rather than just inoring the error condition. It doesn't work with elksemu either. Could it be something to do with an older dos format? From elksemu, I think that with a valid dos disk, fatbuf = 3314 buflen= 4608, and this seems constant. Luke(Boo) Farrar.
Re: compiling 0.0.78
On Mon, 19 Jul 1999, Alistair Riddoch wrote: Werner Heuser writes: I tried to make a 0.0.78 kernel than and got this error: make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block' bcc -D__KERNEL__ -O -i \ 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c boot/crt1.c:5.25: error: cannot find include file arch/segment.h make[1]: Leaving directory `/usr/local/src/elks/arch/i86' make[1]: *** [boot/crt1.o] Error 1 make: *** [Image] Error 2 I don't understand why you get this error. WHat version of dev86 are you using? It has nothing to do with that. But the file blah/elks/arch/i86/arch/segment.h doesn't exist. I think it went pear shaped with the new psion friendly makefile. Luke(Boo) Farrar.
RE: ELKS 0.0.78 released
On Mon, 19 Jul 1999, Dan Olson wrote: A few of us had this exact same problem on PS/2 machines, and I believe the problem ended up not being the disk drive but rather the keyboard not being detected. A simple test, if you can do it, would be to try the combo boot/root image, and see if it hangs or not. Sence you are using 5.25" disks (right?) I take it you don't have a PS/2 as they came with 720k drives. I believe the combo image requires at least 720k disk space, so if you have a machine that can read a 720k disk, it may be a good test. Hope this helps, good luck. I just tried it and found the same thing on a ps2. It's the keyboard that it has a problem with. With the comb image it mounts the root disk fine, runs init fine, then you can't login because of the keyboard. What is so special about ps/2 keyboards? Luke(Boo) Farrar. Dan On Thu, 15 Jul 1999, Jeff Stanton wrote: The problem is that the system does not mount the root disk (AFAIK) I let it spin the root disk for 5 minutes after pressing enter, but nothing happens. But since it works for you, it's probably a problem with my disks. I found another pair of disks, and will try it again tomorrow. -Jeff
Good news????
In the mtools directory there was this readme: 8 mtools - tools to read msdos floppies from unix pc Compiled with a couple of tweaks, but cannot read disks, even under dosemu. Al ([EMAIL PROTECTED]) Sun 11 Oct 1998 16:20 8 I just deleted one exit(1) (line 101 of init.c); and mdir works fine. The others seem to work too. Where it said Can't read FAT or whatever was all crap. Sorry if people new this before. Luke(Boo) Farrar.
RE: herc microwin support
Could I take a peek just for fun? Luke(Boo) Farrar. On Wed, 14 Jul 1999, Jakob Eriksson wrote: On Tue, 13 Jul 1999, Greg Haerr wrote: On Tuesday, July 13, 1999 12:35 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : I think it is a good idea to look into herc support for microwin? How many : 8086's do you know with a VGA card? OR is it a bad idea are 8086's too slow : to run microwin? : Well - you've got a good point - an 8086 is probably *way* too slow to run graphics programs of any merit. However, I would like to add a screen driver for hercules. Is hercules only monochrome, or does it support color? Do you know how the screen memory is accessed? Do you think you could write the driver? : If anyone else is interested I have some specs and some assembler examples : of how to control the herc card. Send me the asm examples, I'l take a look. In particular, examples in small model that read and write a pixel, and write a horz and vertical line are all that's needed. In 1997/1998 when my only Linux box was a 386SX with Hercules, I played around with graphics, since I wanted to view pictures. I disturbed a lot of people with questions and could eventually display PCX pictures (I converted all pictures I wanted to PCX using Image Alchemy) on my Hercules screen. I am sending the code to Greg and anyone else asking for it. Almost no asm though (only a couple of instructions) the code is in C. It does not compile, since I messed something up, but the functions shows what and how to do. I am particularly proud of the tightly coded PCX-reader! :-) regards, Jakob Eriksson
RE: ELKS bugs fixed
On Thu, 15 Jul 1999, David Murn wrote: 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. This is why I thought I had it wrong. Speaking (or not) about filesystems, whats this all about: 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. And: bcc -0 -O -ansi -s ls.c -o ls undefined symbol: _S_ISSOCK H. Luke(Boo) Farrar.
Re: ELKS bugs fixed
This is why elvis, as86, and many, many other large programs have never run. Elks never let programs have 32k data segments! With this fix, I plan on self-hosting bcc and as86, which now will run... The reason bcc wouldn't run was because it was too large ( 64k) to even link. This is where the fat has to be trimmed first, before anyone even starts to worry about running it. I've wondered if it's possible to use temporary files in some way, and break down the compiler into multiple steps. From memory, this is sort of how minix does it (minix runs more than 2 programs to get .c to .o). 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. Did I remember this wrong? How long before we get a self hosted bcc? Luke(boo) Farrar
Re: Recent kernel updates
On Fri, 9 Jul 1999, Alistair Riddoch wrote: Hi all, I have just spent the day hacking, and have finished off some bits and pieces, and commited them into CVS. As CVS mail reporting doesn't seem to be wroking while doa.org is down, here is a summary of what I have commited. Tweaked the bioshd driver to make sure it still works when hd is disabled. Added byteorder functions required by romfs. romfs now compiles, but does not seem to work yet. Added a basic pseudo tty driver. This almost certainly does not work in a standard way, but was enough for me to hack together a terminal program for nano-X. Loads of socket code. I have added lots of code from Linux 1.2 which gives elks the socket layer api, and I started on getting unix sockets working under ELKS. I also took the unix socket code, and used it to write code for a new type socket called nano sockets. These work very like unix domain sockets, but they don't use a filename as their address, they have a single integer as their address instead. This makes the code very small and simple. I have tested these, and they appear to work. The main purpose to this socket family is to provide an inexpensive way of running nano-X on ELKS. Nice one. On the subject of sockets my holidays are finally here, and I'm gonna play some more with TCP/IP. It would be a lot easier though if I new how to link the kernel up to the user space network stack. Could people give me a few hints on this? Luke(Boo) Farrar.
Re: Recent kernel updates
The program calls the socket stuff which goes to the inet_ functions in the kernel. Packet generation would begin there, but I wan't that to happen in user space, so that the socket stuff is in kenrnel, but everyhing else is outside. Luke(Boo) Farrar. On Sat, 10 Jul 1999, Blaz Antonic wrote: Could people give me a few hints on this? What exactly would you like to know ? Make some interface to kernel - special (character ?) device that allows nothing but read()/write() and ioctl() (and of course, mandatory open/release :-))). Whenever you attempt to pas a packet (IP packet) to network layer you simply write to this device, by using select() on it you will be able to notice new packets (in separate, child process maybe). ioctl() will be there to help you set any parameters you might need. This device driver would then take care of passing this packet of yours to network interface. You'd mostlikely have to do packet queues in your program, you don't want to use ekrnel space for that (even though i think one should be able to squeeze basic stack in remaining 4-5 KB). bye, Ab
RE: ELKS problems
On Mon, 28 Jun 1999, Greg Haerr wrote: On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote: : 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. : OK. Al, does Micro-windows work for you? How about anyone else? It works fine for me, but the mouse doesn't work on a pentium. Still don't know why. Luke(Boo) Farrar.
Re: Assembly Howto - BCC (fwd)
The chap who does the Assembly-HOWTO was wanting some info on the following things for the howto. Any comments would help. TIA, Luke(Boo) Farrar. He wants. 8-- Well, things like: * compiler status * who's the maintainer and what's the main site for BCC? are there multiple branches, or only one? He doesn't seem to know about Dev86. * What are your contacts (if any) with Bruce Evans (original author)? with HJLu (maintainer of bin86)? Have they in the past made statements about your developments on BCC? None? See Rob de bath? * is there maintenance for 32-bit instruction set, and newer instructions (in particular, has my patch for 32-bit segment pushing, and/or something equivalent, made it into BCC?) * is there a standalone BCC package somewhere? Dev86 again * what documentation is available? is it in the same package? in another one? Same again. * in particular, is the macro system documented? * have you anything to add?
Re: Capabilities
On Thu, 3 Jun 1999, Alan Cox wrote: In addition, the minix filesystem *must* support files 512k, something it doesn't do now. The libc.a file is 512k so you can't even link anything on ELKS. This requires supporting 7 indirect blocks. Umm it used to. What happened ? : Networking. I think we need ELKS DLL's for this, so that we can run the kernel and any user programs with separate code and data segments to keep the link Keep networking mostly in user space. That btw is also the model things like the early networking work on V7 unix took. The networking text file in the Documentation dir says: Cut here 8 Notes on networking code Current development model is based around using a user process to be the actual TCP/IP stack with socket file descriptors and device drivers dealt with by the kernel. The diagram below show how things should work. ___ | | || |Network Application| |TCP/IP stack process| |___| || | / | | /| _|_/_| | |/ || | KERNEL | / || |_|__/_ __|| | | | | | | | | Socket code | | RAW Driver| | | |__| |___| | | || | || |_|| | __| | | | Network Hardware | |___| The Network Application uses the standard BSD socket interface to open and read and write to sockets. The socket code passes the data on to the TCP/IP stack process, through a file descriptor. (char device or socket). The TCP/IP stack process then constructs TCP/IP packets and writes them to the network device driver including all the necessary hardware headers. Cut here 8 This seems sane. If we have a /dev/ip to communicate with the tcp/ip stack process from the inet_ functions, then virtually everything sits outside the kernel. I don't know much about the userspace device drivers yet, but these could potentially be used for network drivers, and if not a network driver wouldn't take up too much memory. So the user space tcp/ip stack would just take the data, slap in in a cutesy little packet, and shove it out to the network driver (and the same but backwards). Something that shouldn't be as hard to do from userspace. I'll link my inet_ functions up to a device driver for now. Any comments? Lukeboo Farrar.
Re: Palmtops ELKS
On Thu, 3 Jun 1999, Frederic SOULIER wrote: Hi there, I am very interested in projects like ELKS, I would want to know if ELKS is running on palmtops with 8086 or clones processors, like HP200 LX, Psion 3a,... I'm very interested in kernel networking developpment(my actual job) Funky! Networking is the one thing that I really wan't to get going, and intend to do a fair bit on it once my exams are out the way( in a few weeks). However, I have very little experiance. It would be great if you could help with this one. Luke(Boo) Farrar.
Re: Announcing Micro-Win
On Wed, 2 Jun 1999, Greg Haerr wrote: This list has been conspicuously quiet for the last while, so I thought I'd try to wake it up a bit. Following my last major work to nano-X version 0.6, which basically got all the mini-x feature set running, along with device drivers for keyboard, mouse and screen for linux framebuffer, linux 1.x svgalib, elks, msdos, and bare hardware, I decided that it would be time to see whether the basic "Gd" device middleware layer was ready for another "upper-level api." Can I have a copy of nano-X for elks? I think it would go real nice on my hard disk machine BTW: Why is it that on some machines (286/8086) elks boots, and freezes after displaying login: Any clues? Luke(Boo) Farrar.
RE: Capabilities
On Thu, 3 Jun 1999, Greg Haerr wrote: On Thursday, June 03, 1999 10:07 AM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : : You then need a 386. 64K is the limit. The original work I did was designed : : to be easy to run in 286 protected mode once you got rid of any BIOS interfaces. : : :Remind me - what then is the benefit of protected mode? Merely : separate address spaces? : : You get two things in 286 protected mode : : 1. You take exceptions if you try and go out of your segments : 2. You get 16Mbytes of addressable ram : : So, basically, 286 protected mode still runs in 64k segments, and in order to address the additional memory on a per-process basis we need large code or large data segments through the compiler (far pointers). In this way, larger programs can be written. With bcc currently, there would be no benefit to the size of user programs run, just more could be run on ELKS, since ELKS could allocate more physical memory by allocating more DS descriptors covering physical memory... In addition, the user programs could be protected from the kernel and vice versa... And that would be a big bonus, especially for embeded systems Luke(Boo) Farrar.
Re: Capabilities
On Tue, 1 Jun 1999, Chris Starling wrote: Why would anyone want to use any editor other than vi? I'm almost done with the EMACS port. :) But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package... Bcc. I think that its one of the things that needs porting the most. Why? Here's why. ELKS is shaping up quite nicely. We have a useable unixish system. But I think that it needs certain things: A C compiler. A nice(ish) way to install it. (ie, distribution) A decent text editor. Networking. Romability. (I think I just invented a new word! 8*) More standard unix commands. Protected mode stuff. (With Expanded memory support). Some of these things will be difficult (if possible), but I think that this is what we need to make it into a useable system. If people can use the thing, then they are a lot more likely to work on it / test it. Luke(Boo) Farrar.
Re: Capabilities
On Mon, 31 May 1999, Thor Harald Johansen wrote:
Is it possible to compile 'pico', the text editor, for ELKS? And does piping
work ('', '|' and '') properly yet?
--
Thor Harald Johansen
[EMAIL PROTECTED]
Pico would be great, but is is part of Pine, the email program so it
wouldn't be as easy to port as you might think. But It would probably be
doable. I always use pico myself.
Luke(Boo) Farrar.
Re: Capabilities
On Tue, 1 Jun 1999, Aidan Skinner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 1999, Thor Harald Johansen wrote: Is it possible to compile 'pico', the text editor, for ELKS? And does piping Pico is suprisngly large, it would probably be a lot more sensible to use a much smaller editor with more limited functionality. - - Aidan - -- How about a pico clone - It is pretty simple. Isn't it? Luke(Boo) Farrar.
Re: Distribution
On Fri, 28 May 1999, [iso-8859-2] Slavièek wrote: Does distribution that work ok 286 processors exist ? And if exist, where could I find it ?? Your in the right place. ELKS will work on the 286. Try ftp://ftp.ecs.soton.ac.uk/pub/elks Luke(Boo) Farrar.
Re: 0.0.76 Question.
On Sat, 29 May 1999, David Murn wrote: 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? Does any of it work? It seems to compile, but then the Image doesn't build properly. Luke(Boo) Farrar.
Re: ELKS port of nano-X ready
Nice one! Can't wait. On Mon, 24 May 1999, Greg Haerr wrote: Al, I have completed all the work that I can for the ELKS port of nano-X. We now have all the sources completely compiling on ELKS. I have written all the assembly routines for ELKS. I have a serial port mouse driver written that supports MS, PC and logitech mice. A keyboard driver that reads /dev/tty. An EGA/VGA driver that uses int10 to set the graphics and text modes, read the rom character font, and direct hardware access for all graphics stuff. We're ready to rock and roll! All the routines have been tested on other operating systems. DOS was used to test the EGA/VGA hardware driver. Linux was used to test the serial direct mouse driver. The serial routines are termios based. The makefile completely builds and links the project (44k), except that I don't have the declaration for select() in libc. If you can take this and declare select(), this should compile and run with no other modifications Let me know if you want the tarball... Greg Luke(Boo) Farrar.
0.0.76 Question.
I just got 0.0.76, but it keeps saying (every time I ls): Registering action 0 for signal 2 Registering action 0 for signal 3 Registering action 0 for signal 15 Al? Is it a config option? It doesn't happen using sash, but does with ash. And why doesn't 286 protected mode stuff compile? I'm just shoving my networking code start across. Not fun! Luke(Boo) Farrar.
RE: ELKS video drivers...
On Monday, May 17, 1999 8:44 PM, Ben Pfaff [SMTP:[EMAIL PROTECTED]] wrote: Greg Haerr [EMAIL PROTECTED] writes: [...] 11. DEC Rainbow range. [...] Does anyone want a DEC Rainbow? There's one in the basement with a 5 MB hard drive (maybe 10 MB?) and dual 5 1/4" floppies. Lots of software (mostly CP/M IIRC) including Zork I :-) It worked the last time I tried to boot it. Hmmm. Always looking for something new. (To me). I have an apple][, a bbc micro, a spectrum +3, PCW8256, PCW8512, 8088, 8086, 286, 286, 386, 386, 486 and a 486 But no DEC Rainbow! Luke(Boo) Farrar.
Re: ELKS Logo proposed -- the Antlered Penguin
On Wed, 12 May 1999, Curtis Weyant wrote: Hello, I'm new to this mailing list, but a friend and I have been working on getting an ELKS machine running for awhile. Anyway, the other night we were screwing around with some images, and we wondered why no one had taken the traditional Linux penguin and created an ELKS specific logo based on it. So, we did. Anyway, we basically took a penguin .gif from -- uh, well, from somwhere. The full sized origional tux is (if you wan't to play with it): /usr/src/linux/Documentation/logo.gif Penguins kick ass. They are also now the only other creature known to prostitute themselves. They get paid in rocks. I'm serious! Luke(Boo) Farrar.
Re: ELKS Logo proposed -- the Antlered Penguin
On Wed, 12 May 1999, Curtis Weyant wrote: Hello, I'm new to this mailing list, but a friend and I have been working on getting an ELKS machine running for awhile. Anyway, the other night we were screwing around with some images, and we wondered why no one had taken the traditional Linux penguin and created an ELKS specific logo based on it. So, we did. Anyway, we basically took a penguin .gif from -- uh, well, from somewhere (my friend got it), and added some antlers. We also took the liberty of modifying Mr. Riddoch's ELKS-LOGO.gif by adding our penuin onto it (hope you don't mind). Of course, I'll let the ELKS world decide if we've done a good thing. You can look at the pictures at: http://www.angelfire.com/ny2/dylan38/peng.html Laugh at 'em, download 'em, modify 'em, animate 'em, let me know what you think of 'em. I'm not a very technical guy, but I figured, hey, any way I can support the ELKS community and add my bit of creativity is good, right? What do you think? I think its the D's B's. Cute, yet Elky. I might have to make some antlers for my penguin here ;-) (Its a WaiYipToys one - #5.50 at www.linuxit.com).
Re: NanoX version 0.3 released
On Tue, 11 May 1999, Eric J. Korpela wrote: o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes. NanoX now runs on DOS! (OK, I did this only to see how portable nanoX is, and the mouse driver still isn't written) This still uses MSC graphics library. I'll have the bios int10 version driver done shortly, which will allow nanoX to run on ELKS! We should have an ELKS version shortly... BTW, the nanoX kernel is around 20k on DOS... Does anyone else agree with me that direct int 10 access is a mistake? Wouldn't access through a device driver be a bit more unixy? It would be able to prevent multiple processes from trying to access int 10 services. Eric What are the major bonuses of Int10 over the device driver? (If any). Luke(Boo) Farrar.
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
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.
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.
Re: Intro
On Thu, 18 Nov 1999, Giles Russell wrote: David Murn wrote: 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. OK, call me stupid, but how can I get to the CVS tree ??? 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. Agreed, but for initial coding, it may be best to run in user space till code fairly near to completion. Who is Beau Kuiper, and is he still working on the networking stuff ??? Or is David working on it These may seem like simple questions, but I am getting the feeling the docs are little out of date :) Beau Kuiper isn't doing the Networking stuff anymore. I'd love to help, but right now I just don't have the time (I need to work my ass off or I'll get kicked out of school). I had started an ne2000 driver, but it apears that is is no longer required. I don't know how to link the userspace stack to the kernel, but I could help with the stack itself. Luke(Boo) Farrar.
