VBEMP has lots of bug and missing features.. and its not in development for years and if im not wrong is not open source.. Its just something to enable something better than 640x480x16 when drivers not exists for given video cart for some 2D Office work etc the best, that is goal of this project.

Its 2 1/2 years since this thread started , I forgot why is not possible to use this solution with Cirrus VGA which is already supported by QEMU? It not possible simply add / hack this card drivers to add 3d acceleration options, by some drivers enhancement.. as for VBEMP? Because at least for 2D it would work fine, VBEMP is hit and miss, i dont see big future in it..

Yes that's a good question. Open source would be preferable if that can be accomplished somehow.
I think I was using cirrus in my first tests (because Win9x guest has drivers readily available) and the wrapper was at least activated, but that's about as much I can tell you about it...
This is just a guess, but maybe the cirrus drivers don't work correctly with kvm?
Also, what about performance? VBEMP is supposedly the best?

Well lofty ideas..
I wrote way back that best thah solution would some create whole virtual 3D card device, as original Voodoo 1/2 cards actually were, they were in WIndows 98 listed / managed as multimedia device.. when 3D was executed they were activated otherwise they did nothing.. so i theory could as virtual device created pass through calls to host operating system, as are not through dgVoodoo wrapper. and for 2D would all managed Cirrus.. which has to be somehow open sourced, at least its design, because is emulated by lost of emulators.

Difference between Cirrus / VBEMP
1) its probably in framebuffer size, Cirrus has probably max 2/4 MB.. VBEMP much more, there is some Qemu terminal switch to use more, i thing that it is history.. but i never made it working, my quess that is as other lofty Qemu switches, which are working only under some circumstances..
2) VBEMP is probably all emulated on CPU - so with todays hardware could be probably much faster.. that some old 30-50 Mhz 2D card, which is emulated at near to real device as possible (but i could be wrong).

But to be honest..
a) 2D games are already running quite well, i Vmware Windows 98 emulation machinee with its SVGA II driver, i played with it Diablo, Starcraft, Fallout 2 etc..
b) There is not much 2D Win9x games, which need faster 2D card, Cirrus is enough for games before 3Dfx (<96-98) and after games had 3D acceleration. I remember that even back in this era, software OpenGL 640x480 was too much for comtempary cpu+gpus.

You can now finally, actually test (or more precisely simulate) contemporary with old PCs, with PCem, it now support up to Pentium II 450MHz + lots of old videocards, up to Vooodoo 3, Voodoo 1+2 SLI etc:
https://pcem-emulator.co.uk/ // You old need beefy CPU to emulate such fast machine, fast from perspective what is emulated. On my Core i9 9900k Stock clock +3600 CL19 slimmer, it depends on task, but i can emulated something like PII 300 with right speed (there some for emulation speed reporting Popup graph) without frame skipping.

VBEMP is good enough, though it is free only for personal, home & non-commercial use. It does not endorse FSF open source philosophy. QEMU's answer to this is QXL, but unfortunately only WinXP and onwards. QEMU uses Bochs dispi as the VESA backend which is *host accelerated* for hardware virtualization. The typical register model of hardware drivers was not able to harness the benefits of virtualization. It requires an approximate of FIFO model to offset the latency of getting in and out of virtual machine.

Below is an **unfair** 2D performance comparison between PCem and QEMU WHPX, one emulates the "advanced smart" Voodoo Banshee and the other the "just lame" VESA dumb buffer controller.

Notice that my aged AMD FX CPU is unable to emulate Pentium II/233MHz at 100%, but it is fine, just give PCem the advantage on discarding the ticks. A more accurate measurement should take the emulation % multiply by each score sample. Frankly, PCem performance is decent, the more "advanced smart" Voodoo Banshee must have given plenty of opportunities to offload graphics operation onto host CPU. Without hardware virtualization, QEMU can't match PCem. However, when hardware virtualization comes into picture, the table turns and that's so much about emulating Voodoo Banshee.

Does it matter anymore, maybe for some. For playing games, I wouldn't care if 3Dfx/ATI/Matrox/NVIDIA was emulated as long as games run at great speed, high resolution and actually playable.

Non-knowledgeable users who tried and complained about PCem sluggishness were bombarded with "your CPU sucks, use Intel" especially before the rise of Ryzen. QEMU WHPX/KVM had shown the world the proof of concept how it can be done differently with remarkable results without bragging about latest Ryzen 5950X or Core i9 CPUs.

