RE: ELKS 0.0.78 released
At 09:42 AM 7/20/99 +0100, Luke (boo) Farrar wrote: >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. > OK, I tried booting from the 720k disk image on my P-120. It works fine. Surprisingly, it uses a PS/2 style keyboard (with the narrow mini-DIM connector). I tried RaWriting the 360k images to 2 other disks I found and it still doesn't work on the XT clone (with the fat DIN keyboard connector) I really can't diagnose what's going on here, since I'm a ChemEng by training and don't know the first thing about OS design. I do remember getting to log in on the same machine back when the version number was something like 0.68. so I think the machine is OK. I don't even have access to a Linux machine at work to make new images myself. I'm just hoping to put some of the old 8086/8 and 80286 machines back to work, and the limit of my contributions to the project is trying to use the new images and letting the list know when something isn't working for me. Thanks, Jeff
Re: Herc in Microwin
On Tue, 20 Jul 1999, Thomas Stewart wrote: > I am not realy an expert, but a v20 is faster that an 8086/8088 so it might > be worse on those. All that I can think of doing is 1.adding 8087 support > 2.speeding up code 3. anyone else have ideas?? A V20 is a bit faster than an 8086. However, except for with benchmarks, I don't think the difference is meaningful. I'm pretty sure that adding 8087 support would be pretty useless, since there wouldn't be much floating-point going on. To make things faster, the code would probably have to be sped up. (Windows 1 didn't take 10 minutes to load!) pat
Re: 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. It saves me 40 spams a day. It also encourages the admin of sites that are a problem to fix them. Also orbs blocks specific hosts only. They dont block a domain because of a single host
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
fs cleanup in ELKS
Al, I just noticed you're cleaning up a bunch of fs code in ELKS. I have been reviewing the original linux sources, and I think I've noticed an error in the #ifdef BLOAT_FS stuff in ELKS. The problem is in elks/fs/buffer.c, 22 lines into the function getblk(). There is a comment made by the person creating the BLOAT_FS stuff, and he #ifdef'd out the a repeated find_buffer call, saying he thought it was redundant. Well, Linus says in his 0.01 kernel in the same function: /* NOTE!! while we slept waiting for this block, someone else might already have added this block to the cache, check it */ I think this is a bug, and could cause a major buffers bug if ELKS ever ran multiple tasks that read and wrote the same buffer. I suggest we uncomment it out and leave it in. There's really no harm in leaving it there, considering the comment when commenting it out: /* I think the following check is redundant so I will remove it for now*/ Greg
RE: Herc in Microwin
On Tue, 20 Jul 1999, Greg Haerr wrote: > : On the down side it did take a little long for it to load, try 10 min! > : So if it is to be used the code has to be somewhat speeded up. I did not try > : to move any windows because I did not have a mouse pluged in and it would > : have taken too long. > > Uh-oh. Scratch the above comment. You mean that it took > 10 minutes to *draw* the screen! (laughing in background, peers looking > at me very strangely...) Well, we definitely need that HERC_drawhline > to be implemented, because now it calls HERC_drawpixel for *every* pixel > on the screen, all 252,000 of them. I can take a hack at rewriting that, > but It'd be nice if someone with a card did it. The file is >mwin/src/drivers/scr_herc.c. > Ok. I'll do it, since I already have code doing the task "optimally", (how can one be sure anything is done optimally?) if I understand it correctly. (I am not the brain behind the algorithm.) (Guess I'll have to put that Herc. card in a machine then... huhm...) Regards, Jakob Eriksson
RE: Herc in Microwin
On Tuesday, July 20, 1999 2:39 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : I fired up my old beast last night, a v20 640k with a herc card, I ran my : compiled copy of microwin with herc support, and it worked! : : WELL done to greg and whoever helped write that driver! : Unbelievable! That's the *second* time I've written a Microwindows/Nano-X screen driver and it's worked without having any hardware to run it on!!! Also big thanks to Jacob for sending me his sample Hercules code, which was very easy to understand. : On the down side it did take a little long for it to load, try 10 min! : So if it is to be used the code has to be somewhat speeded up. I did not try : to move any windows because I did not have a mouse pluged in and it would : have taken too long. Uh-oh. Scratch the above comment. You mean that it took 10 minutes to *draw* the screen! (laughing in background, peers looking at me very strangely...) Well, we definitely need that HERC_drawhline to be implemented, because now it calls HERC_drawpixel for *every* pixel on the screen, all 252,000 of them. I can take a hack at rewriting that, but It'd be nice if someone with a card did it. The file is mwin/src/drivers/scr_herc.c. : : I am not realy an expert, but a v20 is faster that an 8086/8088 so it might : be worse on those. All that I can think of doing is 1.adding 8087 support : 2.speeding up code 3. anyone else have ideas?? The problem is definitely in HERC_drawhline. Rewrite it to draw the horizontal line directly, rather than call HERC_drawpixel. Greg
RE: ELKS 0.0.78 released
: 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. : If anyone wants another bios kbd reader that works, you can check out my bios code in microwindows mwin/src/drivers/kbd_bios.c and elksutil.c Of course this code would have to be replaced into the bioscon.c kernel code. Greg
RE: ELKS 0.0.78 released
: > What is so special about ps/2 keyboards? : : They have blue electrons running thru their chips :-) : That's true. Normal electrons are greenish-gold.
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
Re: ELKS 0.0.78 released
> 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. I have already suggested to use BIOS console instead of direct one on PS/2 machines long time ago, but noone tried it. DOS uses BIOS IMO and if DOS works ELKS should work too. 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). > What is so special about ps/2 keyboards? They have blue electrons running thru their chips :-) bye, Ab
Re: compiling 0.0.78
Greg Haerr 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? > : > > Likely the problem is the link -s is missing in the /usr/bcc/include for the > arch and linuxmt dirs. > This should be totally irrelevant when compiling the kernel. The -nostdinc option means that bcc should no look in /usr/bcc/include for header files. Al
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 > > >
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.
