VOGONS

Common searches


First post, by almeath

User metadata
Rank Member
Rank
Member

I have recently forked DOSBox SVN on Github to provide a customized version for macOS (Intel 64-bit). It currently incorporates the following patches:

- Munt : for MT-32/CM-32L emulation
- Glide : ready to use with the OpenGlide library for 3dfx graphics "pass-through" support (see my OpenGlide fork on Github)
- 3dfx Voodoo : software emulation of the 3dfx Voodoo graphics card
- Nuked OPL3 : emulates the Yamaha YMF262/CT1747
- Memory : increases memory limit to 384mb for use with Windows 9x
- Large HD : increases hard drive image size limit (seems to work reliably up to 8GB), also useful for Windows 9x
- CGA monochrome : machine type cga_mono is available, use F11 to cycle through amber, green, white, paper white
- Fluidsynth : Fluidsynth software MIDI synthesizer
- 4mb vram : Increases video ram for emulated S3 video chip to 4mb (better performance in some games such as Duke Nukem 3D)
- PC speaker : patch to improve the authenticity of PC speaker emulation (can be enabled/disabled)

My Github fork is here:

https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

I have also provided a pre-built version for those who are unable to compile from the source:

https://www.dropbox.com/s/qaz72fxo0zhhbho/DOS … 64.dmg.zip?dl=0

The DMG contains two versions:

- A 'standard' DOSBox application that operates the same as the one you would download from the DOSBox website
- A 'self-contained' bundle that I developed myself. You can duplicate it as required to create individuals apps for your DOS games (they should be transferable between different Macs)

I have included full instructions for both versions in the DMG file.

My intention is to keep both the forked source code (with build instructions) and pre-built apps up to date, incorporating additional patches that I find useful.

I am interested in receiving feedback on these apps, as I have only run and tested these on my own Macs - a 2019 iMac and 2015 MacBook Pro. It would be good to know if these work as intended or if I need to fix any outstanding issues.

Thanks in advance. 😀

Reply 2 of 18, by almeath

User metadata
Rank Member
Rank
Member
Warrex wrote on 2021-04-06, 10:49:

Thank you very much! Can you provide a universal app with native support for Apple Silicon / the M1 SoC / arm64? I did not find any info on that in the "Compile SVN in macOS?"-thread.

No problem, hope you find it useful.

On the issue of Apple Silicon support, I am dependent on the upstream development of the DOSBox SVN source. All I am doing here is implementing various custom patches to the source and ensuring operability with current versions of MacOS. I only have access to Intel Macs, and more importantly I do not have the coding skills to implement support for a new architecture.

Currently the official DOSBox (0.74-3-3) only supports three architectures on the Mac ; x86_64, i386 (i.e. 32-bit, for MacOS Mojave or earlier) and PowerPC. It is not 'universal' in the current sense of the term (i.e. x86_64, Apple Silicon).

You might want to check out the DOSBox Development sub-forum, as there may be discussions in there about planned support for Apple Silicon. As soon as it is available in SVN, it will automatically be available in my fork as I keep it on par with the SVN source. That will apply to the Github source, but I will not be able to test anything until I purchase an Apple Silicon machine.

Reply 3 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

so far there is no satisfying solution for the silicon. The dynamic core is not working (crashes) and there are solutions in other forks but these are mostly hackish and affects other architectures negatively (e.g. works on silicon but crashes on x86_64).
BUT so far Rosetta2 is amazing and SVN runs really fast. I can provide benchmarks later 😀

Edit:
Benchmark PCPbench:
iMac Pro 3 GHz, Core 10 Intel Xeon: 167 fps
MacMini 2.5 GHz, Dual-Core Intel Core i5: 105 fps
MacMini M1 (Rosetta2 emulation): 127 fps

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 18, by Warrex

User metadata
Rank Newbie
Rank
Newbie

Thank you both for the feedback!

PC Player Bench - have not seen that in a very long time. 😀 As for the scores themselves they seem to be pretty underwhelming considering that the M1 has like 3x the ST performance of the 2.5 GHz Intel Core i5-3210M and 6x the MT performance. The GPU is also much faster.

Reply 5 of 18, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox SVN on ArchLinux x86_64
Benchmark PCPBench on Ryzen 2500U
PCPBENCH /once
VESA LFB 640x400 - 179.8 fps
PCPBENCH 4101 /once
VESA LFB 640x480 - 159.5 fps

/EDIT by DOSFREAK DELETED non-related information

Last edited by kjliew on 2021-04-07, 19:02. Edited 3 times in total.

Reply 6 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