Not to belittle your hard work (quite on the contrary), but this makes one think how much better the performance could be if a proper QXL driver were written for the Win9x family of operating systems.

Once games were developed to run on Windows, hardware wasn't accessed directly anymore. Audio and video drivers would provide hardware-independent abstraction. That is something that could still be taken advantage of when developing emulation and virtualization solutions for such games.

From what I've understood, Win9x video driver development is a bit of a "dark art", which requires a certain legacy SDK, an old enough version of Visual Studio, etc.

What would really help is an existing Win9x driver of which the source code is publicly available under an acceptable open source license. That could be used as a basis from which to develop such a driver. Does anybody know of such a driver? VBEMP is obviously not open source. Neither are the VMWare video drivers for Win9x. Anything else out there that would provide a decent starting point?

Okay, apparently the VBEMP 9x Project website does seem to point prospective Win9x video driver developers in the right direction, with links to an open source example FRAMEBUF driver for Win9x, as well as the proper Driver Developer KIT (DDK) at http://www.mdgx.com/add.htm#DDK.

I guess that's something. Given the references to MASM, there is still assembly code involved. Interesting.

This blog entry also seems to have some relevant related information: http://www.os2museum.com/wp/simple-windows-nt … for-virtualbox/

I've never written a device driver in my entire life, let alone one for an old version of Windows.

How beneficial do you reckon it would be to pursue this further?

You could always reach out to Michal Necasek and/or bearwindows. Michael based his miniport NT3.1 to Windows 7 driver based off the framebuf in the NT DDK. Bearwindows did the same for both 9x and NT on the DDK as well. You would probably be better off with Open Watcom for both. Since you would only be worried about virtual machines you wouldn't have to worry about the hassle of supporting real hardware.

DosFreak wrote on 2021-01-19, 00:40:

You could always reach out to Michal Necasek and/or bearwindows. Michael based his miniport NT3.1 to Windows 7 driver based off the framebuf in the NT DDK. Bearwindows did the same for both 9x and NT on the DDK as well. You would probably be better off with Open Watcom for both. Since you would only be worried about virtual machines you wouldn't have to worry about the hassle of supporting real hardware.

Thanks for those pointers! Those indeed sound like the people to talk to.

And yeah, if I could just use something like Open Watcom and write the driver in (mostly?) C, without having to bother with a lot of assembly language stuff, that would make something like this a lot more feasible, at least to someone like me. 😅

"This ain't fair, you should compare PCem with QEMU TCG!"

Great idea, let's do that and compare device emulation vs API pass-through 😜
Let's give PCem some head-start, 16bpp is OK, max resolution at 800x600 and penalize MESAGL with 1024x768 32bpp.

This is, again, **unfair** (depends on how one looks at it 😜) 3D performance comparison between PCem and QEMU TCG using Quake2. One emulates Voodoo Banshee with 3Dfx miniGL 1.49 and the other "cheater" with MESAGL pass-through with default OpenGL.

Never mind that AMD FX CPU IPC sucks and cannot achieve 100% emulation with Pentium II/233MHz, just look at the final result because it will be the same if one had the beefy CPU that can achieve 100% emulation. Again frankly, PCem performance is decent, (640x480x16bpp 55.8 fps, 800x600x16bpp 50.3 fps) but yet not as good as MESAGL pass-through. Is QEMU TCG significantly better at dynamic re-compilation? I don't think so, but API pass-through has its inherent advantage of low overhead compared to device emulation. In fact, QEMU TCG is getting slower and slower for every new QEMU version since 2.5.

Does device emulation of Voodoo Banshee or even Voodoo 3 matter? It's cool perhaps, and you have the data to make your own conclusion. It's all about the games, baby! 😁

digger wrote on 2021-01-19, 00:10:

how much better the performance could be if a proper QXL driver were written for the Win9x family of operating systems.

In my opinion, not much. Both VBEMP and QXL already use the same Bochs dispi as VESA backend. VESA/AF had failed and no one bothered with it. There isn't an easy way to map 2D primitives to GPU fixed-function 2D acceleration. Today, almost all 2D fixed-functions are stripped off from modern GPUs. A modern 2D driver should in fact make use of 3D backends (OpenGL/Vulkan/D3D12) and use shaders for 2D primitives. All modern OS's DE/WM already do this in user space, so there isn't a lot of hope for much improvement for legacy 2D drivers. No incentive for doing so.

