VOGONS


Reply 81 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 82 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 83 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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?

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 84 of 110, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 85 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 86 of 110, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 87 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 88 of 110, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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. 😀

Reply 89 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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:

bruninho@macbruno:~$ gcc --version
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; 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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 90 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

@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:

Install prefix    /usr/local
BIOS directory /usr/local/share/qemu
firmware path /usr/local/share/qemu-firmware
binary directory /usr/local/bin
library directory /usr/local/lib
module directory /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory /usr/local/etc
local state directory /usr/local/var
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/bruninho/myqemu/qemu-3dfx/qemu-4.1.1
GIT binary git
GIT submodules
C compiler cc
Host C compiler cc
C++ compiler c++
Objective-C compiler cc
ARFLAGS rv
CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_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
LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
QEMU_LDFLAGS -L$(BUILD_DIR)/dtc/libfdt
make make
install install
python python3 -B (3.7.3)
slirp support internal
smbd /usr/sbin/smbd
module support yes
host CPU x86_64
host big endian no
target list i386-softmmu
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
SDL support yes (2.0.9)
SDL image support no
GTK support no
GTK GL support no
VTE support no
TLS priority NORMAL
GNUTLS support no
libgcrypt no
nettle no
libtasn1 no
PAM no
iconv support yes
curses support no
virgl support yes (0.7.0)
curl support no
mingw32 support no
Audio drivers pa
Block whitelist (rw)
Block whitelist (ro)
VirtFS support no
Multipath support no
VNC support yes
Show last 89 lines
VNC SASL support  no
VNC JPEG support no
VNC PNG support no
xen support no
brlapi support no
bluez support no
Documentation no
PIE yes
vde support no
netmap support no
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support yes
HAX support no
HVF support no
WHPX support no
TCG support yes
TCG debug enabled no
TCG interpreter no
malloc trim support yes
RDMA support no
PVRDMA support no
fdt support git
membarrier no
preadv support yes
fdatasync yes
madvise yes
posix_madvise yes
posix_memalign yes
libcap-ng support no
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends log
spice support no
rbd support no
xfsctl support no
smartcard support no
libusb yes
usb net redir no
OpenGL support yes
OpenGL dmabufs yes
libiscsi support no
libnfs support no
build guest agent yes
QGA VSS support no
QGA w32 disk info no
QGA MSI support no
seccomp support no
coroutine backend ucontext
coroutine pool yes
debug stack usage no
mutex debugging no
crypto afalg no
GlusterFS support no
gcov gcov
gcov enabled no
TPM support yes
libssh support no
QOM debugging yes
Live block migration yes
lzo support no
snappy support no
bzip2 support no
lzfse support no
NUMA host support no
libxml2 no
tcmalloc support no
jemalloc support no
avx2 optimization yes
replication support yes
VxHS block device no
bochs support yes
cloop support yes
dmg support yes
qcow v1 support yes
vdi support yes
vvfat support yes
qed support yes
parallels support yes
sheepdog support yes
capstone internal
docker no
libpmem support no
libudev yes
default devices yes

Attachments

Last edited by Bruninho on 2020-09-06, 03:31. Edited 1 time in total.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 92 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 93 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

@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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 94 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

@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:

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

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 95 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 96 of 110, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 97 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

Reply 98 of 110, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
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...)

Reply 99 of 110, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie

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.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.