adlipt
adlipt copied to clipboard
pdewacht
Implement adlipt functionality at the hypervisor-level (QEMU and/or VirtualBox OSE)
Hi! I absolutely love the OPLxLPT concept.
Although it's possible to use such devices with hypervisors running DOS in a guest VM, the only way to currently do so is to route the emulated LPT port on the guest to a physical LPT port on the host. This works, but it would still require either adlipt to be loaded in the guest VM or games to be patched. If the functionality of adlipt could be handled at the hypervisor-level however, the guest could be presented with an emulated virtual Adlib (Gold) or Sound Blaster card (which most popular hypervisors can already emulate), only with the FM-part of such card being routed to an OPLxLPT device connected to a physical parallel port on the host machine, instead of that part being emulated in software. The hypervisor would then only have to emulate the SFX DAC of the sound card (in the case of anything more advanced than an Adlib card).
The advantage of this over running adlipt in the guest VM, other than not having to load the TSR, is that this would also work with protected mode games.
In the specific case of VirtualBox, this would be an ideal addition, since the existing Sound Blaster 16 emulation provided by VirtualBox does not emulate any FM chips, but only the SFX/DAC/DSP part.
VirtualBox allows for the development of so-called extensions, so this functionality wouldn't necessarily have to be offered upstream. Oracle requires contributions to be MIT-licensed so they can also use it in their closed-source products. For developers who are not a fan of that, developing this functionality as an extension would be an alternative solution for VirtualBox. I've looked a bit into developing extensions for VirtualBox and it is not documented very well, but with some help I'd like to give it a shot. Maybe we can work on it together?
As for QEMU, I've also found this pending pull/merge request for something like this in QEMU by @vincentbernat, but the last reply/activity in that thread is from over 2 years ago. Also at first glance it appears to be for the OPL2LPT only. There is no mention of the OPL3LPT in that patch. Perhaps it's time to dust this off?
Support for this in VMware would be nice too, but personally I'm biased towards improving open source software over closed source software.
Thanks for considering, and thanks to everyone reading this who would like to help with this.
I don't know why I didn't get a v2 of this patch. Maybe, I was expecting a human to help on the pending issues. The patch has been updated here: https://github.com/vincentbernat/qemu/commit/a3672cc3412561e092dae37d0fa2858893bbd944. I didn't adapt it to OPL3LPT (while I did that for ScummVM and DOSBox), but this would be quite trivial to do.
OK, now I remember. The usleep() used is executed in the main QEMU thread. Not something you really want. I should have done like for DOSBox and use a dedicated thread for speaking with the OPL2LPT. I suppose I didn't find an easy way to do that in QEMU.
That doesn't sound insurmountable, right? Especially if we could find an experienced QEMU developer that could answer that particular question?
Also, do you have any experience with developing patches or extensions for VirtualBox?
Yes, a pointer to how to create/manage a thread in QEMU would be enough. As for VirtualBox, no experience and little interest to dig (Oracle is not really opensource-friendly).
True. I'm definitely not a fan of Oracle either. But VirtualBox OSE is open source and in my experience tends to be more optimized for virtualizing desktop stuff, particularly with regards to graphics virtualization. But maybe that's gotten better recently?
It's about time VirtualBox OSE got forked, though.
Anyway, perhaps the work of @kjliew could provide you with some pointers w.r.t. thread management in QEMU? That's the developer who implemented a Glide passthrough patch for QEMU, which allows a 3dfx Voodoo emulator to be passed through to a guest VM running DOS or Windows 9x.
Hmmm... On the other hand, apparently the Glide passthrough patch also runs on the main thread in QEMU: https://www.vogons.org/viewtopic.php?p=822114#p822114
But @kjliew does appear to be quite knowledgeable about how threading works in QEMU, so this might still be a good person to ask.
Looking a bit more, I could also modify to use timer_mod() and a state machine instead of creating a dedicated thread. I'll try to tackle this in the next weeks.
Hi @vincentbernat. Any news on this? :slightly_smiling_face:
Anyway, you might be interested to know that I opened a feature request in the DOSEMU2 project for this as well. Perhaps it will be easier to get it merged in there before QEMU accepts your work? See https://github.com/dosemu2/dosemu2/issues/1294
(It would still be awesome to eventually have OPLxLPT support in QEMU as well, though.)
By the way, it's completely okay if you're too busy to work on this. Just sharing this, in case you might find this interesting.
I was too busy and forgot about this.I am still interested by time is limited.