Added missing functions in C-port

[leecher1337]

I don't have such a soundcard myself, so I cannot test anything, but hopefully the C-port works, please check.
Just made a MSVC6 .dsp project file, you may want to make your own makefile for building it.

[pachuco]

I will fully check when I get at home.

Some method to the madness/laziness: /src/crud/* was once /src/*, but I pushed the code off the desk into the trashcan and didn't quite have the heart to discard it. Perhaps I could have used a branch instead.

Now for nitpicks.
QPCuWait() should just spin on QueryPerformanceCounter(), without yielding thread. I assume this is how KeStallExecutionProcessor() works and that our usage will not exceed 50 uSec of delay(MS reccomendation). The use of this is to prevent clobbering of IO ports.

/src/esfm.c should remain dependency neutral and written with stdint. It is intended to be a lib that one may use for whatever. Maybe a driver with real hardware, maybe usermode midi plugin paired with softemu(such as https://github.com/Kagamiin/ESFMu when it gets completed).
This lib that converts midi to ESFM messages is the goal of this repository.

Thirdly, I see you have made MSVC6 makefile/project files. I would have to maintain those or they will fall into bitrot.

Fourth, are you aiming for creating a whole windows driver?
This is outside of the scope of this repository.
The subject of a separate repository perhaps. However, we must consider the merits of the existing ESS win2k/xp driver which has at least two bugs.

1. Janky handling of midi tone portamento.
2. Recording and playing back sound at same time results in noise bursts in the recording. I suspect locking issue.

Thus, if such a driver is desired, then perhaps linux has better codebase(minus the proprietary ESFM bit; they have OPL3 mode midi).

What are your thoughts?

[leecher1337]

Thanks for your comment.
I just came over here because of a thread at my main project: leecher1337/ntvdmx64#203
A user requested the possibility to run Win9x VXD drivers under Windows NT, which of course if aboslutely impossible due to the completely different OS architecture.
But I found out what the users goal was: He wants to use his ESS based soundcard on a Windows x64 machine using the ESS MIDI implementation. So I thought it may be enough to port over the 32bit driver to x64 or at least create a MM usermode driver (using giveio64.sys to also run on x64 Windows) in order to use the hardware.
So I saw that you already disassembled the NT4 drivers which seemed to be a good starting point. That was the motivation. However what I do not understand is that the user mentions that only the Win9x or OS/2 driver has the desired MIDI functionality, not the NT-driver. As fast as I understand, the NT4 driver uses the requested custom stuff and the Win2k driver uses it as a fallback if OPL3 is not available. So am I even on the right track by porting the NT4-driver?

As for QPCuWait:
I just made your __asm("pause") portable. Possible #defines in windows.h are:

#define YieldProcessor _mm_pause
#define YieldProcessor() __asm { rep nop }
#define YieldProcessor __yield

So as your code is to be compiled on Windows, I thought that I should also the same instrnsics that you used. So I was mistaken and should use the QPCuWait from main.c instead?

As for the stdint.h, I understand, as stdint.h was not available under VC6. I can revert this back to stdint.h, and include some defines that define the stdint types on #ifdef _MSVC_VER < 1800, then this should be portable.
Still, the fixes to retain C89 compatibility (declaration scope) should remain. Generally a good idea if you want to keep it portable.

The msvc6 Makefiles are just there to test the code a bit, you can compile the sources with whatever compiler you want. It was mainly for the to make my life easier but not having to mess around with MinGW horrors.

I can crate my own repository for the driver, of course. Just wanted to contribute my IDA-Databases und RE-results to your project, as I was under the impression that you wanted to make a C-Port of the now-working ASM player.

Do the mentioned bugs in the driver also occur on NT4 or just with the Miniport driver in Win2k/XP?

[pachuco]

Lettuce see...
Yes, I condone the giveio64.sys approach. This is assuming he has regular sound driver for the card on 64bit windows. If not, extra activations on the PCI bus will have to be performed(a proper driver at this stage).

This user that says only win9x/os2 has required midi functionality and not nt4 driver... he should be redirected to this repository and describe the differences in implementation. I would be very interested.

QPCuWait from main.c, yes. Sorry for shitting duplicate code around...

Yes, I want C port of the asm player. Though, know that I've botched my asm port as per issue #1.

The NT4 driver does not have the tone porta midi bug like the win2k/xp one. I have not used it enough to know how well it handles recording and playback of pcm audio.

[pachuco]

So am I even on the right track by porting the NT4-driver?

Follow the outline portayed in /src/esfm.asm and /src/esfm.c
Another tell-tale sign is writes of this shape(relative to base)
https://github.com/pachuco/ESSPlayMid/blob/master/src/esfm.c#L70

[ytrezq]

I don't have such a soundcard myself, so I cannot test anything, but hopefully the C-port works, please check. Just made a MSVC6 .dsp project file, you may want to make your own makefile for building it.

I can lend my pci sound card to you.

[pachuco]

Psst, @ytrezq
#4

[leecher1337]

I can lend my pci sound card to you.

That should work, my mainboards still have PCI ports.
I just found an ES1938S in my hardware dump at home, would that also be sufficient for testing or do I need an ES1989S?

If I need an ES1989S, you'd have to pay for the shipping costs to Austria forth and back, I see that a used card incl. shipping is around 40$ on eBay, so depending on your location, this may also be an option.

[ytrezq]

I can lend my pci sound card to you.

That should work, my mainboards still have PCI ports. I just found an ES1938S in my hardware dump at home, would that also be sufficient for testing or do I need an ES1989S?

If I need an ES1989S, you'd have to pay for the shipping costs to Austria forth and back, I see that a used card incl. shipping is around 40$ on eBay, so depending on your location, this may also be an option.

ᴇꜱ1938 series cards were adverting the said full compatibility with previous ɪꜱᴀ cards from the brand, so it means ᴇꜱꜰᴍ. In fact, only those cards bring the ᴘᴄɪ variant. If you still have the original driver ᴄᴅ, I would be interested.

[pachuco]

I can lend my pci sound card to you.

That should work, my mainboards still have PCI ports. I just found an ES1938S in my hardware dump at home, would that also be sufficient for testing or do I need an ES1989S?

If I need an ES1989S, you'd have to pay for the shipping costs to Austria forth and back, I see that a used card incl. shipping is around 40$ on eBay, so depending on your location, this may also be an option.

https://gist.github.com/discatte/a7aacd0e46233846f17af77be9c22903
Czech out this product listing, look for "ESFM synthesis".

Edit: oops, product listing older than product! Lettuce google...

ES1989S: I don't think so
ES1938S: yasssss

[leecher1337]

Hm, both are not listed in the sheet you provided? But I read on data sheet

https://www.alsa-project.org/files/pub/datasheets/ess/DsSolo1.pdf

The Solo-1 integrates ESS’ field-proven hardware design
for DOS game compatibility with hardware FM synthesis
(ESFM) and three methods for legacy audio control
interface:

As the ES1938S is "Solo-1", I guess it should work, so I can test if I get it running on an x64 machine?

[ytrezq]

Hm, both are not listed in the sheet you provided? But I read on data sheet

https://www.alsa-project.org/files/pub/datasheets/ess/DsSolo1.pdf

The Solo-1 integrates ESS’ field-proven hardware design
for DOS game compatibility with hardware FM synthesis
(ESFM) and three methods for legacy audio control
interface:

As the ES1938S is "Solo-1", I guess it should work, so I can test if I get it running on an x64 machine?

They won t run as is on Windows.

[leecher1337]

They won t run as is on Windows.

Well, that's why we want to write a driver for them, right?

[ytrezq]

They won t run as is on Windows.

Well, that's why we want to write a driver for them, right?

Correct. Though pcm is just playing 44Khz at 16Bits. Today, even a 10 years old notebook works at 64 bits with 128Kb/s per second. You better have to broadcast sound to your phone (effort doesn t worth it).

It s just for esfm and midi.

[pachuco]

es1969.sys.idb is newer version than IDA 6.8. Thus cannot be opened on my end.

[pachuco]

I am introducing functions one by one, from /src/crud/essfm.c, into /src/esfm.c.

The results are mixed...

I will push back into your driver branch as I go.
Do you like this plan?

[leecher1337]

Unfortunately I don't know a way how to backport an IDB, but 6.8 didn't have Undo-function is Decompiler, which is very frustrating. I tried exporting IDC and import in IDA 6.8, but it doesn't know most directirives, as it seems, so this is also a dead-end. I can export a pseudocode .c and .h for the structure definitions, if that is helpful.

Testing and fixing my ported functions sounds good, so pushing the fixes back would be fine. Let's see how many mistakes I made ;-)

[pachuco]

The !! functions in commit message are borked from my trials. I have assumed that calling convention is STDCALL.
At least one of those borked functions is my own port.

[pachuco]

It's maddening, because, porting code to C introduces bugs over the original ASM port, which introduced at least 2 or 3 bugs over the original replayer.
AAAAAAAAAAAAAAAA

[leecher1337]

STDCALL should be correct, AFAIK it's the standard Calling Convention on Windows anyway.
How do you do the tests? I would log the input and output state of each function and compare outcome of the ASM and the C call and check for differences.

[pachuco]

I throw midis at the damned thing until "something is off". I then compare between latest rev, an earlier rev, and the XP driver's built-in implementation.
I have no data tools in place, so my ears are the judge.

[pachuco]

Maaaan, that branch merge at the end really twists my bollocks.
Checkout branch... checkout commit... where the fuck did bChannel go...

[leecher1337]

Ooops, did I do something wrong? I just pulled the branch (otherwise I wouldn't have been able to push the commit) and then issued the commit with the fix, seems it automatically created the merge by thoing this...?

[pachuco]

Dog knows what happened. But I am glad it's gone now.