Reply to thread

Message: <blockquote data-quote="RaStr" data-source="post: 10771">Of course I have tried modifying this first, before I even started playing with the DVICO drivers ! What's the most important for us now is the TunerI2CAddress, which is stored in the registry after the driver is installed. That's why the driver is so-called registry configured in the .inf header btw. But as far as I know it doesn't work ! The I2S mode is still serial and I2C address is C0 despite of the value in the .inf or the registry afterwards. Yesterday I have tried to even change the tunner model registry value to 0A (as this one has PLL on C2 addreess) just give it a try, but I was very surprised that nothing has changed in the I2C communication. I was too lazy to reinstall the driver (my spare PC which I have to use now is very slow just a reboot takes some 3 minutes!), I have just modded the registry and rebooted, so there are two possibilities:a) the driver is configured somewhere else than in the registry and I need to change the .inf and remove/reboot/install the driver/reboot with every change - but I have had no time for that yesterday b) the driver autodetects the tuner type and ignores the registry settings completely - this seems to be possible, as I remeber I have seen the mt352 ID register read on the I2C bus during the Windows boot, i.e. after the driver initialization !  If you will hexedit the zulutune.sys file you will see there are some data tables near the end of the file, so I expect the initialization data could be somewhere there, but I was unable to find it till now. For those who knows dissassembly of  C++ code better them me, I have uploaded the code here: <a href="http://www.althan.cz/A771/ZuluTune.asm" target="_blank">http://www.althan.cz/A771/ZuluTune.asm</a> . I have suddenly forgotten the list of initialisation data at home today, but I remember, that it starts: write to device 1Eh(mt352), address 89h(Clock_control) value 38h, then write device 1Eh, address 8Ah(CONFIG) value 38h. This is probbably implemented as a one command in the code as both writes are in the communication in the same order and only together ! If someone can find where this sequence is stored or programmed, we can trace the rest and modify it !I have checked the I2C communication with the original Avermedia driver, there are some differences, but nothing really critical - but I have had some problems with my I2C sniffer that time and not all data captured were reliable, so I will have to repeat it someday. Anyhow the main facts are that the mt352 must be configured for parallel output (the byte written to address 8Ah controls this) and the PLL address must be C2 (this has to be written to address 58h).  So if there are some good code crackers on this forum, please, take the lead, as I am a bit busy now, and cann't continue too much. Of course If we would get the source code from DVICO, it can be modified easily, but I don't believe that some of the other companies will ever release it, as even Connexant - the manufacturer of the chip doesn't want to ! And they have generic BDA driver SDK for that chip and I believe the DVICO's driver is based just on this SDK !</blockquote>

Verification