How do you know you've been working on emulators for too long?
I was testing Age of Empires with the ARMv8 core and when I selected a unit and told him to go somewhere, he took off in the wrong direction. As soon as I saw this, I knew there was a bug in the FPU. 😀
That's hard-core, man.
In The Matrix, Cypher commented that he didn't even see the code on his screen anymore, and instead would immediately visualize it in his head: "Blonde, Brunette, Redhead..."
You're the opposite: you look at a character walking weird, and you immediately see the code behind it. 😅
digger wrote on 2021-02-21, 18:53:That's hard-core, man.
In The Matrix, Cypher commented that he didn't even see the code on his screen anymore, and instead would immediately visualize it in his head: "Blonde, Brunette, Redhead..."
You're the opposite: you look at a character walking weird, and you immediately see the code behind it. 😅
The ARMv8 core is the 3rd core for Boxedwine, I think maybe I just saw a similar bug when working on one of the other cores. Or perhaps I passed 10,000 hours on programming emulators (if you believe that random number from the Outliers book). Finding bugs is definitely much easier for me now than it was in the first couple of years. I remember spending close to 80 hours on a single bug in jDosbox. But for Boxedwine, it is weird to spend more than a few hours on a single bug.
I'm starting to see Quake 2 run. I got it to complete a timedemo. In software mode at 640x480 I got 16.3 According to a graph I saw, this puts it at about the same speed as a Pentium II 233MHz. That doesn't seem too bad for the Raspberry Pi 4 to start with. It is a very FPU heavy game, so I'm happy to see the FPU code performing well. Because of the stack nature of the x86 FPU, I wasn't able to keep the FPU registers in ARM registers, so each instruction has to fetch the FPU register from memory then write back the result.
danoon wrote on 2021-02-22, 17:08:I'm starting to see Quake 2 run. I got it to complete a timedemo. In software mode at 640x480 I got 16.3 According to a graph I saw, this puts it at about the same speed as a Pentium II 233MHz. That doesn't seem too bad for the Raspberry Pi 4 to start with. It is a very FPU heavy game, so I'm happy to see the FPU code performing well. Because of the stack nature of the x86 FPU, I wasn't able to keep the FPU registers in ARM registers, so each instruction has to fetch the FPU register from memory then write back the result.
That is quite impressive indeed, considering that I was getting similar Quake2 performance on the power-hungry AMD FX over 3GHz with QEMU TCG with x86->x86. That also implies that once you got OpenGL pass-through working for the RPi4, Quake2 would be fully playable at over 30 FPS.
I am also very eager to jump into the ARMv8 bandwagon nowadays and start qualifying the performance of QEMU TCG ARM->x86 and check out how many x86 PC games are playable.
I'm also curious how QEMU TCG ARM -> x86 will perform. I looked into TCG when starting Boxedwine. I'm sure its come a long ways since I last looked at it 10 years ago. It was pretty simple then, but the benefit of that was it was quick when generating the code. Since my ARMv8 code always translates every instruction (not JIT), I also try to keep the decoder/encoder as fast as possible. But even so, there is a lot of code to run when starting up Wine so it takes several seconds just to start the game/app on the Pi. Maybe in the future I could cache the generated code to speed up start times.
There is definitely a lot to work with on ARMv8 now. After the Pi, I plan to get Boxedwine running on the M1 chip. I can't wait to see how the M1 performs compared to my x64 core on my desktop machine.
It's a big deal if your implementation could match or outperform QEMU TCG ARM->x86. So far none of the other architecture portable dynarec/JIT could even match the performance of TCG x86->x86.
I don't use anything from Apple, but getting the Apple M1 macbook air is enticing simply because of the fastest ARMv8 core to play with. And, the Apple M1 macbook air form-factor is perfectly sweet. I hope the market for Linux ARM laptops similar to Apple M1 macbook air will blossom one day to offer viable alternatives for open-source ARM ecosystem development.
I have always believed in the ARM's simple design advantage if it were given the same clock and thermal budget together with design principles on performance first rather than power efficiency. Apple did it with the M1. When Google and Microsoft follow suit, it would just be a matter of time for the ARM software ecosystem to build up in similar quality and abundance as of x86 long entrenched advantage.
kjliew wrote on 2021-02-23, 18:39:I hope the market for Linux ARM laptops similar to Apple M1 macbook air will blossom one day to offer viable alternatives for open-source ARM ecosystem development.
I have always believed in the ARM's simple design advantage if it were given the same clock and thermal budget together with design principles on performance first rather than power efficiency. Apple did it with the M1. When Google and Microsoft follow suit, it would just be a matter of time for the ARM software ecosystem to build up in similar quality and abundance as of x86 long entrenched advantage.
Linux will soon be usable on the M1 thanks to the Asahi Linux project.
Google and MS have been making ARM based laptops for several years already, Apple just charmed the press into thinking they were the first (just like they did with the iPod/iPhone).
MS offerings in this area have been rubbish, to say the least.
I wouldn't say that. I have a 2019 windows on arm laptop that gets faster benchmarks using the x64 build of DOSBox (via x86_64 emulation) than a proper arm64 build of DOSBox. Their emulation is fairly impressive even without the x86 support hacks that apple added to their hardware.
If you're looking for an affordable and developer-friendly ARM-based laptop, you might want to take a look at the Pinebook Pro. It is currently out of stock, but it can be preordered for $199.
* https://www.pine64.org/pinebook-pro/
* https://pine64.com/product-category/pinebook- … ?v=0446c16e2e66
There's also the regular Pinebook, which is even cheaper, but has lower specs (for instance, just 2GB of RAM instead of 4GB on the Pro). Linus Tech Tips did a review video on the regular Pinebook a while back. It's not suitable for most regular desktop users, but it would work just fine for developing and testing dynarec and/or TCG implementations. After all, if you can make your implementation run reasonably well even on a lower spec laptop/SoC, then you'll know it's very efficient. 😉
I remember when OS X dropped support for Rosetta after I did an update. I was not happy to see the icon turn to an invalid icon for one of my OS 9 games, Bob the Builder, that my kid played. At the very least it would have been nice for them to warn me with a giant dialog saying that my app wouldn't work after the update. I wonder how long the current Rosetta will last. I often wonder if Microsoft is talking about retiring Win32 yet. That is what made me want to do Boxedwine, I wanted an app as easy to use as Dosbox without all the disk images, but for Win32. When I heard about the M1 I hoped that I could have finished a Boxedwine build for the M1 chip when it was released, but it turns out ARM->X86 took a lot longer than I thought. Right now I would be happy if I had a decent build for the M1 in 6 months.
Win32 as in 32-bit support? Because they still call the whole main windows API "win32", to distinguish it from all the other failures/crap (win CE, win RT, etc) even though it's mostly no longer limited to 32-bits.
jmarsh wrote on 2021-02-24, 16:27:Win32 as in 32-bit support? Because they still call the whole main windows API "win32", to distinguish it from all the other failures/crap (win CE, win RT, etc) even though it's mostly no longer limited to 32-bits.
I always assumed they had another name for the 64-bit API 😀 I stopped doing Win32 programming right around the time .NET came out. I did embedded c and j2me for a while. Now for the last 9 years I've been working on an iOS app.
I think they are collectively called "Windows API" now, but still make reference to "Win32" on and off.
https://docs.microsoft.com/en-us/windows/win3 … indows-api-list
I wonder if sites like GOG and Steam are starting to talk about ARM. It would be cool to see GOG survive the change. Speaking of which , Boxedwine might be used to bring a 1997 game to GOG next month. I will post a link when its official.
GOG haven't even bothered to fix their games to be able to work on past macos (64-bit apps only) let alone the latest.
In Windows I tried using Boxedwine with Requiem: Avenging Angel (1999), and Gunmetal (1998). The former runs fine until I get into the game proper then the performance tanks, and Gunmetal is kind of infamous for running too fast on modern machines and strangely ran too fast in the menus, then the framerate ultra tanked and it went down to like 1-2 frames a second ingame. Actually, when I first tried using it, the games wouldn't run in Boxedwine's 64-bit executable, then suddenly after using the 32-bit executable once, they finally did open in the 64-bit one. I got the "better" results with the 64-bit executable, as they ended up both running too slow consistently in the 32-bit executable.
alberthamik wrote on 2021-03-01, 11:55:In Windows I tried using Boxedwine with Requiem: Avenging Angel (1999), and Gunmetal (1998). The former runs fine until I get into the game proper then the performance tanks, and Gunmetal is kind of infamous for running too fast on modern machines and strangely ran too fast in the menus, then the framerate ultra tanked and it went down to like 1-2 frames a second ingame. Actually, when I first tried using it, the games wouldn't run in Boxedwine's 64-bit executable, then suddenly after using the 32-bit executable once, they finally did open in the 64-bit one. I got the "better" results with the 64-bit executable, as they ended up both running too slow consistently in the 32-bit executable.
Yes, the 32-bit version of Boxedwine can be pretty slow. A lot of my time now is spent on the 64-bit version because it performs so much better. I tried the demo of Gunmetal on the 32-bit version of Boxedwine with my i7-6700 and it seemed somewhat playable, the sound had a lot of issues, but the controls, menus and just overall feel seemed pretty good. For the 64-bit version, it was a mess, completely unplayable. If I just tapped a key, it would bring me to the other side of the room. I didn't look into the running code, but I assume they are using the RDTSC (time stamp counter) for timing. This does not work on multi CPU systems because each CPU has its own RDTSC counter. For my x64 builds, I use the hosts RDTSC, so I don't emulate it at all. That might explain the crazy behavior. For my 32-bit build, I think I emulate it pretty well. This game might work well in Boxedwine using the 32-bit build, but on a faster computer than I have. What was the speed of your computer?
I will experiment with adding an emulated rdtsc instruction on x64 (kind of like a compatibility mode). It will slow it down, but that should be fine because it should only be necessary for older games.
danoon wrote on 2021-03-01, 21:21:What was the speed of your computer?
I have an i7-4790k, which is not a slouch of a CPU, but I think alot of modern emulators hate it. Also if RDTSC can at least fix Gunmetal that would be amazing. I'm sad Requiem was acting weird. It performs fine in modern windows but is a PITA to record in OBS because it alternates between two different windows for game menus and ingame. Meaning Boxedwine in theory could be great for playing the game in windows to capture in OBS. But for me, it ran too slow.
Well actually, I've had friends on Windows who've just been flat out unable to play Requiem for some reason, so if it could work in Boxedwine no problem I can finally recommend it to them.
alberthamik wrote on 2021-03-02, 04:14:danoon wrote on 2021-03-01, 21:21:What was the speed of your computer?
I have an i7-4790k, which is not a slouch of a CPU, but I think alot of modern emulators hate it. Also if RDTSC can at least fix Gunmetal that would be amazing. I'm sad Requiem was acting weird. It performs fine in modern windows but is a PITA to record in OBS because it alternates between two different windows for game menus and ingame. Meaning Boxedwine in theory could be great for playing the game in windows to capture in OBS. But for me, it ran too slow.
Well actually, I've had friends on Windows who've just been flat out unable to play Requiem for some reason, so if it could work in Boxedwine no problem I can finally recommend it to them.
As for Requiem, what was the issue? I was able to get the 3dfx version to work, but the D3D version always complains about DirectX 6.1.
If you use the Boxedwine UI, after you install the game, go to the containers tab, select the Requiem container, and install nGlide (see attached screen shot). In that same screen, I created a new shortcut to config.exe, then launched that from the apps screen of Boxedwine UI and selected 3dfx.
