There are still 5 stubs values that need to be found:
NSTUB( 0xFF020760, GUI_CONTROL
NSTUB( 0xFF31CFCC, ChangeColorPalette
NSTUB( 0xFF2CFA54, MirrorDisplay )
NSTUB( 0xFF2CFAB4, NormalDisplay )
NSTUB( 0xFF2CE1F0, redraw_maybe )
that's from the 550d's stubs file, so I'm going to try to find those now. After that we need to confirm that all of the properties and constants are correct, before proceeding any further.
Just wondering if you managed to find these Coutts?
I think if these were found it would be more stable.
PS Dont turn on the Digtal Filters
I talked to alex, mirror display and normal display were part of the april fools joke so no need to worry about those. i found changecolorpalette pretty easily, i don't think it's being used right now so that won't change stability at all.
redraw_maybe tells the camera to redraw all of it's canon gui elements, and gui_control is some event I think. I couldn't find either of these 2...
I'm trying to tackle ALO/HTP right now. i'll give everyone a rundown on how custom functions in ML work:
custom functions are grouped into 4 groups (you can see this grouping from your custom function menu). the custom functions property has 4 buf's in the code. it's an array, it does something like this:
cfn[1] = buf[1];
cfn[2] = buf[2];
cfn[3] = buf[3] & 0xFF;
i don't know what that 0xFF thing does, but anyways.. there's a print statement commented out that's used for testing purposes, it prints the value of each "cfn group". each cfn "group" has a value of all the custom functions in it. EX: in the 500d, group 2 (cfn[1])'s value when everything in group 2 is turned off except for HTP being on, it's value is 10000. when you turn ALo from std (default value, 0) to low, the value of cfn[1] becomes 1010000 (add 1000000).
well MLU works fine, because everything in that group (cfn[2]) is either 100, 10, etc. so alex (or whoever wrote this function, [admin: avoid swearing please] genius) uses bitwise operations. so setting MLU on:
void set_mlu(int enable)
{
if (enable) cfn[2] |= 0x100;
else cfn[2] &= ~0x100;
prop_request_change(PROP_CFN, cfn, 0xE);
}says, if you pass a 1 to set_mlu, then the variable enable has a value, so:
if enable has a value, set cfn[2] to the result of a bitwise or operation of 0x100.
else, set cfn[2] to the result of a bitwise and operation with the inverse of 0x100
request prop change for prop_cfn..blah blah.
so a bitwise or operation:
this takes the value of 2 binary values and compares, if either bits are 1, then the result is 1, otherwise it's zero. example: turn MLU on, the original value of cfn[2] is 0. so the operation looks like this:
000 <-- old value
100 <-- new value
----
100 <-- result
then turning it off, a bitwise and operation takes each pair of bits and compares them, if they both are 1 then the result is 1, otherwise it's zero. well remember that tilde says to invert the bits of that 0x100. so turning MLU off it looks like:
100 <-- old value
011 <-- inverted 100
----
000 <-- result - MLU is turned off
so this works fine and dandy when you're only dealing with 1 and 0s, like the MLU function where MLU is 100 and the other custom functions in that group are 1000 or 10000, etc.
SO THE PROBLEM WITH ALO IS, alo doesn't just use 1s and 0s, it uses 2s and 3s:
cfn[1] values:
ALO standard (default value) - 0
ALO low - 1000000
ALO high - 2000000
ALO off - 3000000
so we can't use these ingenious bitwise operations.. so the only solution i've come up with is include every custom function in group 2 in the ML menu, and just say from now on you adjust those from the ML menu (changing the custom function menu won't work right), and a huge if statement to cover every possible setting combination of htp/alo/high iso noise reduction/long exp noise reduction will have to be used to handle this. idk though, it's gonna be a HUGE if statement and probably going to slow ML down, as it'll always be checking this if statement in the shoot_task's while statement that runs as long as the camera is running.
so this is what I spent all day yesterday working on and figuring out. It took me literally all day to understand how the bitwise operations and stuff work. this is where I'm stuck now. We need a better way to handle this. in the 550d, Alex found the property location for ALO, to avoid this mess of the 2s and 3s and not being able to use simple bitwise operations. well, i tried finding the ALO functions in the 500d dump yesterday,
NO LUCK.. so frustrating. prop_spy isn't working either for some reason, I think we need to verify our debug.c code with the 5d and 550d to make sure our prop_spy code isn't different.
we need to verify our properties are correct.. but without prop spy idk what to do.
