John T Kohl <jtkohl@cs.berkeley.edu>:
quoted text
> Anybody working on GNU emacs?  "em" is passable, but I'd like the real
> thing...

I'd be interested to hear about this too..  I haven't got the disk-space
to try to port it myself, but judging from the ease of porting other GNU
software it shouldn't be too difficult.  Of course, emacs is rather big,
and probably wants some features...  ? If anybody gets a working binary
(and no, I don't think we need all the features: gif-viewing, mail, news
etc :-), I'm sure it could be set up for ftp somewhere (both nic and
amaru accept incoming ftp: nic in /pub/OS/Linux (but it won't show up
immediately), amaru in msdos/replace/incoming or something like that). 

quoted text
> In other news, I have now been able to observe program execution speed
> differences when I toggle the Turbo switch (easiest to observe by
> scrolling lots of text on the console).  So it's probably some sort of
> timing glitch that prevents booting at full-speed?

Do you have any problems at all using the floppy or harddisk later on?
It might be that linux uses the IO-ports too often (there are usually
(always?) two "jmp $+2" between IO instructions, but on a 33MHz 486 this
isn't too much of a delay). I cannot imagine what other timings might be
wrong (but if I have forgotten "jmp $+2" somewhere, it's probably in the
early code, ie the one that is used at bootup.. I'll check)

mgfrank@acsu.buffalo.edu (Marc G. Frank):
johnsonm@stolaf.edu (Michael K. Johnson):
quoted text
> [ mtools ]

This has been said before on this forum, but it seems there are enough
new linux-activists to rehash the problems with mtools:

1 - you have to tell mtools which device to use. This is done by linking
(or mknod'ing) the files /dev/dos[A|B|C] to the correct device. (ie
mknod /dev/dosA b 2 28 for a 1.44M dos floppy in A etc).

2 - linux-0.10 doesn't support reading/writing from partitions >64M. Be
VERY careful if you write to such a partition: the blocks wrap around at
65536. This is easily fixed (I think): change the unsigned short b_blknr
in buffer_head to unsigned long, and recompile the kernel. I cannot test
it (both my harddisks are <64M), but this should work. Thanks to xxxx.

3 - due to the bug in /usr/include/ctype.h (tolower), mcopy isn't able
to do things like "mcopy 'a:*' .", as the names get confused.  You'll
have to give the new names explicitly, or recompile the mtools with the
corrected ctype.h (mtools source can be found at nic.funet.fi:
pub/unix/i386/isc/source/mtools* and from several other ftp sites)

4 - /dev/dos[A|B] is hardcoded to 12-bit fats, /dev/dosC is hardcoded
for 16-bit fats.  There is no /dev/dosD etc.  If you have a small
harddisk (12-bit FAT), you have to call it A or B. 

Btw, mtools is not really needed: you can write a tar-file to disk with
the rawrite program, and use "tar xvf /dev/xxxx" to untar it unto the
linux partition.  Thanks to "whoever" for pointing this out (and I hope
nobody minds the fact that I never remember names)

nicholas@cs.uwa.oz.au (Nicholas Yue)
quoted text
> 
> 	(i) 80386 with 80287

I've tried to get a 287 working with linux, but no luck so far.  Does
anybody know anything about the problems with 287? I tried to put it in
protected mode (FSETPM), but that didn't seem to help.  I seem to be
able to correctly identify it (check for a x87, and if ET is cleared,
it's a 287), but it simply won't work it seems? Any pointers to it? Is
it at all possible to use a 287 in 386-protected mode?

Again I have the problem that I cannot test my changes: the few
(unsuccessful) things I tried had to me mailed to nicholas. 

jtkohl@antipodes.Berkeley.EDU (John T. Kohl):
quoted text
> 
> It seems whenever I type control-U while in a program, the console bash
> dies and the system grinds to a halt.  bug?  feature?

This is an old debugging tool I think.  I was testing the keyboard
interrupts, and got cc_c[VKILL] to send a SIGKILL to the processes in
the tty-group.  I used ^U as I never use it myself for other things, and
thus promptly forgot about it when it worked.  I should make VKILL work
the right way (ie just kill the line in cooked mode(?)), but an easy fix
to this would be to comment out the line in tty_io.c that calls
tty_signal or whatever, and recompile the kernel.  Thus you could call
it a "feature", even though it isn't documented anywhere (unless you
count the sources as docs, which might not be a bad idea anyway). 

		Linus

PS.  I think I have found the "Invalid TSS: 0000" error that a couple of
people have got after soft-booting from DOS: possibly the eflags NT-bit
was set, in which case an iret would try to change to TSS 0000, which
doesn't exist.  It should be corrected in the next version (again, I'm
unable to test it - I don't get that error).