-------- Original Message -------- Subject: Re: [Fwd: Re: plex86 guest os (video) drivers] Date: Thu, 24 Aug 2000 11:34:59 -0800 From: "Kendall Bennett" <[EMAIL PROTECTED]> Organization: SciTech Software, Inc. To: [EMAIL PROTECTED] CC: Kendall Bennett <[EMAIL PROTECTED]> Hi Jeroen, > Where can I find the XFree86 shell drivers so I can have a look at > it? Well our XFree86 shell driver is so out of date at the moment that we have not released it. We are in the process of updating it to work with XFree86 4.x and the latest Linux distributions, but the progress is slow (the developer is a part time contractor at the moment, and I don't have any developers here that can work on it fulltime). > btw, is anyone "allowed" to write binary portable device drivers? If you are asking if anyone is allowed to build Nucleus compatible drivers, the answer is no. At least at this stage, since our new technology is still in it's infancy. We may open it up at a later date, but it all depends on finding a business model that works if we do that (to keep our investors happy ;-) > > The most likely scenario as I see it, is that the actual drivers to > > control the hardware are loaded only by the virtual machine system > > (ie: plex86), and shared by all guest OS'es. Then the guest OS > > drivers talk to the VM hardware driver via some kind of RPC mechanism. > > hmm... let me try to understand this, are you talking about plex86 > loading hardware drivers for the hosts display adapter and guest > os'es can have "direct" access to the *real* display adapter > instead of "emulating" something? For software rendering, yes (ie: the guest OS driver can directly write on video memory if it is running in the foreground in fullscreen mode). The drivers wouldn't be directly accessing the display hardware from the guest OS, but rather sending commands via RPC to the plex86 system (which has the hardware drivers loaded). Due to the way we have designed our system, the guest OS will have full services for caching bitmaps in offscreen memory etc, which could be shared across all guest OS drivers. It should even be plausible to allow the guest OS direct access to the video memory on the surfaces that it owns. Then when a guest OS driver needs to blit something from offscreen memory, a quick RPC calls into plex86 would then trigger the actual hardware blit. With the above architecture you would have the maximum performance possible from a virtual system. Note however that for this to work, the host OS itself would also need to be running our display drivers (for direct access to our Nucleus internals), or plex86 would need to be running in a fullscreen console mode on the host OS so it has direct access to the hardware). > > It sounds like an interesting project. VMWare intrigues me, but I > > can't play with the internals at all, so plex86 sounds interesting. > > Well, I noticed you've been also busy with x86emu, so that's also > a reason why I contacted you :) I haven't touched x86emu in some time, since now it works aboiut 97% for the stuff we need it for. However now that bochs is LGPL, I have been seriously considering looking at switching our emulator needs to bochs, since I believe it is a much more full featured emulator than x86emu is (in terms of processor instruction support that is; we only need it for POST'ing the video BIOS on secondary controllers ;-). Regards, +---------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +---------------------------------------------------------------+ | Kendall Bennett | Email: [EMAIL PROTECTED] | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +---------------------------------------------------------------+
