vasile

48 minutes ago, Marco Tecno said:

Vasile, while you are at it, just a quick question: is the nx-on-wake install file still at its original 1.0 version? Only the readme files got updates, right? Thanks in advance.

Yes

48 minutes ago, MountneerMan said:

@vasile, May I ask what the next feature you think you are going to work on?

I started already (but will be away until Aug)- see here for details.

On 02/07/2016 at 8:58 AM, Parker said:

Vasile's new 'nx on wake' hack is marvelous... Camera behaves exactly the way it does without any hacks, super quick to turn on and off whenever, hacked bitrates are loaded instantaneously since we don't have to wait for Bluetooth to load like we used to (and still do with the KS mod). They've recently added some nice tweaks to the UI as well, give it a shot! 

:-) 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)...

On 02/07/2016 at 2:34 PM, SMGJohn said:

Thanks mate, I will try Vasile one the installation for NX Wake though scared me away for a second but if its speedy its all worth it

Better wait a bit, most likely a new version out tomorrow. 

this.

Thanks in advance.

41 minutes ago, vaga said:

@vasile how is the progress on integrating things into Samsung's menu itself?

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

this.

Run out of slots to enable.

Any NX500 beta testing volunteers please PM me.

41 minutes ago, classicam said:

Hi Vasile,

Thank you so much for the wonderful work! I've just installed your no-wakeup mod and 5.1 patch. It all work flowlessly! I have two question wish you can help me to understand: 

1. What is the stable highest bit rate for UHD 25p/30p and FHD 120p that you recommend? I'm using the lexar 2000x 64G card. 

2. Is that a way to make focus mode stay in Manual mode by default? (or with a possible futuremod) It's very annoying to have the mode swithed in auto by default when I'm using Samsung lens e.g the 30mm and 16mm lenses which don't have a MF switch:(  

Your input will be much appreciated!!

Thanks again!

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?

Did not have time to look into this since:

http://***URL removed***/forums/post/57641348

http://***URL removed***/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.

nx-patch v5.1

rgds

2 hours ago, vaga said:

How about long press of Ok?

long presses are not supported by Otto's keyscan...

How about double click on the button to illuminate top lcd?

46 minutes ago, Marco Tecno said:

I'm talking of the ks mod. There the ev+ok triggered the menu flawlessly.

well, EV+OK never worked for me on my NX1 although I am using the same keyscan fro Otto.

11 minutes ago, Marco Tecno said:

I really liked the ev + ok on nx1. Never gave problems.

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.

2 hours ago, Francesco Tasselli said:

..I don't know if the theme has been yet approached, so I put the question:

does the hacking compromise the Samsung warranty?

Your hacking work is fantastic and I'm very attracted by the possibilities it opens, but I'd like to deepen what happens with the official warranty..

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

35 minutes ago, cojocaru27 said:

@Vasile, i have dropped you a private message. If you can find some time to answer it would mean a lot to me. So looking forward for your advice. thanks a lot.

replied

3 hours ago, Pavel Mašek said:

As on dpreview forum - I would like to thank you very much....  It works great - as without hack - very fast, no delays, BUT with high bitrates... simply wonderful :-)

Any chance you could use different button combination than OK+OK for UI? eg. thash+thash (or even EV+EV as on NX500 could be better). Because when I have performed some changes in menu I have accidentally evoked UI because of fast pressing OK+OK... Setting bitrate for "Normal quality" would be also nice..., but these are small details. I really do not want to bother you with them ;-)  

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.

this :-). Have fun.

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

36 minutes ago, Otto K said:

No reason why it wouldn't, but I have no way to test it on NX1. 

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

23 hours ago, iamoui said:

No this is with one of Kinoseeds mod packs for 1.40 firmware. I didn't see any reason to upgrade to 1.41. I use an iPhone, and I love the bit rate hack!

edit: wait, what new hack for 1.41? Vasile's?

edit2: just read through the dpreview thread on vasile's new hack for 1.41 and saw that someone claimed to have true 120fps at 180mbps. Guess I'm going to have to test it tomorrow!

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.

9 minutes ago, lebigmac said:

Hey Vasile, raise your voice! Since someone claims that your work is not reliable, it is high time to make your point. We have a great amount of trust in you developers and we all will be happy if you discussed - and solved - your issues openly, the technical as the and the emotional ones.

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.

6 hours ago, kinoseed said:

Vasile, even tough apparently he obfuscated the bitrates and had to be "hacked" to be used with "poker" was given full credit.

Indeed. Since I chose to publish everything, from the beginning as GPL, it was in my best interest to obfuscate these values so no-one could understand them. After all, why publish as close source when I can achieve the same effect by GPL'ing my work and intentionally obfuscating it so to make it unreadable and unusable. Oh. Wait.

6 hours ago, kinoseed said:

When the new FW showed up, I gave him the new addresses, but the values were suspect, and after waiting a week for him to produce the new bitrates (as I suspected were different) he just said "they are the same" while apparently he's been working on his "mod". Well something didn't add up as the values from Samsung did not match Vasiles.

The bitrate values are the same. This is a complete lie - go check the bitrate values between the old and new firmware (in my code or in his) and judge for yourselves. @MountneerMan - your background might help - you can also confirm that the new bitrate calculation in my code is precisely the same as the one I incorporated in my Excel spreadsheet I published a long time ago.

In addition, the code that needs to be changed is bit by bit the same between the two firmware versions, and the changes therefore have to be the same to achieve the same result. Claiming the bit rate values are different between the two firmware versions is simply untrue.

I won't comment on the allegations as to the reason for the delay but my comments at the time are available on dpreview - you can all go read the facts. And BTW I have a life outside of this as I made clear from the beginning.

6 hours ago, kinoseed said:

 

So I redid his hack, and found he had miscalculated the values 4 bits out of 8 bytes, (which was not critical in the end, but gave different values) maybe it was not from his calculations, but error from his obfuscation - no idea, didn't really care to check his work that much.

My spreadsheet is available to all for checking. Enough said.

6 hours ago, kinoseed said:

But since he didn't contribute anything for the latest NX-KS mod, and only made sure his work can't be really used as opensource, was enough to let him go and do his own thing, although teaming with Otto was great.

This again calls for a bit of judgment: why would I release everything as open source if I did not want it used?. Please read this coming from @MountneerMan; it was feedback I did not request as the author will confirm.

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.

You might find this interesting.

Regards

Vasile