Quote:
Originally Posted by jonpry
RPC really isn't a problem anymore since we have a more or less complete implementation of oncrpc.dll and are able to load the native remoteapisvc.dll and remoteapiclient.dll. But after doing all of that, all it really did is verify that the reversed engineered RPC calls for sound were good enough.
wavedev.dll eventually makes a kernel io control that i believe returns the AMSS version to the drivers, but I don't know how this number is represented or what it should be. Perhaps that is making some part of the driver not work correctly, but it doesn't error.
There are also some strange calls to DEX, SPM, and KLM. In theory DEX an SPM are working, but I didn't verify it very well. There is some question as to what it is for. Maybe cycling power on the DSP?
I have no idea what KLM is. Captnoord said it is MicroP, but I couldn't find a dll that exports a KLM driver. Some massive amount of data is transfered to it, whatever it is. Maybe microcode? Maybe something on the i2c bus.
I don't know what GRP rail is. Audio doesn't crash A9. A9 seems to be happy with what we are doing, AUDPP starts up and says it is ready to play, but DSP never consumes the buffer.
|
Sending anything to 0x3000000F 0x2C is for grp rail. But not to worry about that since i verified its actually on. The only reason i mentioned it is because it would bomb out if i tried to enable it that way.
On wavedrv.dll, did you get this info through disassembly? Cotulla has been very cool in verifying some ASM for me. Maybe he can do the same as long as we provide him the dll.
There is some dood about to sell this tp2. Lets get it so you can jtag that beotch ..lol.