I'm slowly discovering how to compile using the virtual machine

[4nd3r50ncr]

@volkertb when you generate the .mak use this... gpr2mak -d- SBEMU.GPR

We need to maintain firmer contact to work together

[volkertb]

Thanks for reaching out! See my reply to @thp here.

I'll try your suggestion. If that is indeed the solution for generating properly working Makefiles from SBEMU.GPR, that would be wonderful! I actually had to closely follow how RHIDE was building the project by running it in a very slowed down VM instance and recording the output of the compiler and linker commands that appeared on screen. 😅

If this works, I'll update my CI/CD setup MR to make use of it. Thanks!

[thp]

I'll try your suggestion. If that is indeed the solution for generating properly working Makefiles from SBEMU.GPR, that would be wonderful! I actually had to closely follow how RHIDE was building the project by running it in a very slowed down VM instance and recording the output of the compiler and linker commands that appeared on screen. 😅

For me personally, my minimal Makefile is more comfortable, as @crazii is currently on hiatus (it seems) and everyone else seems to want to develop this on non-DOS machines, so trying to keep things working with GPR and RHIDE which nobody who actively tries to contribute uses seems unnecessarily complicated for the time being. I still haven't figured out where to get this gpr-to-makefile utility, and gpr seems to be in some kind of weird binary format that doesn't lend itself to being managed with Git in terms of seeing changes using "diff".

I wouldn't worry about the GPR and Makefile getting out of sync. We can cross that bridge when we get there (if/when @crazii picks up development again and they want to make it work with RHIDE again, in case it ever gets out of sync).

IMHO Building this project should be as simple as git clone + make (assuming a DJGPP toolchain is installed) on any modern host OS (Linux, macOS, Windows).

My filename case changes I needed to do to make it build on case-sensitive filesystems shouldn't affect the build on GPR/RHIDE at all.

That's just my two cents and personal opinion. It took me a while to figure out how to build the project, and the codebase not working on case insensitive filesystems and using a weird build tool (either run it on a retro machine or in DOSBox?) doesn't lend to quick edit-build-test cycles. Being able to build on a modern Linux machine with parallel builds and a modern version of GCC / DJGPP is quite convenient.

[4nd3r50ncr]

I wouldn't worry about gpr, it actually makes it more disruptive and wastes more time, so discarding it would at least be more obvious. Now, an opinion, we could even port the entire project to pure gcc currently, I don't know if Linux's gcc can generate a working .exe binary. I managed to compile it with gpr2mak, however it is terrible, worse than the original, as it is not paired with the original file created by crazy in the .gpr file, so that's it, a make file, for both it would be much more interesting, as djgpp for DOS can also compile makefile as you know.

[volkertb]

Okay, so does that mean we would be better off forking it at this point, and perform the improvements you suggest, to ease cross-compilation from within Linux and modern build environments? Also, are you aware of Baron-von-Riedesel's VSBHDA fork?

Ultimately, what I would like us to work towards is a modular emulation solution, that would combine the funcationality of SBEMU and SoftMPU, and have some kind of pluggable or otherwise modular support for various sound drivers (AC'97 ICHx, Intel HDA, USB Audio, virtio-snd, OPLxLPT, etc). I'm currently experimenting with AIL/32 as a possible driver model for this, trying to port sound drivers from Linux and/or xBSD (OSS) to AIL/32, with the idea of those drivers then being loadable by an improved version of SBEMU.

Long story short: a universal sound emulation framework that focuses on the main challenge, namely the hard part of port trapping hardware access, including DMA support, both in real mode and protected mode games, and being otherwise modular and extendable.

What do you guys think? Is that a crazy idea?

[thp]

I've created https://github.com/sbemu-x/sbemu-x -- including in a separate organization so it's easy to give out permissions for new contributors and not have the new fork be a one-off dead project again. Happy to have the fork obsoleted at some point, and things re-integrated into upstream, but until that time let's develop things there? @volkertb you should have an invite in your inbox for the org.

[4nd3r50ncr]

@volkertb I'm struggling too much, and I'm not able to compile without using gpr2make, I'm trying to configure the makefile, so that it can be compiled directly in DOS. Can you take a look for me?

makefile.zip

[volkertb]

@thp Joined! Thanks for inviting me. I'll port my GitHub Actions Workflow PR to the sbemu-x project and offer it as a PR there soon. Hopefully I'll have time for that this coming weekend.