I've setup a website at http://sf.net/projects/win9xbox as a place to put all the patches for windows/glide support into a working and stable DosBox tree. The idea is to create a version of Dosbox which easily handles installing windows 3.11, 95, 98 and possibly ME, so that people don't have to try patching the source code themselves. This should make management of the windows specific patches easier.
wrote:I've setup a website at http://sf.net/projects/win9xbox as a place to put all the patches for windows/glide support into a working and stable DosBox tree. The idea is to create a version of Dosbox which easily handles installing windows 3.11, 95, 98 and possibly ME, so that people don't have to try patching the source code themselves. This should make management of the windows specific patches easier.
Glad to hear that! I made the DOSBox-X branch on my site http://hackipedia.org/Projects/DOSBox-X/. I haven't had time to work on it, but I would be willing to help incorporate the improvements I made in keyboard emulation, PS/2 and serial mouse emulation, Sound Blaster emulation and ISA PnP emulation which works fine with Windows 95. I also started ATAPI IDE emulation, and I got it to work well enough that Windows 95 is able to see a CD-ROM drive.
I can say for certain that you can already run Windows 3.11 fairly well in DOSBox. Win95 (up to OSR2) is also possible, you have to use a specific core or else you will see plenty of mysterious faults. Windows ME will definitely NOT work, I've tried. It doesn't crash, but the installer goes into an infinite loop that never completes. Don't use the S3 driver, it will crash DOSBox. I like to use machine=vgaonly to install, and then install the vbemp driver to get SVGA graphics.
Really a good concept! DOSBOX should be capable to smoothly emulation of Win9x, because there's no alternative for that (VMWare and Virtualbox have support for 3d accelerated graphics for NT-based Windows only) and this is really frustrated.
I always thought of making something like this 😁
That was the plan:
- adding opengl-accelerated 3dfx patch (coming on official dosbox, sooner or later)
- adding that patch for support for >2gb disks (a must!)
- adding ata interface patch for booting/reading cd-roms from win9x (someone already developed this)
- hiding dosbox console by default
- create a launcher app, cloning the VirtualPC console (it's very simple), where you can create machines (dosbox conf files in our case) and manage disk images
Kekko, you had a great support for making possible using 3dfx under Windows/DOSBOX and thousands thanks for this. If you will complete emulation of 3dfx under Windows/DOSBOX, you will be simply DOSBOX-god for me 😀
This is probably not the most appropriate thread, but given you're talking about the emulation of the win9x environment I'll ask anyway:
My limited programming knowledge tells me that all natives games since windows 95 should be communicating with the hardware exclusively using the windows drivers and (excluding glide games ) the direct-x layers, right?
So, instead of emulating an existing Direct X board (and obtaining the required copyrighted firmware or binary blob) , wouldn't be easier to just write a windows reference driver that just translates the graphic calls to something a modern opengl-capable videocard would render?
This way you could avoid some of the incompatibilities brought by the original hardware with some games. My voodoo card was not exactly a great direct-x 6 hardware, and almost every pre-Nvidia TNT card had his own quirks when dealing with Direct X.
I known that this sounds more similar to a wrapper / HLE solution rather than an emulated device that just returns a complete framebuffer - which is what kekko's voodoo emulator looks like - but from what I understand no games should be dealing with even lower-level calls bypassing the windows driver, right? I mean, I'm talking about VXD driver level - not an higher level replacement like wined3d.
I'm sure that some Demoscene stuff won't work this way, but would this approach really compromise the compatibility of any game?
wrote:This is probably not the most appropriate thread, but given you're talking about the emulation of the win9x environment I'll ask […]
This is probably not the most appropriate thread, but given you're talking about the emulation of the win9x environment I'll ask anyway:
My limited programming knowledge tells me that all natives games since windows 95 should be communicating with the hardware exclusively using the windows drivers and (excluding glide games ) the direct-x layers, right?
So, instead of emulating an existing Direct X board (and obtaining the required copyrighted firmware or binary blob) , wouldn't be easier to just write a windows reference driver that just translates the graphic calls to something a modern opengl-capable videocard would render?This way you could avoid some of the incompatibilities brought by the original hardware with some games. My voodoo card was not exactly a great direct-x 6 hardware, and almost every pre-Nvidia TNT card had his own quirks when dealing with Direct X.
I known that this sounds more similar to a wrapper / HLE solution rather than an emulated device that just returns a complete framebuffer - which is what kekko's voodoo emulator looks like - but from what I understand no games should be dealing with even lower-level calls bypassing the windows driver, right? I mean, I'm talking about VXD driver level - not an higher level replacement like wined3d.
The virtual S3 card already handles directx6 and directx7 on many games I tried. The problem is direct3d. However, kekko's Voodoo1 (V1) easily handles up to direct3d6 and certainly glide. Some d3d6 titles show some graphical anomalies, but these are likely fixed by debugging his code. The set of glide and some opengl games allow for an expanded compatibility list with the V1. Many of the direct3d7 games and later will not easily run with the V1, but they are very frequently limited by CPU speed (and MMX), so is it worthwhile to develop a virtual 3d driver for CPU-bound or MMX games. We should identify game titles which do not presently run in dosbox before considering potential solutions.
Moreover, much of the past efforts are based on documented devices. Is the windows VXD driver code available and documented well? It seems a more reasonable strategy, if one exists at all, to implement the 3d solution similar to VirtualBox. There is an open source Gallium3d driver and this allows 3d games to run, although using an NT-based OS.
I think the compatibility list is well into the hundreds for Windows games in dosbox. It probably exceeds the list of decent titles for DOS, so it may be reasonable to work on the existing configuration before adding new features.
I'm more worried about the compatibility of some direct3d games with the 3dfx hardware itself, rather than kekko implementation - On top of my head, I remember having an hard time running the original Colin mc Rae Rally on HW acceleration with a voodoo card.
I suppose this could be fixed, but it could require straying away from the original hardware, and possibly some changes to the (open source by now, i believe?) 3dfx reference driver anyway.
For the Direct X 7 stuff - it was the time when most game were starting to require TnL support and extremely higher clocked CPUs, I doubt that dosbox can run them even on modern computers.
About the complexities of writing the driver - Well, I remember talking years ago with some co-workers whose job was writing windows drivers for soundcards and other multimedia devices, and yes, they didn't really describe that as a pleasurable experience. Probably the most difficult part of taking this approach. I suppose that there are some old windows DDKs floating on the net, but I pity whoever would take this job.
About the Gallium3D driver - isn't that just a passtrough? That wouldn't be very helpful, given that most fixed-pipeline functions and features have been deprecated on modern videocards.
Anyway, too many "woulda", "shoulda" and "I believe" here - I'm going to let the actual developers do the talking 😀
Problem is not only in compatibility but in speed too. I've launched X-Wing 95under Windows 98SE with 3d accelerated graphic. It works very good, but slow. What is very surprising: X-Beyond the Frontier, a game with more complicated graphics is much faster, than X-Wing!
As long as we're making wishes, how about something to allow local folder access via Win9x networking, like VMware does? That should bypass the need for >2GB disk support.
wrote:My limited programming knowledge tells me that all natives games since windows 95 should be communicating with the hardware exclusively using the windows drivers and (excluding glide games ) the direct-x layers, right?
So, instead of emulating an existing Direct X board (and obtaining the required copyrighted firmware or binary blob) , wouldn't be easier to just write a windows reference driver that just translates the graphic calls to something a modern opengl-capable videocard would render?
This is pretty much what WineD3D does, with varying degrees of success. Apparently documentation for early versions of DirectX is poor.
As long as we're making wishes, how about something to allow local folder access via Win9x networking, like VMware does? That should bypass the need for >2GB disk support.
keeping any mounted folder for use after booting Windows 9x would suffice for me 😀
Is there anything majorly different about 9xbox compared to ykhwong's build?