digger wrote on 2021-01-19, 00:10:

Once games were developed to run on Windows, hardware wasn't accessed directly anymore. Audio and video drivers would provide hardware-independent abstraction. That is something that could still be taken advantage of when developing emulation and virtualization solutions for such games.

It's already happening, it's called para-virtualization. QXL is part of it. The virtio peripherals in QEMU take it to the next level. On Linux, you can have

virtio-gpu virtio-net virtio-blk virtio-scsi virtio-mouse virtio-keyboard virtio-tablet virtio-serial virtio-crypto virtio-balloon

The more recent, virtio-fs & virtio-audio are on the horizon and virtio-gpu gets the plumbing to support host video decode acceleration. Too bad, legacy OS's will be left out in the cold shower. I do hope one day Windows 10 does get support for virtio peripherals. Otherwise, solution such as Intel GVT-g will prevail and force AMD/NVIDIA to do the same for their IGPs and consumer-class dGPUs. Now, Intel has entered dGPU competition, it is interesting to watch how it will shape up the vision of GPU virtualization in the future.

Did you tried to contact Bearwindows? He's a kind person and maybe he can reconsider the license and sources when you tell him about the project. He probably don't have time to develop vbemp further.

BTW AMD FX is good, at leas in the winter 😉

Very nice web-digging there, digger & co. 😉

Authors have their own reasons for choosing a particular license, but it can be just a placeholder because they haven't really given it any thought.
I brought up open source because I think that is the best way to ensure there will always be a way to fix things, should a need arise.
In this case it could happen if there are some massive changes in qemu itself, and/or the hardware. The guests themselves are what they are.

Below is an **unfair** 2D performance comparison between PCem and QEMU WHPX, one emulates the "advanced smart" Voodoo Banshee and the other the "just lame" VESA dumb buffer controller.
perf2d.png

Im not sure that i understand these numbers right.. Well, i expected that Qemu numbers + Your mode would be much, much better.. there is 637 vs 848 its so difference is very small and with PCem im getting fully emulated machine without QEMU / VBEMP problem, it would be no brainer sacrifice 25% of performance for that. Same Quake 2, there is difference but its not huge (lets say 50%), as i expected.. If im not wrong in some previous posts ( Re: KVM(QEMU) Win98 videocard passthrough.I finally got it working- with full 3D API support Quake III 1600x1200 90+ FPS) was info about much bigger performance some Quake 3 1024x768 - 167 FPS, Sam TFE at 60FP on some slow notebook.

So these great results from the past are limited only to emulated Windows XP+, or only on host Linux or where is difference in performance? Because with these numbers your project starting to be interesting for me, otherwise no big deal with PCem quick progress.

I dont care about which graphics card is emulated and how.. but i care about whole virtual machine experience. I dont want to use multiple Win98 virtual machines depends on which type of game i want to play, its like have multiple computers for same time period, its hassle.. It would be nice really have one virtual solution for whole Win98 era (with Win98 and Dos multiboot).. when i decide which game from era in want to play after machine is booted, than before - to select proper virtualization engine for it.

ruthan wrote on 2020-03-08, 00:32:

You should really post some numbers / videos etc, because otherwise nobody know what to expect..

Yes, Sir! I listened. You can check it out. Thanks for supporting my channel.
https://www.youtube.com/channel/UCl8InhZs1ixZBcLrMDSWd0A

You're right about everything you said for a Core i9 9900k at 5GHz. Have fun with PCem, you deserve it for the money spent.

Just a minor correction if you don't mind ...... Regarding the Quake2, you do realize the difference in QEMU between TCG and WHPX/KVM, don't you? 😁 Do you really want me to show the result from the later? Oh, please don't 🤣 😁 50fps is 100% playable and I am sure Core i9 9900K can emulate Pentium II/233MHz at 100% including a Voodoo 3 for games.

Well, you posted QEMU TCG numbers, nothing else.. and probably nobody now that your youtube channel exist, oldest video is 6 day old.

When you will post WHPX/KVM numbers it would get more interesting. Especially now, when WHPX can run besides Vmware virtualization with last Vmware Workstation.

In my case it tried on Windows and Linux turn lots of Qemu acceleration options and newer saw big difference, but it probably depends on use case and i never benchmarked it, it could be better, but never feel some big speed up with Win98 or Dos machine at least in Windows 98 with some your patch, i always got Win98 crash when desktop loaded.. On Linux with KVM i thing that i have it on, but im not sure.

Im playing on lots of machines, even on mobile GPD WIn2 with Intel m3-8100Y 1.10 GHz 15W duo core.. so i dont need to hear, this 5GHz elitist bla, bla, its nice to have fast machine for new games and work and it running WinXP natively too. So far PCem is still best you can get, without too much hassle, without it there was only physical machine or Linux KVM with GLide wrapper and Windows 98 compatible videocard passthrough (and its also far from hassle free).

BTW Arch linux in explain some things, you are using must hardcore path even in Linux field..

ruthan wrote on 2021-01-20, 00:15:

.. and probably nobody (k)now that your youtube channel exist, oldest video is 6 day old.

Yeah, true ... I believe in you. It is so quiet down there, unlike those game videos captured on PCem. I will thank you when you spread the words. Perhaps, you really got your point, the word "QEMU" immediately scared everyone away. 🤣

ruthan wrote on 2021-01-20, 00:15:

Im playing on lots of machines, even on mobile GPD WIn2 with Intel m3-8100Y 1.10 GHz 15W duo core..

Lucky you, it is indeed a great machine for portability. QEMU runs great on that machine and it would be running circles around PCem running on Core i9 9900k with much more playable games from the late 90's til early 2001 era. UT2003 is playable at near 60FPS my Core m3-6Y30 within QEMU, and that is an N-2 generation CPU compared to M3-8100Y. Yeah, I hear it you don't need to play UT2003 with VM.

I went for ArchLinux for its rolling update and pacman packaging ecosystem. I am used to pacman and like it very much from MSYS2/mingw-w64 on Windows 10. I had Ubuntu prior to this. You don't have to be accustomed to ArchLinux to be able to use QEMU. It is also easier to to setup new system with ArchLinux from scratch. I like the way that one could get to the console ASAP without DE/WM compared to Debian/Ubuntu GUI based setup.

UT2003 is playable at near 60FPS my Core m3-6Y30 within QEMU.. its nice, what API its using OpenGL, or you are finnaly able to run Direct3D? I know that this is fast, but some apple to apple numbers found be great, so if you can run same test as before for Quake 2 with some HW acceleration.. so show difference, or vice versa run UT2003 without it and run it on same HW with PCem..
UT2003 complete fine for testing, you want most demanding WIndows 98 games, to show difference, even these are more for WiXP, i did same thing with my Win98 KVM benchmarking:
https://www.win-raid.com/t6017f53-Windows-SE- … .html#msg107458

I thing that we all dream about super fast overkilled, but still stable and compatible virtual Windows 98 machine. Its quite fun for me even try to make such newest as possible games working on Win98, right kind of fun, not some self educating Qemu compiling and Qemu switches madness trying fun 😀

Arch Linux - i would say that is for lowlevel control freaks, i dont know, does it have now finally official GUI installer, or you still need 3rd party tool for it? For the record, i tried probably every major Linux distro.. and im user friendliness and GUI lover, so im using if can choose- Mint, Manjaro, Ubuntu, Fedora, Solus... and i would prefer them even more high level, more really working gui wizards, less terminal and text configs, that is killer of desktop Linux success.

Qemu problems are similar - lack of good GUI frontend / tools for machine setup and control (there Virt manager, but only on Linux and far from from be good enough), very user unfriendly help/wikies (usually depends on distro, in-complete and hard to fully understand) and command line interface + lots of bugs, there is Qemu bug tracker.. but nothing like readable main know issues list for concrete target OS.

ruthan wrote on 2021-01-20, 19:26:

.. what API its using OpenGL, or you are finnaly able to run Direct3D?

It is OpenGL for UT2003. Where have you been in the last 2 years?

ruthan wrote on 2021-01-20, 19:26:

...some apple to apple numbers found be great, so if you can run same test as before for Quake 2 with some HW acceleration.. so show difference, or vice versa run UT2003 without it and run it on same HW with PCem.

