for win9x hvf you may try this video drivers
https://bearwindows.zcm.com.au/vbe9x.htm
they were needed for -accel whpx

That's the same driver I've been using on QEMU with win9x. With -vga std, -vga vmware or -vga cirrus?
The win9x machine only boots if I remove the -accel hvf. The accelerator apparently only works with XP and later. I've tested with XP before, somewhat better than without it - XP without HVF is unbearable.

I get this error when I try to use HVF with win98 vm: vmx_write_mem: mmu_gva_to_gpa a1000 failed

So, I tried PCem and... all I can say is, it’s good enough for Windows 3.1.

kjliew wrote on 2020-08-30, 23:11:

Alright, this is going to be complicated, unfortunately. I was looking for an easier path to use GLX/X11 on macOS, but this was not as simple as I thought. This was a deprecated, unfavoured approach and Apple had since freezed the time for anyone trying to do that, by capping the OpenGL at 2.1. To do this anyway, AFAIK you will need XQuartz (X.Org server) and SDL2 with X11 support by recompiling it with "--with-x=yes", in addition to Apple/Cocoa native UI library. When I inspected the SDL_config.h, it only supports Cocoa and no X11. Not surprising for something that was part of planned obsolesce. And I presume the performance will not be as good as what being supported on Windows and Linux.

So the correct way to support macOS is to add OpenGL context creation through Cocoa/NSOpenGL. Since I am not an Apple developer, this will be quite challenging to pull this out without accessing to systems with macOS. So I think I will just drop macOS support . Hopefully, someone more adept at macOS software development will be able to contribute the codes in future.

Just to clarify... I can install xquartz which brings me X11, right?

About X11 for Mac

And if I understood this correctly, I'd have to download sources and recompile SDL2 with X11 support (--with-x=yes), instead of the SDL2 from homebrew?

Then I could try again to compile QEMU with your patch (--disable-cocoa --enable-sdl) ?

Am I correct or am I missing something?

Bruninho wrote on 2020-09-02, 15:42:

Just to clarify... I can install xquartz which brings me X11, right? And if I understood this correctly, I'd have to download so […]
Show full quote

Just to clarify... I can install xquartz which brings me X11, right?
And if I understood this correctly, I'd have to download sources and recompile SDL2 with X11 support (--with-x=yes), instead of the SDL2 from homebrew?
Then I could try again to compile QEMU with your patch (--disable-cocoa --enable-sdl) ?
Am I correct or am I missing something?

Frankly, those were pieces and parts gathered from Google. No one had tried it and neither did I.

kjliew wrote on 2020-09-02, 20:26:

Bruninho wrote on 2020-09-02, 15:42:

Just to clarify... I can install xquartz which brings me X11, right? And if I understood this correctly, I'd have to download so […]
Show full quote

Just to clarify... I can install xquartz which brings me X11, right?
And if I understood this correctly, I'd have to download sources and recompile SDL2 with X11 support (--with-x=yes), instead of the SDL2 from homebrew?
Then I could try again to compile QEMU with your patch (--disable-cocoa --enable-sdl) ?
Am I correct or am I missing something?

Frankly, those were pieces and parts gathered from Google. No one had tried it and neither did I.

OK, I'm now officially puzzled.

I made a VMware Debian x64 machine and decided to build qemu with the patch in a debian linux environment just to see if it works.
Guess what, I also got an error at the end. The majority of these errors refer to something like glide gui window or mesa release window. Yikes.

Bruninho wrote on 2020-09-03, 22:06:

I made a VMware Debian x64 machine and decided to build qemu with the patch in a debian linux environment just to see if it works.
Guess what, I also got an error at the end. The majority of these errors refer to something like glide gui window or mesa release window. Yikes.

That should work. Though I didn't use Debian, I had been able to build on Ubuntu x64 before I moved to ArchLinux.
Post the build error log.

kjliew wrote on 2020-09-03, 23:04:

Bruninho wrote on 2020-09-03, 22:06:

I made a VMware Debian x64 machine and decided to build qemu with the patch in a debian linux environment just to see if it works.
Guess what, I also got an error at the end. The majority of these errors refer to something like glide gui window or mesa release window. Yikes.

That should work. Though I didn't use Debian, I had been able to build on Ubuntu x64 before I moved to ArchLinux.
Post the build error log.

I'm sorry, I deleted the VM. I'd rather start over again from scratch just to make sure I did not miss anything or screwed something. I know Ubuntu much better, but I chose Debian x64 because it would be good to start getting used to it for a web development VM, and because I saw in the WWDC 2020 the Apple Silicon Macs demoing Parallels Desktop using a Debian ARM64 VM. If there is an easier distro that works for both architectures and beginners, I'm listening. Could you share the steps you used to compile and build in your linux (Ubuntu or Arch, anything to get started).

