Re. http://mail-index.NetBSD.org/netbsd-help/2004/01/08/0006.html

I'd think that for software communications, it wouldn't matter a whole lot.
Doing PLIP might require emulating more control lines (not sure).  For SLIP,
I think that the common case is 1 start bit, 8 data bits, one stop bit,
no parity, and hardware (RTS/CTS) flow control, with the application not really
caring about the start/stop bits beyond setting up the serial port.

This means that a serial port could be an awful lot like a socket, which
might make it easier to pull off SLIP with minimal overhead.

The other thing is that NetBSD doesn't support PLIP.  I don't know if that
would be a real obstacle as long as you're not reading a real parallel port.

I think that the only advantage that PLIP offered was that it went over the
parallel port, which was faster than the serial port (by virtue of sending
data in parallel rather than in series...(^&).


Funny that the mouse doesn't work for you in bochs.  It works for me.
I *did* have a problem with my disk geometry (now fixed): I used heads=120
to increase the capacity.  It seems that that exceeded some expectations
of the NetBSD bootloader (and possibly is why I had problems with Knoppix
booting, too).

I'm trying to get a decent NetBSD boot, now.  I may have to go with
"pit: realtime=1", but am hoping that setting "ips: 54500000" (54.5 MIPS)
will do better.  My impression is that I/O gets *really* bad with realtime=1,
but that may just be a natural side effect of having an accurate clock,
and not be inherent in the way that bochs sets the clock.

(54.5 MIPS is a slightly high estimate based on NetBSD's kernel messages
as I combine ips: and pit: options---ips: seems to be an initial value,
which pit: adjusts.  The "real" value is probably between 54 and 54.5 MIPS.)


With decent ips: setting, NetBSD seems to take forever after figuring out that
the root filesystem type is ffs.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/