Message for Peops dev team!

Hello,
I implemented a WaveOut driver for Peops SPU.
I successfully made it working on Windows CE and I would like to release the modified/newly added sources.
Into some files I had to add an empty line, because the compiler signaled an error similar to "No blank line at end of file"; I ignore why it happens...
Here there is a listing about the modified files:

dsound.c:
- The variables "LastWrite" and "LastPlay" are now handled here.
- Added conditional compilation with macro _ENABLE_RECORDING

dsoundoss.h:
- Added blank line at the end.

externals.h:
- Added declaration of macro "_ENABLE_RECORDING" and "_ENABLE_DEBUGGER" if they aren't defined elsewhere.

record.c:
- I just made some variables as private with "static" keyword.

record.h:
- Added blank line at the end.

regs.h:
- Added blank line at the end.

reverb.h:
- Added blank line at the end.

spu.c:
- Added different description when the WaveOut driver is selected.
- Quick fix for handling waveout streaming.
- Conditional compilation of recorder and debugger stuff according to macro "_ENABLE_RECORDING" and "_ENABLE_DEBUGGER".

winmm.c:
- New file, the WaveOut driver. If it's used instead the DirectSound Driver, the _USE_WIMM macro must be defined.

As you will be able to see by reading the source, it's just a quick but working implementation.
Unlike the other drivers, the sound data is decoded directly into the playing buffer.
For this reason I did a fix after calling the SoundFeedStreamData() function.
It would also be nice to remove the malloc() to pSpuBuffer (I could also remove the saveSpuBuffer member from WINMM.C), but I didn't touch it, I was not sure if it was used in other parts of the source codes.

And surprise, it seems to run a bit faster on my PC with WaveOut instead of DirectSound.
But I don't know nothing sure, nor I did some specific tests on performances, since I just saw an higher frame rate...

BTW, do you remember the fix you did with option "IRQ handling in the decoded sound buffer areas"?
Well, besides "Crash Team Racing" there is another game that needs this option.
It's "Unjammer Lammy 2".
ePSXe, PCSX, and FPSE (with my simple sound mixer) loop forever after starting a game.
But with your plugin, the games runs!
Both FPSE and PCSX run it; unfortunately ePSXe still loops, but probably I didn't simply understand how I could disable his internal hack.

I hope this may be useful.

Sincerely,

LDChen.

Hello,
I also have a problem with PSEMU GPU plugins.
The new version of my emulator accepts both FPSE and PSEMU plugins without differences, but I have a problem with PSX internal timings.
The fact is that I need to know the number of 32 bit words processed by function GPUdmaChain().
Since you already have a variable called "DMACommandCounter" into that function, I was wondering if it could be used for counting the amount of memory transfered by GPU and if his value could be made public with a new function.
Afterall, it seems to me that this variable is only used for detecting a loop condition: so, counting the doublewords or the gpu commands shouldn't make a big difference.
Or if you have a better idea, it's ok anyways for me.
At the moment I resolved the trouble in my emulator with a special option:
state=0 : no fix, I assume that the GPUdmaChain() completes immediately.
state=1 : no fix, I assume that the GPUdmaChain() transfers a small amount of data (256 bytes by default).
state=2 : the dma buffer is parsed manually with a function before calling the GPUdmaChain(). It doesn't look very nice, but it seems to work.
state=3 : unimplemented, it gets the number of transfers from GPU plugin.

If the feature is available into the current plugin, I was thinking to force the "state=3".
Otherwise, the user is responsible to select how the state must be handled (afterall, it's the user that decided to run emulation with that plugin!).
What do you think?

Sincerely,

LDChen.