I thought about Ubuntu MATE, that distro has both x86 and ARM64 (though these are for raspberry pi) but I went for Debian in the end.

The RPI4 folks run a flavor of Debian AArch64 and they had problem with GCC being too old. You probably want to be sure that your GCC is at least 8.1.
https://github.com/kjliew/qemu-3dfx/issues/3# … mment-662070341

Well, I didn't move to ArchLinux without a reason.... anyway. 😀

kjliew wrote on 2020-09-04, 00:50:

The RPI4 folks run a flavor of Debian AArch64 and they had problem with GCC being too old. You probably want to be sure that your GCC is at least 8.1.
https://github.com/kjliew/qemu-3dfx/issues/3# … mment-662070341

Well, I didn't move to ArchLinux without a reason.... anyway. 😀

Got back a Debian 10 Buster x64 VM now. GCC version reported is 8.3.0:

1bruninho@macbruno:~$ gcc --version
2gcc (Debian 8.3.0-6) 8.3.0
3Copyright (C) 2018 Free Software Foundation, Inc.
4This is free software; see the source for copying conditions.  There is NO
5warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Now I need to figure out all the needed dependencies and setup to compile QEMU with your patch before even doing anything... would be good to have a direction to follow.

EDIT: I saved a snapshot from the VM right after setting it up, so I don't have to reinstall and reconfigure everything again if I screw it up.

@kjliew: I tried again, using my Debian linux VM, targeting only i386, and I had this error. I think I am sure I have all the dependencies in place and I checked as much as I could. But I don't know what is happening this time. I'm attaching the build error:

1Install prefix    /usr/local
2BIOS directory    /usr/local/share/qemu
3firmware path     /usr/local/share/qemu-firmware
4binary directory  /usr/local/bin
5library directory /usr/local/lib
6module directory  /usr/local/lib/qemu
7libexec directory /usr/local/libexec
8include directory /usr/local/include
9config directory  /usr/local/etc
10local state directory   /usr/local/var
11Manual directory  /usr/local/share/man
12ELF interp prefix /usr/gnemul/qemu-%M
13Source path       /home/bruninho/myqemu/qemu-3dfx/qemu-4.1.1
14GIT binary        git
15GIT submodules    
16C compiler        cc
17Host C compiler   cc
18C++ compiler      c++
19Objective-C compiler cc
20ARFLAGS           rv
21CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
22QEMU_CFLAGS       -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt  -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99  -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libdrm -I$(SRC_PATH)/capstone/include
23LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
24QEMU_LDFLAGS      -L$(BUILD_DIR)/dtc/libfdt 
25make              make
26install           install
27python            python3 -B (3.7.3)
28slirp support     internal 
29smbd              /usr/sbin/smbd
30module support    yes
31host CPU          x86_64
32host big endian   no
33target list       i386-softmmu
34gprof enabled     no
35sparse enabled    no
36strip binaries    yes
37profiler          no
38static build      no
39SDL support       yes (2.0.9)
40SDL image support no
41GTK support       no 
42GTK GL support    no
43VTE support       no 
44TLS priority      NORMAL
45GNUTLS support    no
46libgcrypt         no
47nettle            no 
48libtasn1          no
49PAM               no
50iconv support     yes
51curses support    no
52virgl support     yes (0.7.0)
53curl support      no
54mingw32 support   no
55Audio drivers     pa
56Block whitelist (rw) 
57Block whitelist (ro) 
58VirtFS support    no
59Multipath support no
60VNC support       yes

61VNC SASL support  no
62VNC JPEG support  no
63VNC PNG support   no
64xen support       no
65brlapi support    no
66bluez  support    no
67Documentation     no
68PIE               yes
69vde support       no
70netmap support    no
71Linux AIO support no
72ATTR/XATTR support yes
73Install blobs     yes
74KVM support       yes
75HAX support       no
76HVF support       no
77WHPX support      no
78TCG support       yes
79TCG debug enabled no
80TCG interpreter   no
81malloc trim support yes
82RDMA support      no
83PVRDMA support    no
84fdt support       git
85membarrier        no
86preadv support    yes
87fdatasync         yes
88madvise           yes
89posix_madvise     yes
90posix_memalign    yes
91libcap-ng support no
92vhost-net support yes
93vhost-crypto support yes
94vhost-scsi support yes
95vhost-vsock support yes
96vhost-user support yes
97Trace backends    log
98spice support     no 
99rbd support       no
100xfsctl support    no
101smartcard support no
102libusb            yes
103usb net redir     no
104OpenGL support    yes
105OpenGL dmabufs    yes
106libiscsi support  no
107libnfs support    no
108build guest agent yes
109QGA VSS support   no
110QGA w32 disk info no
111QGA MSI support   no
112seccomp support   no
113coroutine backend ucontext
114coroutine pool    yes
115debug stack usage no
116mutex debugging   no
117crypto afalg      no
118GlusterFS support no
119gcov              gcov
120gcov enabled      no
121TPM support       yes
122libssh support    no
123QOM debugging     yes
124Live block migration yes
125lzo support       no
126snappy support    no
127bzip2 support     no
128lzfse support     no
129NUMA host support no
130libxml2           no
131tcmalloc support  no
132jemalloc support  no
133avx2 optimization yes
134replication support yes
135VxHS block device no
136bochs support     yes
137cloop support     yes
138dmg support       yes
139qcow v1 support   yes
140vdi support       yes
141vvfat support     yes
142qed support       yes
143parallels support yes
144sheepdog support  yes
145capstone          internal
146docker            no
147libpmem support   no
148libudev           yes
149default devices   yes

