Jump to content

vasile

Members
  • Content Count

    95
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by vasile

  1. I started already (but will be away until Aug)- see here for details.
  2. :-) well, it does exactly what it says on the tin, nothing less, nothing more :-). And yes, this is my objective: make it seamless as much as possible because bluetooth becomes real tedious real quick (well, that's actually a lie, actually my main real purpose is to get my 16-50S but not there yet)...
  3. nx-patch v5.3 is out. One point of interest to videographers: killall switch added which basically returns camera to factory settings (until battery pull) EXCEPT for the already set bitrates. Pull battery to reactivate mod UI.
  4. Better wait a bit, most likely a new version out tomorrow.
  5. I am now doing groundwork for mods that will be a lot more advanced. This is why you are likely to not see any visible progress for a while. In essence I am trying to zombify the di-camera-app to enable bi-directional communications between it and my mod infrastructure, and to introduce the possibility to "drive" it from the mod runtime.. If successful this should allow many things, potentially including native UI integration, true BBAF, native integration of focus stack & focus pull, etc. etc. My plan is to make it an extensible and open framework upon which others might build on (e.g. Otto) to deliver things that work in coordinated manner with the native app, and that are aware of what the native app does. This will allow, for example, to have the UI permanently up to date regardless of what the mod does (as opposed to today where mods do not update the UI because they are independent of di-camera-app). NB. Nothing above is a promise or commitment and you do not see any timeline, do you? PS. I still covet that lens ;-)
  6. Short answer: no progress. This will take a long time and I am trying to do things with a lot more impact first. You should check this from time to time - I keep it up to date, and you will save some time by just checking it. rgds
  7. this. Run out of slots to enable. Any NX500 beta testing volunteers please PM me.
  8. 1. no idea, you should experiment with your card 2. this will require deep interference with di-camera-app. Basically I would need to zombify di-camera-app and make it play my tune. Possible and I am working towards that because I would like to achieve a better BBAF which requires the same type of interference. But definitely not short term and may not even be achievable. NB. This is not a promise and you did not see any time frame above, did you?
  9. Did not have time to look into this since: http://www.dpreview.com/forums/post/57641348 http://www.dpreview.com/forums/post/57635337 But there's no way I can see to influence this from di-camera-app or any Tizen-land application. From the looks of it it is managed inside the T-Kernel. And this I don't even know where to start on.
  10. long presses are not supported by Otto's keyscan... How about double click on the button to illuminate top lcd?
  11. well, EV+OK never worked for me on my NX1 although I am using the same keyscan fro Otto.
  12. I do not know - on my camera EV always generates double events and it is impossible to combine it with OK :-( I could change it in the release but it would be untested by me - or I could put in a disclaimer that it does not work for me.
  13. I guess it depends on whom you ask. To me the hack only overcomes artificial marketing-imposed limits. In any case I bricked my burner NX500 (oh, my personal one too - but that one is still awaiting repair) and Samsung repaired it without a peep under warranty. Now I do not TRULY know if it was me - the motherboard was replaced and to my knowledge nothing I was doing could have caused a hardware failure - but in any case they fixed it under warranty. YMMV. rgds
  14. There's a reason I did not use EV EV - does not trigger correctly on NX1. Ideally the key combination to trigger the UI should not trigger anything on the camera AND be easy to use/remember. Trash activates video mode and I'd rather not use that key. EV would be ideal but as I said even single clicks on EV generate "doubles" - at least on my NX1. I am open to ideas otherwise.
  15. Ok this is going to be fun. BTW in case you wonder why I have time and state of mind to write this long post, see here :-(. So all you have so far is two contradicting claims coming from me and KS, and you cannot be sure which of us is right. Let us rectify that. I attach the spreadsheet I used to calculate the bitrate values - you will need to keep it open in Excel because otherwise you will not be able to properly follow the rest of my post. NB. you will need Excel 2013 or later because it uses some Excel functions that were unavailable before Excel 2013. I also attach a print screen for those of you who would rather not download it and instead look at a picture :-), or do not have Excel 2013. Unfortunately the machine I am writing this from does not have Excel 2013 either so I cannot plug in the 40Mbit value - but you will see that the spreadsheet calculation gives the exact value I used and KS quoted - see cell E48 (If you want, tonight I will post an updated picture). BTW if you have not heard of hexadecimal (base 16) numbering which is used in computing because it is easier :-) just remember that instead of numbers containing 0-9 you will see in the spreadsheet many numbers using 0-9 and A-F (coz base 16). If you are unfamiliar with this, do not be discouraged - I will not ask you to make any calculations. So, if you are ready to invest 10 minutes in understanding where do the rates come from, here we go: When I looked into the newly broken-in NX500 it was obvious that the di-camera-app was the program to look into - the name makes it so. So my initial objective was to see where the bitrates are set - well, to cut a long story short, I identified the place in a certain function call, and I saw that the bitrates were loaded into a CPU register via a couple of ARM instructions (different for each bitrate slot). These instructions are called mov.w and movt. The end result of running them one after the other is that a 32-bit value is loaded into a target CPU register. For the bitrates, the target register needs to be R3 (except for nx500 pro bitrates which need to be put in R0 - note that KS did not say what is the cause of this exception). Now we go in really deep. Basically we need to re-encode these instructions such that instead of loading into R3 whatever bit rates Samsung marketing decided, they should load whatever __I__ wanted. From now on I will start each paragraph with the cell you need to look at. Cell D9 - So let us pick the target value - in this case 85Mbps. Cell D10 - to keep things easy let us convert it in a 32-bit hexadecimal Cell D11 - let us not forget the target register (for nx500 pro bitrates we would change this to r0) Cell H5 After thoroughly reading the relevant section of the ARMv7 reference manual, I built the tables H5-AM9 and B13-AM23. Let us discuss then a bit. The two ARM instructions I am trying to assemble are each 4 bytes = 32 bits. Since this is little-endian ARM, the values are stored in memory as shown in table H5-AM9. that is, a bit scrambled :-). If you read the ARM reference manual, you will see that these two instructions are very similar, the only difference is that one loads a 16-bit value in the lower half of the target register (mow.w) and the other of into the upper half of the target register (movt). They are encoded with some fixed bits (background white in the tables) and some variable bits which contain the 16 bits that make up the value to be uploaded into the register (yellow background). So now all we have to do is split the 32 bits of the target value into two sets of 16 bits, and spread these 16 bits into the dedicated yellow spaces reserved for them. Cell B13 Let us start with mov.w (cell B13). The mov.w neds to contain the lower 16 bits of the target value - see cells E14 and E15. These 16 bits I then manually (ok through formulae) sprinkle into the proper yellow places in the encoded ARM instruction. I then do the same for the movt instruction. The upper 16 bits from the target bitrate I "sprinkle" into the necessary places within the encoded instruction - see cells B19-AM23. So now we have the ARM instructions codes, exactly how they look if we dump the memory: see cells AB16 and AB22. BUT, since I am going to use gdb to patch the memory, they are inconvenient, because gdb would require four set statements if I tried to patch byte by byte the memory. So what I decided was to make out of these 4 bytes an integer (which can be patched with one gdb set statement). How to do it? Well, because ARM is little-endian, I needed to reverse the memory byte order to arrive to an integer that gdb will use for patching. Hence cells AB17 and AB23 - notice that the bytes are in reverse order compared to what you see in the memory. This is because gdb, when putting an integer into memory, will know ARM stores them in reverse order and therefore will do the same. The net result is that we end up with the proper value in the memory. Finally, again to make my gdb task easier, I decided to concatenate these two ARM instructions together so I do not mismatch them and because they are easily split again in gdb. I did that in cell AD25. So now all we need is to add the surrounding text to make it simply a copy/paste in the gdb script and thus avoid re-typing errors. This I did in cell Q27. But this calculates only ONE bitrate value, and I am lazy so how can I force Excel to calculate all of them without me having to replace each value in cell D9? Well, Microsoft was kind enough to provide for array operations (I think they are called so) and I took advantage by telling Excel to basically replace D9, successively, with the values I wanted, and store the result in a table. You will find the table in cells D46 to G82. From there I simply copied the result into the gdb script I publicly released. Now if you have gdb, go to the memory addresses that change the bitrates and compare my spreadsheet results with the original SAMSUNG values, you will see that they match perfectly: the instructions generated by my spreadsheet are CORRECT - every instance of original Samsung bitrate set instructions, read from memory, matches the corresponding value calculated by my spreadsheet. This proves that the elaborate construction I put together in this spreadsheet is correct. Finally, for those who open the file, there's a second section of the worksheet that I did not discuss, and which is basically the development of the algorithm used by my current nx-patch and which calculates on the fly the bitrate allowing you to set it to whatever value you want. This development I integrated ad-literam in my nx-patch - see bitRateOpCodes function in nx-patch.cpp. NB. This is a very very short explanation of my thought process how I went from zero ARM assembly knowledge to encoding these instructions, by using the ARM reference manual. I hope this post will clear any lingering doubts about the correctness of my calculations. NX wip v18.xlsx
  16. They should apply to NX1 but involve EXTREMELY dangerous changes. DO NOT attempt to do them on your own unless you know what you are doing - a mistake WILL require you to send the camera for service. Why? Because you change a library that is required by di-camera-app. For 2.5K you also change the di-camera-app itself. A mistake and di-camera-app will crash leaving you without user interface. So just don't. Wait a bit please
  17. You may want to wait some more unless you want to test again later on. After I get back the burner camera from repairs I will try to put together an even smaller mod, which should have less resource consumption (read: memory) than what I have out now. And I also intend to break the bluetooth dependency but this is not news. In general you should keep an eye on work in progress and on work finished or abandoned. The best place for requests is (AFAIAC) to add to this on github.
  18. Not going to defend my own work (beyond what I wrote above) since I will be accused I am partial to it and that I would twist things to defend it. Please look it over yourself on github and make your own opinion. And/or ask someone else to do it for you or help you do it. I will let my work posted on github advocate my position.
  19. There a lot of public comments on dpreview from KS that are offensive to me - I chose not to respond to them because I am a long time member of that forum and do not want to start a flame war there which would endanger my membership. I read them at the beginning but not for a good while. Now I see this here. Well, I've had it. Having said that, @Andrew Reid, I apologize for disturbing the peace on your property and promise to not do it again. I am just asking you to try to understand and overlook this one-time digression. Thanks and kind regards.
  20. You might find this interesting. Regards Vasile
×
×
  • Create New...