I don't have a great desktop CPU to show off the better part of PCem. I halted desktop upgrade indefinitely. My best CPU is on thin & light laptop, the Ryzen 2500U, but PCem is hopeless on any mobile CPUs. I could be heavily criticized for magnifying the ugly side of PCem. Since you have a Core i9 9900K seemingly the highest clocked CPU on earth, you are in better position to show off the better part of PCem. PCem has a strong community backing it up, but most of them are shy of publishing in-game performance stats and yet recommending PCem and setting unrealistic expectation that games such as Unreal, NFS3 , Turok2, Blood2, MDK2 etc. with screenshots/videos as though they are playable. Perhaps I was so wrong and those games are indeed playable with Core i9 9900K, all one needs is 30fps, anything more is superficial.

Even Box86 on RPi4 videos have the guts to show performance stats running old Windows games.

It is seemingly impossible to gather performance statistics on PCem, but some do exist, but with unknown host CPU/GPU and game configuration
3DMark99 - 3607 3DMarks
3DMark2000 - 1049 3DMarks
Quake3 - 34.5 fps

There is a YouTube video on Turok 1 with stats, but it didn't finish end-to-end to provide the final T1Mark score for easy comparison. Another video on YouTube showing Final Reality running on PCem, but abruptly cut before the final scores could be shown. Perhaps you can help to fill the gap. And you can do more, Unreal Flyby Timedemo, Turok2 T2Mark, MDK2 benchmark. Oh, please don't use UT2003, it is so unfair to PCem 🤣

ruthan wrote on 2021-01-20, 19:26:

i did same thing with my Win98 KVM benchmarking:
https://www.win-raid.com/t6017f53-Windows-SE- … .html#msg107458
I thing that we all dream about super fast overkilled, but still stable and compatible virtual Windows 98 machine.

I think we are there now, it is no longer just a dream with QEMU, and only with QEMU for now 😁. Though I didn't have the energy and time to check out the huge list of game demos you have there, I am pretty confident QEMU will run all of them equally well, if not better. I did pick a few interesting ones, such as Mafia and Max Payne, they just work. I could be making a video for them on QEMU in the future.

The idea doesn't seem to be welcome, it takes away the fun of tinkering real machines. Otherwise, unless one is building a Win98 frankenstein machine with unofficial driver support (Geforce 6800 and better), Win98 VM on QEMU outperforms all lesser builds at playing games. I already foresee this, Win98 VM will be faster than anything on earth that can still boot Win98.

I gave you notice before and for good reason. Would you like it if someone else mentioned constantly their perceived issues with Qemu ad nauseum?
You want to play games at ridiculous high fps in Windows 98 in Qemu. That's fine. We get it. Qemu is the greatest piece of software in existence.
Someone else wants to play games however they want to play them in pcem. That is also fine but it's not fine with you even though you say it is but it isn't if someone reads your posts.

If you persist then I'll pick apart every one of your posts and show you what is blatantly obvious, I'd rather not.

DosFreak wrote on 2021-01-20, 22:16:

I gave you notice before and for good reason. Would you like it if someone else mentioned constantly their perceived issues with […]
Show full quote

I gave you notice before and for good reason. Would you like it if someone else mentioned constantly their perceived issues with Qemu ad nauseum?
You want to play games at ridiculous high fps in Windows 98 in Qemu. That's fine. We get it. Qemu is the greatest piece of software in existence.
Someone else wants to play games however they want to play them in pcem. That is also fine but it's not fine with you even though you say it is but it isn't if someone reads your posts.

If you persist then I'll pick apart every one of your posts and show you what is blatantly obvious, I'd rather not.

I acknowledge. Thank you, I got your message. 😁

Just a minor correction if you don't mind ...... Ridiculously high FPS is never the goal. The goal is getting the games to run seamlessly and correctly on Windows 10 and Linux, hence the preservation of games for foreseeable future. I have 2 videos on Titanium Mechwarriors on my channel, if you don't mind visiting them. They were deliberately FPS capped at 36 so their game logic didn't go crazy. The Unreal Flyby timedemo, NFS3 and NFS Porsche Unleashed were deliberately capped at VSYNC, if I am not mistaken.

Believe it or not, sometimes I do appreciate games being slow. I compiled my own version of Genesis GENS to cap FPS at 20 so that on some shoot'em up I have more time to react without instant death. 🤣