any reason for not providing configure log? it is not only based on your parameters but also on what is available in the environment

by the way i guess you could also try compiling in windows

robertmo wrote on 2020-09-05, 05:33:

any reason for not providing configure log? it is not only based on your parameters but also on what is available in the environment

by the way i guess you could also try compiling in windows

I provided both config and build logs?

Also, compiling in Windows is not an option.

@robertmo: I added to my previous post the output of configure command as well now. so all the info needed to debug why it is also not compiling in a linux VM environment is there.

@kjliew: I fixed some dependencies, but I am still having errors and failed build. The build logs are precisely the same as of yesterday. Most of the errors are related to something you've fixed yesterday for WINE as I could perceive from your latest commit, they all refer to something inside /hw/mesa/mesapt_mm.c as you can see from my last build.log

@kjliew: I see that you've been updating the repository, so I decided to try again on my Debian VM. Now it gives me a different error:

1make[1]: Entering directory '/home/bruninho/myqemu/qemu-3dfx/qemu-4.1.1/slirp'
2make[1]: Nothing to be done for 'all'.
3make[1]: Leaving directory '/home/bruninho/myqemu/qemu-3dfx/qemu-4.1.1/slirp'
4  LINK    i386-softmmu/qemu-system-i386
5/usr/bin/ld: hw/mesa/mglcntx_linux.o: undefined reference to symbol 'XFlush'
6/usr/bin/ld: //lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
7collect2: error: ld returned 1 exit status
8make[1]: *** [Makefile:209: qemu-system-i386] Error 1
9make: *** [Makefile:472: i386-softmmu/all] Error 2

Meanwhile, I am getting some pretty decent results with PCem tests. I think the slower nature of the emulated PC I had before, was because I've used the wrong processor speed; When I chose Pentium MMX 166 instead of 233, things improved considerably, I could notice it when the Windows 98 startup sound was not stuttering anymore. I could somewhat get FIFA 98 playable in a Windows 98 SE machine with Voodoo 2. Maybe, the VBEMP 9x driver could also have been a factor before, due to decreased performance (DOSBox-X also had decreased performance using VBEMP 9x drivers). I'll test VBEMP with the new configuration settings to see if it had influence while playing FIFA 98. The final test will be GP3 and CS 1.6.

I still have a couple of devices to be fixed in Windows 98 SE, like the Printer Port using the wrong resources. Can't seem to fix them all at the moment. DOSBox-X also had similar problems with Power Management and two identical IDE controllers in Windows 98 SE. But so far, it seems to be looking promising. Did I find the holy grail for what I wanted to do here? IMO QEMU should have been a better choice, if it had 3DFx/Glide passthrough for macOS, then it'd have been really GREAT.

I believe that with an Apple Silicon Mac, PCem will be much more faster, so I could probably increase to the Pentium MMX 200 at least. I'd love to see Dominus test PCem with his DTK - although I know this is a forum much more focused on DOSBox and I respect that.

Bruninho wrote on 2020-09-09, 01:24:

I believe that with an Apple Silicon Mac, PCem will be much more faster,

Your believe will be shattered, I bet.

PCem has a highly tuned dynamic re-compiler based on 32-bit x86 instructions. It has no 64-bit version, in a similar fashion of DOSBox high performance dynamic_x86 core that used to work only with 32-bit x86. The architecture portable dynarec core is multiple magnitude slower than dynamic_x86.

QEMU TCG is also an architecture portable dynamic re-compiler and it beats PCem optimized non-portable dynamic re-compiler hands-down.

