Subject: PLIP [was Re: PC Emulation w/bochs - notes]
To: None <netbsd-help@netbsd.org>
From: Gary Thorpe <gathorpe79@yahoo.com>
List: netbsd-help
Date: 01/08/2004 21:43:00
 --- Andy R <quadreverb@yahoo.com> wrote: > --- Richard Rauch
<rkr@olib.org> wrote:
> > Re.
> >
> http://mail-index.NetBSD.org/netbsd-help/2004/01/08/0001.html
> > 
> > I'm not sure what you are asking.  BillOS does PPP
> > and BillOS does
> > SLIP.  
> 
> Ahh, pardon me. Brain fade. I've been on ethernet for
> so long that I forgot about serial line antics. I only
> ever set up a modem like once under *nix and I think I
> did SLIP and PLIP once or twice to amuse myself. I
> think Windows might even do PLIP with some coaxing.
> Which might be better than SLIP on a guest OS? I have
> a PLIP cable sitting here from the old PC anywhere
> days... I think that's what they used? 

I don't think windows can do PLIP: it supports data transfers using a
parallel cable but it isn't PLIP as far as I can tell (crynwyr packet
driver under ms-dos would provide PLIP). NetBSD has several PLIP
patches (most are outdated) and one which is against NetBSD-current
(within the last month or so):

http://netbsd-ppbus.sourceforge.net/

has more details (I work on this project). This requires applying
patches to the current source tree, so it probably isn't for everyone.

> 
> > Since my understanding of how bochs handles network
> > interfaces would
> > be pretty unreasonable to set up, I am probably
> > wrong.  I just didn't
> > see an alternative interpretation.  (^&  I certainly
> > haven't *tried*
> > it.
> 
> If Bochs CAN work similar to vm ware, then it's a very
> slick setup that's worth using. I'll have to struggle
> for a while and see what comes of it. If PLIP or SLIP
> is easier, then maybe that's the way to go. It's going
> to be slow though.

PLIP will probably be much, much, worse as the hardware does 0% of the
handshaking (it is very CPU intensive on a real machine). It is much
faster than SLIP thoguh.

> > As for usability, it's pretty limited even on a 2GHz
> > AMD64 (AMD64 "3200").
> > Though your impression seems to be much more
> > favorable on the performance
> > penalty.  I wonder if a dual CPU helps in some
> > subtle way?  Or maybe
> > you've turned up the optimization levels somehow?
> 
> Haven't played with optimization at all really. On the
> NetBSD guest, I used the pit: enable=1 option so that
> the keyboard worked. It responded like faster a 486 or
> so, but this is a command line OS. It was usable in
> command line mode, let's say. Grimdoze was S-L-O-W,
> and of course the mouse didn't work... Which limits
> it's useability greatly. Still have to try a newer
> version of bochs to see if they worked on this.

BOCHS does pure emulation: it will never approach vmware because vmware
just excutes the majority of the code natively (which is why it isn't
portable). There was some work by DEC to get x86 code running fast on
the alpha (I think it had something for NT specifically), but I don't
know how reuseable/protable their work was. And Macs had (has?)
VirtualPC which was (is?) supposedly fairly fast for emulation.

> 
> > If you find out why plex86 was yanked from pkgsrc,
> > I'd like to know.
> > I commented on that, I think, in my original post.
> 
> There was that stabilization effort that happened not
> too long ago, wonder if it was a casualty of that...
> In any case, I may just compile it like in the old
> days (sheesh how I love pkgsrc) and see what happens.
> 
> <tangent>
> From what I'm seeing, bochs would fulfill one of the
> project's claims which is if someone has some program
> sitting there on an ancient 386 or 486 that's still in
> production and everybody is scared to touch, it could
> probably be emulated rather nicely on a modern *nix
> machine. Especially if it doesn't rely on any
> particular piece of hardware. And I know of these
> situations. Probably thousands of "mom and pops" had
> these *new fangled* computers installed years ago and
> are still doing some job just fine. Until the machines
> die, of course.
> 
> The only problem seems to be bochs's appetite for CPU
> time, but CPU is cheap depending on who's asking who
> and who's buying what.
> </tangent>
> 
> Andy

The other problem is the accuracy of the emulation and device drivers
(for the emulator).

> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus 

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca