-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please support hardware Vxd drivers. #203
Comments
This would be great also for my retrogaming project - a lot of joystick Win98 only devices with VxD driver and proprietary force feedback (InterAct Racing Wheel) |
Unfortunately, the VxD driver model is completely different than the NT driver model, there is a reason why this wasn't implemented by Microsoft into the NTVDM and there are only VDDs (NT replacement to VXDs). VXDs are very specific to Win9x (16 bit) Kernel and there are no comparable facilities in the NT kernel or the emulated Win16 kernel of NTVDM. If you want to support real hardware which is connected to Host Windows and already has a driver working there, I suggest to write a VDD driver and a corresponding 16bit driver that interacts via BOPs with the VDD (that's the recommended way to implement NTVDM drivers). For interacting from DOS, this usually works fine. |
Here is an example on how to write your own VDD driver extensions to replace the VXDs: |
I have the reverse problem as the code I need to run is in the vxd, and the vxd I m talking about contains many register settings for the real hardware. |
First step is to reverse engineer the .sys driver, then you can try to write a 64bit driver based on your reverse engineering results. |
Something very hard as the userland interface is standard but hardware isn t. Those who attempted it never completed it. This is also why the Linux driver is stripped down in important features (especially the signal generator). Getting the vxd or the |
Of course, it's very hard, but I see no other way. In case it is a scanner driver, I recommend the appliction VueScan which has a very wide list of supported Scanners where no 64bit driver from the vedor exists. But "Signal generator" doesn't sound like a scanner. |
The other way is to behave in a ndiswrapper like manner by wrapping the required abi endpoints which unlike the driver are partly documented. The extreme difficulty for reverse engineering doesn t make wrapping more difficult (the fm generator require huge mathematical knowledge for being controlled). Otherwise, the user mode driver framework indeed allows to send irq to pcie from ring 3 on modern Windows. |
giveio64 has some weird tricks to access I/O ports directly also on 64bit Windows, from what I know, so it might become handy for porting the driver. Still, the problem remains to get a VXD running, as WOW16 architecture is lacking all the stuff that is required for running VXDs, as its kernel is different from Win 3.x/Win9x kernels, even though it uses part of the Win 3.x sourcecode. If there would have been a possibility to make it work, M$ most likely would have implemented it. |
In my case, the driver job is to translate the very complex handling of the card to the simpler standard Windows api. From there, I was able in 98SE to run standard 32 bits Windows Media Player or vlc to use the card (and even relatively recent versions of Firefox through the vista compatibility layer for 98 and ME until I had to switch to a computer with a Xeon without full 32 bits support). Though, I agree to accept running Windows 16 bits version of vlc if it can fix my problems. |
So, there is some Linux driver already (and some reverse-engineering efforts), it sounds interesting to extend. Could you provide more details about this device, please? Btw, there's an option to try dosemu/dosemu2 (VDM for Linux) or Win9x in KVM. It won't be an easy way (e.g. compared to working with real hardware from DOS in OS/2 MVDM) but it's not so painful IMHO as struggling with NT internals and tools. |
The over 20 years old Linux driver only does provide pcm signal conversion (using the card as a digital to analog converter which many more modern and any sound card provide). It doesn t handle the configuration of the signal generator which behave like a separate piece of hardware on the same chip (it also trigger a kernel panic if you try to use pcm input despite being in tree). There are however incomplete abandoned reverse engineering works on https://vogons.org on that part that still can t be used into any software (they just identified the code addresses in the vxd responsible for handling the registers of the card and identified most of them without understanding fully how they behave). Also my computer is a special 6Tib of ram one: it is controlled through an on board arm computer (the bmc) and the bios run os through virtualization (allowing to expose some of the arm hardware as direct x86 equivalent through virtualization). You can run userland 32 bits programs but can t run 32 bits oses. You also can t do nested virtualization (I had to disable HyperV security on Windows) and are supposed to run multiple os through the firmware s vendor web interface (the default is to have all sata and pcie hardware as pass through). |
Naming the card name and linking the Vogons-threads about it may be helpful for readers that are interested in the issue. |
Well... Is it possible to provide the name of this device? And which application/driver could use its full capabilities under which OS? Kernel panic isn't surprising, I guess there were no maintainers who had this hardware to test before accepting the driver. But it shouldn't be hard to fix, at least it provides much more information than BSoDs. |
(I m using the pci variant through a pcie adapter and the card is identified as I m interested in fm synthesis not as a way to generate poor unrealistic results, but as a way to create unsual sounds. Though just buying a Yamaha fs1r might be a larger but more straightforward computer controlled option. |
The project https://github.com/pachuco/ESSPlayMid looks active to me, does the demo player work with your card? |
As it uses assembly, it lacks 64 bits support. It also doesn t attempt to replicate the original sound bank and thus the quality. Though, he use |
Using asm isn't really a problem, also for 64bit driver. Just the IN/OUT stuff needs to be replaced with 64bit driver doing the port access (or giveio64.sys may also work), so this wouldn't be a real issue. If it's just for the banks to be used, this could be exchanged in the resource segment of the Usermode MIDI-driver AUDDRIVE.DLL easily without even needing to reimplement this driver |
Essplaymid is just for doing the reverse engeeniering work (check prior versions of the readme). You have to test ideas to check is they are true. https://www.vogons.org/viewtopic.php?p=738552#p738552 says said bank (registers) is in the kernel driver. After all, the card has in hardware opl3 compatibility. If it s just for basic midi, a more documented way would be to port the old vxd opl3 Windows driver which used adlib sound banks. |
The tables are both in the usermode MIDI driver:
Or which tables do you mean? |
A third thing: on Windows 11 kernel dll need to be in 64 bits. |
Kernel DLL? The MIDI driver DLL is always user mode, the .SYS driver is kernel mode, when using the Installable Driver concept that also goes with the NT4 driver. The installable DLL driver (AUDDRIVE.DLL) is always 32bit, regardless if running under 32bir or 64bit Windows afaik (check default wdmaud.drv, it's always 32bit). The kernel mode driver AUDDRIVE.SYS mostly consists of a lot of functions from the well-known Soundlib where source is known, so there are just some ES1868 specific functions to reverse-engineer and implement and then compile it as a 64bit driver to be compatible with the IOCTLs that the DLL driver sends. |
So I had a look at the drivers:
So getting the Win2k/XP driver to use the same method as the NT4 driver is relatively easy, just patch the routine that checks for OPL3 to return FALSE and - if needed - patch the appropriate sound bank into the driver (bnk_NT4.bin is present, can be swapped with bnk_common.bin). So as I understand, the sole problem then is that there is no x64 version of the driver, thus not working on Win11, so driver es1969.sys needs to be ported to x64, OPL3 support turned off and maybe functionality to add custom table added? |
If this true, yes. Previous reverse engineering on Vogons.org told that the midi functionality was working only in opl3 compatibility mode instead (leaving only the modern pcm playback working normally) of the advanced one, leaving only some games being able to use the ess functionality. The second problem is my bios run oses in virtual machine mode while disabling vm inside vm acceleration thus only allowing 64 bits os to run unless some customs modes like yours is used (Windows 98 inside a browser based Javascript vm indeed works but without access to the hardware). |
Does your 64bit Windows generally support the soundcard? |
Both things are true. |
Though if creating a new port, a general midi level 2 driver which can understand the sysex message for controlling harmonics effects would be great too (General midi level 2 was made in 1999). I meaning partial support. |
Here is the driver that you requested, x64 driver for ESS soundcards with ESFM support: |
The point is ntvdm already supports vxd loading like
dsound.vxd
for providing DirectSound support.On the other end, there are more and more hardware like Fax and hardware‑based sound synthesisers which only have legacy vxd or early ɴᴛ drivers like the ᴏᴘʟ3 card.
Would it be possible to get those vxd to pass low‑level data to such ᴘᴄɪ or even ɪꜱᴀ devices ? Of course, the hardware would only work with Windows 16‑bits applications.
The text was updated successfully, but these errors were encountered: