Should be able to post about a dozen troublesome games tomorrow. If the error log not good enogh then at least the game list will be something.
Just a quick status update. Things are still moving along.
I started playing around on a Raspberry Pi 4. It's not exactly fast for Boxedwine, but since I'm only using the normal core, I guess that isn't surprising. Right now it seems like Roller Coaster Tycoon gets about 1 frame per second. I already have a simple JIT recompiler for x86 that I can use as a template for ARM. The x86 JIT seems to give a little more than 2x improvement so maybe ARM will see the same improvement.
Finished the simple ARMv7 recompiler. MDK performance on the Raspberry Pi 4 improved from 11 to 21. So almost doubling performance as expected. There is still room for improvement. When generating the ASM, each emulated op creates the ASM independently. So I see generated code where it will store a value from a register to memory at the end of an emulated instruction. Then the beginning of the next emulated instruction will read the memory back into the same register.
Is BoxedWine's goal currently only games or Windows 9x apps too which broke on modern Windows? I tried a few apps with it - Publisher 95, Publisher 97, certain apps which require old 32-bit Video for Windows codecs, Encarta 99/2000, Picture It! 2001, Picture It! 2002. Not a single one worked 🙁
xpclient wrote on 2020-08-08, 20:26:Is BoxedWine's goal currently only games or Windows 9x apps too which broke on modern Windows? I tried a few apps with it - Publisher 95, Publisher 97, certain apps which require old 32-bit Video for Windows codecs, Encarta 99/2000, Picture It! 2001, Picture It! 2002. Not a single one worked 🙁
I definitely spend most of my time getting games to work, but apps should work too. Boxedwine just runs Wine inside a custom Linux/CPU emulator. So if Wine can run the app, then Boxedwine should be able to do it too, and if not, then its a bug. I looked up Publisher on the Wine app db, it looks like Wine had problems running the older versions.
I did try Encarta 99. It failed to install, but then I changed the Windows version to "Windows 98" (from the UI this can be done from a combox box, from the command line you will need to launch winecfg) and the installer worked for the most part, just one error. Encarta started, but some things didn't work. The audio seemed way too fast, and sometimes it just hung/paused for 1 to 2 minutes. If it complains about the cd missing when you run it, you can mount the directory containing the cd files (should be easy to do if you are using the UI, see the area I circled in the attached screen shot).
I think every year my TODO list for BoxedWine grows. It is hard to keep up with everything I want to do. For one, I really need to make a better release process that can automatically build all platforms. Here is a portable Windows zip for x86 and x64 that contains everything necessary to run BoxedWine plus Full Tilt! Demo. In the future I will create an installer again and put up more platforms. I already have a Jenkins server set up that builds and runs unit tests for all supported platforms, the next step will be publishing the artifacts.
As for BoxedWine, not a lot to report on, I've been pretty much focused on Armv8 (Arm64). My goal is to create an Android and Mac Arm release. I was hoping to have the Mac Arm version done in time for the new Mac releases but unfortunately that is not going to happen. x86 to Arm is a tough problem. I imagine I will spend a lot of time debugging memory fences once I do get it up and running.
https://sourceforge.net/projects/boxedwine/fi … /Builds/20.1.2/
Files for Download:
BoxedWine 20.1.2 - Windows.zip
* This is a portable version of BoxedWine for Windows.
* This contains the 32-bit and 64-bit versions of BoxedWine.
* This also contains Wine 5.0 and Wine 1.7 so that it can be used without a network connection.
Changes:
BoxedWine 20.1.2
* Added about 30 more supported extensions to OpenGL.
* Fixed fstat system call, it will now will report the correct size of the file
* Added SSE2 support for both the x64 and normal cores
* Fixed crash in custom winex11.drv and updated file systems to use it
* Launching Boxedwine without any command line arguments will now launch a new UI. As long as the platform support OpenGL it should work with the UI.
* Windows UI is DPI aware
* Fixed an issue where fast keyboard or mouse input can cause major lag in some games like Sacrafice, Powerslide and Quake 3.
Known game fixes
* GOG's Diablo + Hellfire - https://www.gog.com/game/diablo
The installer works, the launcher works and Diablo works. Hellfire does not work (same as Wine).
* Half-Life Uplink Demo installer and game work with Wine 4 now. Wine 1.7 has color issue with intro and game is a blank screen.
* Final Reality Benchmark. Works with Wine 1.7 and OpenGL (need to delete HKEY_CURRENT_USER\Software\Wine\Direct3D\DirectDrawRenderer key from registry)
* MechWarrior 3 with Wine 4.0
* Tomb Raider 3 from GOG.com, need to add -setup to the command line and hit enter at the first black screen
I was a huge fan of jdosbox, glad to see you are still working on things!
Getting a win98 VM to download from a webpage was very nice and worth the learning (it looks great in job interview).
If you compile qemu with WHPX/HAXm support it can run opengl/webgl benchmarks from a linux VM on a windows host. It can run the graphics on another process with Linux and KVM and this provides additional performance.
If you setup these it helps in my experience: https://wiki.winehq.org/Useful_Registry_Keys
I had previously setup QEMU's block drivers in a linux/KVM and used GCDEMU to pass isos into wine and play Sanitarium( multi-cd game). It worked fairly well. This was in 2015
Intel's HAx is an open source accelerator for windows and is on github, no idea if it could help you out.
Qemu does work for win98se and dos8 but without acceleration it cant even load Fallout 1&2's intro. Even on x86.. boxed wine does.
Boxed wine seemed to have better video output quality in a simple test vs QEMU.
Qemu-system-86 works fairly well on arm and you can use multithread mode to load LiveXP with multiple cores 4+ on an Xu4.
On Arm SBC I have been able to run starcraft and diablo and Mech commander via qemu-system-i386/x64.
But this is done with ram drives and nvme ssds and tuning with GCC. Its been for learning and not necessarily as an entertainment solution.
Without acceleration and VBEMP with the newer GPU modes in qemu, its not really competitive vs anything else though for gaming. I cant even get the cirrus card to work outside of dos...
Stay well!
danoon wrote on 2019-08-11, 05:14:wrote:although not listed there - i would really like to know if maybe boxed wine could run iF-22 and or iF/a-18 - i think these 2 interactive magic games from the late 90s have been the challenge of the past decade for me. even Jane's F/a-18 has recently cracked when i have tried some more dxwnd approaches, but if-22 and if/a-18 remain impossible to get going (i think it may have to do with the movies which seem to have some coding issue running on windows 10
iM1-a2 abrams runs in windows 10 but it currently runs far too fast when it comes to projectiles flying and if the tank goes done a slope it goes into hyperdrive
if boxed wine could work for any of these iMagic sims, i would like to know
There might be some hope. I tried iF 22 and it mostly worked. The movies would crash near the end of the movie, but eventually I was able to get to the main screen. I tried the instant action. It works, but it wasn't very responsive to my keyboard commands, it was hard to control. Maybe someday when I get joystick support it will be more playable.
Did you or anyone else managed to make it work with a USB joystick ?
Hail to the Emperor !
Hello,
Thanks a lot for BoxedWine, it's an incredibly interesting approach to make old games work again ! 😁
Fascinating, really.
I had tried to run Wine directly inside WSL 1/2 but performance was horrible of course.
I see 3D games on the project's page, I'm very curious about their performance compared to PCem.
About CD images, could I use Daemon Tools 3.47 inside BoxedWine ?
(I'm trying to run the first Barbie Detective game. I removed the IN/OUT privileged instructions with OllyDbg. Now it works on Windows XP and up to Windows 7, but still won't run on Windows 10 (DirectDraw problem, no wrapper fixes it. Not even WineD3D). It uses a CD image with CD music. I could make a NOCD but I'm trying a simpler approach first)
wadrasil
Qemu-system-86 works fairly well on arm and you can use multithread mode to load LiveXP with multiple cores 4+ on an Xu4.
On Arm SBC I have been able to run starcraft and diablo and Mech commander via qemu-system-i386/x64.
That sounds pretty promising for Arm. Arm is my current focus right now.
As for things like HAXm, I have thought about it. I think something like nested page tables could help performance. But its not a priority right now. I consider 3 classes of app/games. 1) 16-bit 2) old 32-bit and 3) newer 32-bit. 16-bit doesn't work on Windows 10, so Boxedwine is useful for that. Some older 32-bit games don't run well on Windows 10 so Boxedwine might work well there. But for newer 32-bit games, they should work well on Windows. So for the x64 platform, I think the x64 build of Boxedwine is fast enough for 16-bit and older 32-bit games. But in the future I might consider something like HAXm.
FIVE-one
Did you or anyone else managed to make it work with a USB joystick ?
I haven't implemented joystick support yet, but it is in the top 5 things I want to work on in the next year.
xcomcmdr
About CD images, could I use Daemon Tools 3.47 inside BoxedWine ?
I looked up Daemon Tools on Wine's app db,
https://appdb.winehq.org/objectManager.php?sC … rsion&iId=30120
Unfortunately, if it doesn't work in Wine, it won't work in Boxedwine. But ISO and BIN/CUE are on my list of things to support in the future. It wouldn't support copy protection but it would pass simple CD checks.
FWIW, early 2000s/win98 era safedisc protection is pretty easy to bypass assuming the .bin files contain full 2352 byte sectors. It uses a different read command to check for its "bad" sectors, so all you need to do is manually verify the requested sector's CRC and return a read error if it doesn't match.
jmarsh wrote on 2020-11-27, 19:30:FWIW, early 2000s/win98 era safedisc protection is pretty easy to bypass assuming the .bin files contain full 2352 byte sectors. It uses a different read command to check for its "bad" sectors, so all you need to do is manually verify the requested sector's CRC and return a read error if it doesn't match.
Thanks for the info, I added it to my feature tracker so that I won't forget when I get to it.
danoon wrote on 2020-06-17, 17:59:I started playing around on a Raspberry Pi 4. It's not exactly fast for Boxedwine, but since I'm only using the normal core, I guess that isn't surprising. Right now it seems like Roller Coaster Tycoon gets about 1 frame per second. I already have a simple JIT recompiler for x86 that I can use as a template for ARM. The x86 JIT seems to give a little more than 2x improvement so maybe ARM will see the same improvement.
This is great news.
Have you seen the box86 project?
https://github.com/ptitSeb/box86
Currently a distribution named "TwisterOS" is the easiest way to test it out with WINE:
https://twisteros.com/
And while that's great, I'm really not a fan of that specific distro. Updating it is cumbersome, and the author has really hacked in a lot of things that make it rather difficult to use as a standard desktop OS like Raspbian/RaspberryPiOS/Ubuntu outside of the box86 tools that I'm interested in.
Pretty excited to see a portable, installable usuable x86+WINE setup for RPi via Boxedwine. That opens up a massive world of software for a very affordable little system.
I'm also really keen to check out the WASM option. There's quite a few preservation groups who I'm helping out currently, and they're very keen to get this stuff working in browser for their research teams.
box86 seems like a cool project, very similar to Boxedwine but from a different approach.
The last several months I've been working on a faster CPU emulation for ARMv8, so this will require the 64-bit version of the Raspberry Pi OS. I'm slowly making progress, it now launches the first two processes that Wine uses, wineserver and wineboot. I have no idea where performance will land, but I would be happy if it could run smoothly games from the Pentium 166MHz time on the Pi 4. The worst thing about writing a CPU emulator is that it has to be completed before performance can be evaluated.
As for WASM, we would like to create some sort of JIT WASM recompiler for it, which could double performance, but that might be a ways off. But in the mean time it runs Windows 3.1 and some early Windows 95 stuff ok. I just helped someone get a Turkish program to run on it which was a little bit of challenge because of how locale is handled. https://maidis.github.io/boxedwine-moonstar/b … nStar&p=MTU.EXE
Here is another update on the ARMv8 CPU core. My Raspberry Pi 4 on the 64-bit OS went from 27 (simple JIT version) to 170 for the MDK performance test. This is the first time I've gotten MDK perf to run since I started this CPU core 9 months ago. It's nice to see such a large improvement. It still has a lot of work left, but at least I know I'm on the right track.
Oh wow, that's an amazing improvement in performance and efficiency! Well done.
If these gains can be reproduced for other games from the era, than you've made the RPi4 an ideal platform for PC retrogaming!
Can your ARMv8 core also be used in DOSBox or other DOS emulators?
digger wrote on 2021-01-31, 16:37:Oh wow, that's an amazing improvement in performance and efficiency! Well done.
If these gains can be reproduced for other games from the era, than you've made the RPi4 an ideal platform for PC retrogaming!
Can your ARMv8 core also be used in DOSBox or other DOS emulators?
My CPU cores don't implement the OS specific instructions since I don't need them. I only implement what the games/apps use. So it would be a big undertaking to port it to Dosbox. And on top of that my architecture is quite a bit different since mine is multi-threaded. Each game/app thread gets it's own CPU core which runs on its own host thread.
When I first ported Dosbox to Java I learned a lot about emulation. I even extended jDosbox to run a couple of Windows games without Wine but gave up on that pretty quickly. Then I got Windows XP to run on jDosbox but it was slow. After that I started thinking about how to make something like Dosbox but specific to Windows games. I wanted to run Windows games without Windows and without VM disk images, I wanted them to run directly from the host file system just like Dosbox. So that it how I started Boxedwine. I know a lot about the Dosbox CPU cores and my slowest core, in my code I call this NormalCPU, is somewhat similar in design to the Dosbox Dynarec core. My newer x64 and ARMv8 cores are complete different. The emulated registers no longer live in memory, but are mapped to host hardware registers. This is what makes it so much faster.
For example, right now I'm investigating a crash on ARMv8 for Quake 2. The instruction that it crashes on is
quake2.exe @ 0x42bf69
mov dx, [ecx+eax*2]
My ARMv8 code translates that to
add w9, w1, w0, lsl #1
ldrh w10, [x9, x20]
bfxil w2, w10, #0, #16
w0 = EAX
w1 = ECX
W2 = EDX
W9 = tmp
W10 = tmp
x20 = offset into emulated process memory space (4GB continuous reserved virtual memory, inside the 64-bit process)
So 1 emulated instruction in x86 gets translated to 3 ARMv8 instructions. Overall, I would say that's not bad.
Indeed, not bad at all. Especially considering that you are translating machine code from a CISC architecture to a RISC architecture, right?
It's a good thing all common operating systems run Aarch64 CPUs in little-endian mode, so you don't have to worry about the whole byte swapping thing. 😅
What about memory alignment, though? Didn't Apple have to implement something in their Apple Silicon CPUs to natively support the memory model of the Intel architecture, to allow for faster x86 emulation?
Note that I may be talking about things I know too little about. 😁
digger wrote on 2021-01-31, 21:26:Indeed, not bad at all. Especially considering that you are translating machine code from a CISC architecture to a RISC architec […]
Indeed, not bad at all. Especially considering that you are translating machine code from a CISC architecture to a RISC architecture, right?
It's a good thing all common operating systems run Aarch64 CPUs in little-endian mode, so you don't have to worry about the whole byte swapping thing. 😅
What about memory alignment, though? Didn't Apple have to implement something in their Apple Silicon CPUs to natively support the memory model of the Intel architecture, to allow for faster x86 emulation?
Note that I may be talking about things I know too little about. 😁
Yes, the fact that ARM systems are mostly little-endian helps a great deal.
As for memory, x86 guarantees some things about the order in which one thread will see the changes from another thread. So for a single threaded app there shouldn't be an issue. The Apple M1 chip did implement a TSO (total store ordering) mode that it uses to make their memory writes appear in other threads the same way as x86 and their Rosetta emulator uses that. I'm still worried this can cause issues for me. For apps that use the x86 LOCK prefix my code will work, but for code that doesn't use thread synchronization objects, like lockless programming, I think what I have now will fail. I'm hoping I will figure out a way to handle it, but I'm sure it won't be easy, otherwise Apple wouldn't have spent the money developing their TSO mode on hardware.
I'm kind of just hoping that the older games I'm targeting won't depend on a strong memory model.
I guess the easiest way to fix it, which is also a worst case scenario, would be to implement an app compatibility flag on the command line which will allow the user to launch a game with Boxedwine and force that game to only run on a single core.
The Raspberry Pi 4 port is going well. Quake 2 still doesn't work, it hangs right after it renders the first frame of the game. Quite a few other apps and games hang too. Roller Coaster Tycoon demo does ok, but seems to only run at about 1/2 the speed as on my desktop PC. I'm not too concerned about that. Once I get more games workings I will come back to improving performance. Here is a screen shot of Caesar 3 demo. It seems to run well and performance is good.