No one needs more than 30fps in PCPBench 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 7 of 18, by Warrex

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote on 2021-04-07, 18:29:

No one needs more than 30fps in PCPBench 😉

How dare you! It is as important to be the king the school yard as it ever was! 😉 Guess I have to wait for the Apple Silicon fixes then.

Reply 8 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Splitt off the other Qemu discussion to not further derail this thread. Sorry for derailing it to begin with through the benchmark posts. Wasn't intended. Please continue the Qemu discussion at DOSBox SVN - Qemu on M1 benchmark comparison discussion

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 9 of 18, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-04-07, 19:29:

Splitt off the other Qemu discussion to not further derail this thread. Sorry for derailing it to begin with through the benchmark posts. Wasn't intended. Please continue the Qemu discussion at DOSBox SVN - Qemu on M1 benchmark comparison discussion

That's OK, I am sure people are keen to hear about the progress with Apple Silicon support.

Reply 10 of 18, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I could get vanilla DOSBox SVN r4456 compiled for M1 macOS. Normal core works fine but dynarec crashed with protection error. I believe this has to do with what @jmarsh had been proposing in fixing JIT memory attributes problem with modern security harden OS and Apple had published a whitepaper for porting mprotect/JIT on new macOS.

What's the best solution now to have a single code base from SVN that works across x86_64 and AArch64 for Intel/AMD and Apple M1?

As far as I can understand from @Dominus, dynamic_x64 x86_64 build (or was that actually dynarec x86_64 build??!) translated by Rosetta 2 was working out great. I am curious if native code dynarec AArch64 would be similar in performance if Dominus really had dynamic_x64 translated instead of dynarec. For DOS games, dynarec for most of the time, is good enough.

Reply 11 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, getting it to compile is easy but the dynarec core needs adjustments. The ones found in forks is not really ideal and not stable.
My x86_64 build is working fine but a native Apple-Arm64 would probably be even faster.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 12 of 18, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2021-05-17, 22:21:

My x86_64 build is working fine but a native Apple-Arm64 would probably be even faster.

Is your x86_64 build using dynarec or dynamic_x64?

It depends, native code dynarec may not be faster than dynamic_x64 translated. It would be amazing if native code dynarec is actually faster than dynamic_x64 translated. I am looking forward for native code compilation. I have no desire to use Rosetta 2. Anyway, dynarec x86_64 on Windows/Linux build is good enough for most of the DOS games, considerably faster than normal core for games that need that kind of CPU performance.

I thought dynarec is already working on other AArch64 such as RPi4, Rock Pi and ODROID platforms. So dynarec itself isn't broken, it just needs to adapt to setting up memory attributes on cacheblocks for OSes with security harden features. All modern OSes (Linux, Windows, macOS etc.) will soon require that for software that execute generated codes during runtime. Thanks to the paranoid world we now live in for software vulnerabilities.

Reply 13 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I have to confess that I have no idea about the difference between dynarec_x86_64 and dynamic_x64. Let alone that there are two dynathings that work on x86_64.
So by default I guess it's dynarec?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 14 of 18, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

For recent SVN, Windows and Linux 64-bit builds should be default to dynamic_x64, not sure about macOS. I have never used any Mac in the past, the M1 is my first Mac. Non-x86 default to dynarec and had been in used by ARM SBC folks and Android forks.

BTW, OpenGL output rendered at lower-left instead of filling up the window decoration. I think this is an inherent problem with SDL1.2 lacking support for HiDPI retina display. Perhaps it is time for official DOSBox to finally adopt SDL2. QEMU SDL2 is doing great on M1 despite lacking hardware virtualization, but for DOS games I still prefer DOSBox and its excellent sound hardware emulation. QEMU + DOSBox is all I need for all my legacy DOS/Windows games on M1 😉

Reply 15 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The OpenGl problem is not caused by the Hidpi Retina display.
Otherwise it would have been a problem on my side for years now.
But doesn't change the fact that it's likely to be magically fixed by using SDL2

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 17 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I think it was the matter of using the latest SDK (or the 10.15 at least) with the right minimum supported x86_64 target (10.10). Using the 10.14 SDK was causing it, I think (I should really take notes, I tend to forget when I solve it).
You can try my build in the signature

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 18 of 18, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

From /Library/Developer/CommandLine/SDKs/, I am already at MacOSX11.3.sdk on the M1 and it does not solve the OpenGL output problem. I didn't really bother with the version of SDKs. When I ran "make or gcc" on the Terminal, the system just prompted to install Developer Tools and pulled everything from the cloud. Thanks for the build, I guess I will just stick to native build and use normal core for now until DOSBox devs pick up the steam for M1 support.