Re: test
Hi there. Is there any one who is using the linux kernel with tcp/ip stack Most people who use the Linux kernel do just that. However, very few of them are on this mailing list... Best wishes from Riley. * Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
Hi David. 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'. There is a little more than that involved: 1. When checksummed over the length of the ROM, the checksum must be correct. 2. There were TWO entry points to each ROM that had to be in the correct place. One was the initialisation entry point, the second was the "DOS Extended Commands" table, which consisted of a table of additional DOS commands together with the offset of the command within the ROM. Miss those out and you can expect your ROM to cause problems... 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 implant a ROM in there). 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. Very true, and I will definately second this recommendation. Best wishes from Riley. * Copyright (C) 1999, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
Re: KISS networking for elks
Hi David. Aren't some people working on network drivers? Are they at the stage where we can transmit and receive ethernet frames yet? I'm not sure, but the sooner it's working, the better IMHO. One good use I can see for networked ELKS is as a print server for the network. Basically, all that requires of the operating system is: 1. Support for a single network connection. It matters little whether this is ethernet, token ring, SLIP, PPP or PLIP. 2. Support for a single printer connection. It matters little whether this is a serial or parallel printer. 3. Plenty of space for spooling documents to be printed - the more the merrier as far as this application is concerned. 4. A userland print spooler daemon that receives documents in a ready to print format and sends them to the printer. Note that the following additional facilities would all be useful, but NONE of them are required: 5. A userland print spooler daemon that receives documents in Postscript and converts them to the format required by the attached printer. 6. The ability to connect two or more printers to the same print spooler. 7. The ability to handle two or more network connections. Before anybody asks, I was working on the print spooler daemon, but lost my work when my hard disk failed. Right at the moment, I'm in no position to do anything on it, but when I can, I will try to do something along those lines. Best wishes from Riley. * Copyright (C) 1999, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
Hi Alistair. Not really--All I know is that PCs and XTs fell back on cassette BASIC when the disk boot failed--AMI BIOS still makes a call to it when it fails, but the BASIC roms don't exist in post-8088s. It does seem intriguing, though. I'll see what I can come up with. I have come across a few old machies that had sockets like this, but never one that actually had a BASIC rom in it. I don't know what the ROM in this socket needs to contain in order for the BIOS to recognise it as a BASIC ROM and run it if boot fails. Interestingly enough the ELONEX 486DX33 I use for testing ELKS alot of the time has cassette BASIC built into its BIOS. I only found out by accident because I took out the harddrive. If I remember right the bios setup replaces the basic, On my 386, if you call basic (with an int or someting, did it years ago and can't remember) the bios setup loaded. The original IBM PC's had basic on a rom, but I do not know how big the rom was. The Elonex definatly has both a BIOS setup program and BASIC. I will see what docs I can track down on this. The original setup was actually quite simple, and worked as follows: 1. On power-up, the CPU switches itself into Real mode and starts running the BIOS POST routines. 2. After completing the POST, the BIOS scans through the rest of the BIOS area looking at every 4k boundary for the relevant "Extension ROM marker". a. When it finds one, it looks at the adjoining "ROM length" field to determine how large the ROM is supposed to be, then checksum's the ROM area. b. If this checksum is zero, it assumes the ROM is valid, and calls the "initialise ROM" entry point for that ROM. c. The ROM BASIC pointed this entry point to a routine that inserted a call to the main ROM BASIC entry point in the INT 0x18 vector. 3. Once the ROM SCAN was complete, the BIOS starts its "Find OS" loop, which works as follows: a. If the ROM SETUP has options for it, the list of valid boot devices can be set there. If not, the default is "Primary floppy" then "Primary hard drive". b. For each device in the list of valid boot devices, is it present with media in it? If so, load its boot sector and boot from it. If it ever returns, go to step (b). c. If we fall through, execute INT 0x18 to do whatever that feels like doing. There are various other ROM's that can be plugged in, and all use this same mechanism. Among the ones I'm aware of are: 1. Most Video BIOS's. 2. One to require the user to type in a password before the user can continue. Most modern BIOS's have this internal to the BIOS but it can be added to those that don't. 3. Hard drive controllers on the XT included a controller ROM that worked this way. 4. As far as I know, network boot ROM's work this way as well. Hope that helps. As for interrupt assignments, the following URL comes in handy: http://www.ctyme.com/rbrown.htm Best wishes from Riley. * Copyright (C) 1999, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/
Re: SV: Capabilities
Hi Thor. Depends on the shell you're using - I believe sash doesn't implement pipes yet, but I'm not sure about any other shells... There are other shells? I have heard rumours that there's a version of ksh working for ELKS, but I've never managed to track it down... Other than that, there's just the 'shell hacks' (as I call them), where somebody writes a C program that displays a menu on the screen, waits for a valid keypress, then executes whatever command has been associated with the relevant menu option by the programmer. If there are any ELKS shells other than those, and any reader of this email both knows of them and where to find them, YELL BY EMAIL!!! Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: Capabilities
Hi Thor.
Is it possible to compile 'pico', the text editor, for ELKS?
No idea, sorry.
And does piping work ('', '|' and '') properly yet?
Depends on the shell you're using - I believe sash doesn't implement
pipes yet, but I'm not sure about the other shells...
Best wishes from Riley.
+--+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+--+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
RE: ELKS video drivers...
Hi Shane. 9. Tandy 1000 range. I think that the Tandy 1000 was a CGA+ mode, with the idea being to provide 320x200x16 without a full EGA mode. So we have the old 640x200 standby here, too. Having had a Tandy 1000, I can safely say that whilst it did indeed have a CGA+ mode that was nominally 320x200x32 (yes, x32), it did NOT have a 640x200 mode. However, it DID have an oddball mode of 480x240x4 available, although I'm not aware of anything much that used it. Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
ELKS video drivers...
Hi there. AFAIK a BIOS, like I said before, is specific for one and only one chipset. Not true: an XT BIOS is specific to a particular combination of chipset and glue logic, not just the chipset itself. Taking the Tandy 1000 range as an example, they differ from the standard PC range in using part of system RAM for video RAM, and had special non-standard glue logic to implement this, but they used the same chipset as many other 8086 clones of the time. One obvious example is the Tandy 2000 range, which used the same chipset with different glue logic, and the BIOS's of the two machines were not interchangable... And I think the answer is writing a video driver for every different type of system. Linux does this precicely because it is unable to use the BIOS in protected mode, but the simplest form of video driver is simply to have the kernel driver use the standard INT 10h routines provided in all PC compatible BIOS's, and present a standard API for other programs to use. Granted, one could add drivers for specific hardware, and have the kernel routine detect and use it in preference to the BIOS driver if the relevant driver is present, but I wouldnae see such as a first choice for getting a working video subsystem... Whilst we're on the subject, let's enumerate the various different video subsystems we may need to handle, assuming a genuine XT clone of some sort: 1. IBM MDA. 2. Hercules MDA. 3. CGA. 4. EGA. 5. MCGA. 6. XGA. 7. VGA. 8. Assorted SVGA modes - how many are there now? 9. Tandy 1000 range. 10. Tandy 2000 range. 11. DEC Rainbow range. 12. Olivetti computers ??? Others, anybody? Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: Amd186 ELKS
Hi Li. I'm a newbie for this discuss group. I have developed a intelligent network interface card using Amd186 micro- controller and AMD Pcnet 10Base-T network controller. I am looking for a embedded linux-like system supporting TCP/IP stack. I reviewed the source codes and documents of ELKS project. I noticed that all versions of this project only supported floppy driver boot. How do I boot the ELKS from ROM? Make ELKS think the ROM is a floppy? That's how the Tandy 1000 series of PC's did that trick, and modern PC's do similar tricks to enable boot from CD-ROM - they turn the relevant file on the CD into a virtual floppy... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
ELKS from ROM
Hi Alistair. As far as I am aware noone has yet booted ELKS from ROM, and if you wanted to do this you would have to write your own bootstrap code, and tweak the kernel to work from ROM. The actual kernel data and code are compiled an linked into a file called System which can be found in the arch/i86/tools directory. It is a minix format binary which is fairly easy to deal with. The are a few places in the kernel where it is necessary to write to the kernel code segment, but these can be removed if you know the physical location at which the data segment will be located. All the code does is store the kernels data segment so that it can retrieve it later after an interrupt has occured. One possible way round this would be to reserve one of the interrupt vectors for this, and use something like the following, assuming the vector for INT 255 was chosen - I'm using Intel opcodes here as I'm not yet familiar enough with the Linux versions to be happy: Q ; Initial code which gets the kernel data segment in DS at a Q ; point where the contents of ES and AX are irrelevant. Q Q ; Store DS:0 in INT 255 vector Q Q XOR AX,AX Q MOV ES,AX Q MOV SI,0x0FF0; Change to suit = 16 * vector chosen Q MOV ES:[SI+0],AX Q MOV AX,DS Q MOV ES:[SI+2],AX Q Q ; Rest of ELKS kernel. Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
RE: BIOS get code
Hi Raude. I just writes out 64k at 0xF000:0 to 'bios.rom'. I tried your program on my hp200lx , it's ok. If someone wants to have a look at its bios, I can send the file. If you can, I'll have a look at it and see what I can work out... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: plip for elks?
Hi Jonathan. We're gonna need a tcp/ip stack first. A plip driver won't be that hard, but we need something for it to sit on. The problem with PLIP in ELKS will be finding XTs with bi-directional parallel ports. Whilst PLIP will make good use of bidirectional parallel ports, it doesn't need them as it can use the so-called LapLink protocol that turns a unidirectional parallel port into a bidirectional 4-bit port. Memory says it makes use of five of the status lines as inputs that are connected to five of the data lines at the other end, and that gives four data lines and a strobe signal each way. And finding 8-bit parallel add-on cards that support bi-directional transfers. Given a 286 based system, the 16-bit EPP cards that are common in the local emporiums round here can easily be used, so that's unlikely to be a headache... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: ELKS Networking
Hi David. Most cards that don't need the 16-bit bus don't come as 16-bit cards with the exception of those cards that are specifically designed otherwise. Actually, there's a reason for some coming as 16-bit. That is simply because they're capable of using IRQ 7, or other extensions like that. They still only use the 8-bit data bus though. I proved this when I put a 1mb trident card into my XT. The XT got it into 640x480x256, and was capable of detecting/checking the full video memory. Memory says that the 16-bit extension connector was designed to enable cards to auto-detect whether they're inserted into an 8-bit or 16-bit connector, but few cards made use of this facility... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: How to: unsubscribe
Hi David. [EMAIL PROTECTED] acts like a black hole. It is. Try [EMAIL PROTECTED] instead. Perhaps somebody should make the former an alias to the latter at vger... Best wishes from Riley. --- * ftp://ps.cus.umist.ac.uk/pub/rhw/Linux * http://ps.cus.umist.ac.uk/~rhw/kernel.versions.html