Remember why Parallels only demo'ed with Debian ARM64 and not typical Debian x86 or Windows XP? Foreign architecture instructions cannot be virtualized and running x86 codes on ARM64 through re-compilers is going to suck on performance.

kjliew wrote on 2020-09-09, 02:06:

Your believe will be shattered, I bet. […]
Show full quote

Bruninho wrote on 2020-09-09, 01:24:

I believe that with an Apple Silicon Mac, PCem will be much more faster,

Your believe will be shattered, I bet.

PCem has a highly tuned dynamic re-compiler based on 32-bit x86 instructions. It has no 64-bit version, in a similar fashion of DOSBox high performance dynamic_x86 core that used to work only with 32-bit x86. The architecture portable dynarec core is multiple magnitude slower than dynamic_x86.

QEMU TCG is also an architecture portable dynamic re-compiler and it beats PCem optimized non-portable dynamic re-compiler hands-down.

Remember why Parallels only demo'ed with Debian ARM64 and not typical Debian x86 or Windows XP? Foreign architecture instructions cannot be virtualized and running x86 codes on ARM64 through re-compilers is going to suck on performance.

I don't care which emulator I will use in an Apple Silicon Mac as long as it gives me 3Dfx, Networking and my DOS, Windows 3.11 and 98SE childhood games running. If it has to be DOSBOx, QEMU or PCem, whatever, I don't care which one I will be using.

Dominus has tested Intel DOSBox with Rosetta 2 with the DTK, and it apparently yielded good results. I don't really care about the dynamic core, since DOSBox-X (a fork of DOSBox) with Windows 98 only works with normal core. I never used the dynamic core, just the normal core. So far DOSBox-X with Windows 98 SE appears to be the only possibility here for me, but it still has issues with two IDE controllers being seen in Windows 98 (one with an yellow exclamation mark), problems with APM Bios (yellow exclamation mark too) and last but more important, the right amount of cycles to be usable/playable is too hard to find. No one has pointed solutions for these issues to me yet. DOSBOX-X developers need to sort out these issues, therefore I've put it aside to explore other possibilities while they aren't fixed.

In an ARM Mac, I would try QEMU inside Parallels running any ARM64 Linux distro (I don't care which distro as long as I get what I want) just to get your 3dfx patch going, but it will be slower anyway and even in my test with a VMware Debian X64 VM I can't get it to compile either, too many errors, so I just left it behind too unless I somehow manage to compile it, I've also provided the logs above for you. If someday it works, then it will also work in an ARM64 Debian VM. But I don't get why it has to depend on Mesa/OpenGL when there are much better alternatives like MoltenVK and Vulkan that are cross-platform, available in ALL platforms, including macOS.

Also, don't underestimate the upcoming Apple Silicon Mac, there are leaked geekbench scores for the DTK showing that even a DTK made without much effort by Apple (running an A12X from 2020 iPad Pro and with 4 of the 8 cores unlocked!) is FASTER than my current 2013 13-inch retina MacBook Pro!!! The future A14 which will be used in first ARM Macs will be definite monsters. So yes, I am definitely going for an ARM Mac.

Another proof of concept is that my 2017 2nd gen iPad Pro is running UTM, which is a GUI for QEMU, and it has a Win 98 SE VM on it. FIFA 98, FIFA 99, GP3 are all running with decent very good speed albeit there is no 3d acceleration, just software renderer. It's practically stock QEMU on an iPad Pro. It can even run Windows XP. If it does THAT well in a 2nd gen iPad Pro, the 2020 is faster than that. But in ARM Mac? It will be absolutely fantastic. But heck, I want 3d acceleration for better graphics.

I will definitely NOT get an Intel PC just for games. I'm fed up of modern Intel PCs, modern games, and I need something I can take with me while travelling and also do my work as a web designer with my mac environment apps. So the games have to be virtual/emulated.

It's QEMU, DOSBox, PCem or nothing. It will definitely NOT be QEMU unless it happens to have 3d acceleration out of the box.

kjliew wrote on 2020-09-09, 02:06:

Foreign architecture instructions cannot be virtualized and running x86 codes on ARM64 through re-compilers is going to suck on performance.

You might want to hold off on that thought until DOSBox gets a "proper" dynamic core for CPUs with lots of registers available (I have an ODROID C4 on the way...)

Right, I've got PCem working flawlessly now with Windows 98SE and set it up for a Pentium MMX 166Mhz. Shutdown now works correctly as it should. Let's see if VBEMP will make it slower... hope not, because I want a full widescreen view.

Okay, here comes the first issues... VBEMP isn't that good for PCem as it is for QEMU/DOSBox. Can't go past 1024x768 in high color without issues on display. And 2nd issue, Netscape Navigator 9 crashes for some reason while it works on QEMU/DOSBox.