Cool. Thanks. Ummm.. do you know of any drivers for DOS that provide
access to an NE 2K and provide a TCP IP stack... and I've never directly
interfaced with a TCP/IP stack before. All I want to do is be able to
send and receive from one PC to anotother (and back from the another PC
to the one PC :-)
Would you guys _happen_ to know where I can get d/l a TCP IP stack
driver, an NE 2K driver, and get docs _or_ a high-level library that
lets me actually do interfacing?
Let's, like, make this a sub-project of plex86. After it's good enough
we can submit it to Kevin as a plugin. What it will do is use only a few
of the plex86 emulated devices; the rest will be implemented via
interactin with an actual PC. This will allow for a kind of
virtualization and debugging you couldn't otherwise do: what if you need
to see the way a program will run under a non-emulated device that you
have in the real world but don't have a clue how to emulate? Or what if
you want to diagnose a problem with an SVGA driver?
Plex86 provides for spectacular debugging capabilities but only with
hardware devices that can be emulated. If you want to fix a Linux SVGA
driver, using the flexibility of a virtualized environment, how are you
going to do that, short of plugging in a second SVGA card (or an MGA
card)? By using what this.
-Willow
PS> Anyone want to contribute? Aside from what I mentioned above what we
also need is a _name_ for this. Sub-projects need names, you know. Who
named plex86?
Oh, you can also run Windows and analyse it under "real world"
conditions so you can do quality-control on Windows applications.
Suspect a Windows app is doing something fishy with your hardware? If
your hardware isn't something we know enough (and care enough) about to
emulate, this is _the_ way to find out.
BTW, I wonder if it would be possible to shift the load, so to speak, of
things like paging hardware by doing this? A miniture DOS kernel,
perhaps based on FreeDOS, would run on a separate PC.
You could even have a program analyse drivers under real-world
conditions. Plex86 already allows for this but this would provide a
means to enhanve plex86 further: after analysing chipsets we could
eventually learn enough to emulate them! I think this is _the_ thing to
do until we emulate an SVGA chipset.
"Timothy J. Massey" wrote:
>
> On Thu, 24 May 2001 23:09:40 +1200 (NZST), Arnim Littek wrote:
>
> >On Thu, 24 May 2001, Willow Schlanger wrote:
> >> There will be _no_ OS on one end (the "slave" PC) but on the other end
> >> there will be an OS that lets me directly program the thing.
> >
> >You'll buy a certain amount of leverage if you use TCP/IP across the
> >link. A lot less farting around at the master end. It does mean you
> >need a small OS with a TCP/IP stack at the other end. Then you start
> >using existing tools, which makes life a whole lot easier, and still a
> >damn sight faster than bit bashing a parallel port...
>
> Even if the remote OS is DOS and you use packet drivers. That way, you
> don't have to know the internals of the NE2000, and you have "a small
> OS with a TCP/IP stack at the other end." It's kind of the best of
> both worlds. AND, your setup is a little more flexible than being
> hard-coded for the NE2000. You can use different NIC's: in fact, any
> NIC with packet drivers.
>
> With UDP packets in such a situation, you should get 90%+ of what you
> could have gotten with your own custom-developed driver/protocol
> solution, and a whole lot more. For example, you'll have the ability
> to route this data, which means that the computers don't have to be
> next to each other (but you still want a lot of bandwidth, so that kind
> of rules out the Internet). There are all kinds of benefits to this.
>
> Tim Massey
