Eos 400d ( Rebel XTI )

  • 1862 Replies
  • 391258 Views
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1590 on: 03 / May / 2012, 04:37:11 »
    Advertisements
    In our "gui.c" we intercept the GUI_IDLEHandler routine, to detect when the main dialog has been updated (event GUI_START_OLC_MODE), and change some of the info displayed (like the spot metering icon, for example). I have played very little with that code, but looks like a nice starting point to look for events to block.

    *

    Offline a1ex

    • *****
    • 659
    • ML dev
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1591 on: 03 / May / 2012, 08:00:23 »
    I have played a bit with IDLEHandler events, but wasn't able to handle them without causing stability problems.

    I'm even thinking to move all menu button handlers into gui_main_task (instead of dialog API).

    *

    Offline 0xAF

    • ***
    • 219
      • 0xAF
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1592 on: 03 / May / 2012, 09:56:27 »
    Great job, 0xAF! I guess you can draw anything on the screen now. New dialogs, help windows... Do you know if default GUI updates screen so often or there is no problem with it?

    Basically this means, we can now draw whatever we want, just like in ML, and the basic idea was to use a ML style of menus/dialogs, as the canon's (which we use now) are not good enough for our needs.

    In the video you can see the normal start of the camera and after few seconds i paint the whole VRAM in yellow, then "Hello World!" is written. As you can see a part of the screen is being redrawn by gui task, thought it's not everytime and not so often, but in this video it's visible.
    Then i do nothing, i wait for a regular event which redraws the screen, so you can see how much time it takes before a regular redraw happens... of course if you press a button or force some screen change, the redraw will happen sooner.

    I already knew that ML has a way to block redraws, and i was thinking to block the GUI task (atleas the redraw event).
    As Alex explained, we will probably look for the ML's way of blocking the redraws.
    // AF

    *

    Offline 0xAF

    • ***
    • 219
      • 0xAF
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1593 on: 03 / May / 2012, 10:01:09 »
    In our "gui.c" we intercept the GUI_IDLEHandler routine, to detect when the main dialog has been updated (event GUI_START_OLC_MODE), and change some of the info displayed (like the spot metering icon, for example). I have played very little with that code, but looks like a nice starting point to look for events to block.

    Yes, I was thinking the same ... gui task is a good candidate.
    Probably we should do the handlers in one task too (if it's possible), this would be more clean to maintain i guess...

    I have played a bit with IDLEHandler events, but wasn't able to handle them without causing stability problems.
    I'm even thinking to move all menu button handlers into gui_main_task (instead of dialog API).
    Alex, have you investigated if you can catch everything you need in the GUI task?
    I was thinking for the MainCtrl task, but i'm not sure we can catch every button press there...

    // AF


    *

    Offline a1ex

    • *****
    • 659
    • ML dev
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1594 on: 03 / May / 2012, 10:08:47 »
    There are some buttons which can't be seen from gui_main_task (like scrollwheels in main photo mode). But at least what works, works well.

    MainCtrl task looks pretty low level, and doesn't seem to handle more buttons.

  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1595 on: 04 / May / 2012, 15:11:07 »
    Currently I use the JUMP button in shooting mode for AEB. Is there a reason why we can't have finer steps for each button press, like we can when setting AEB through the camera menu (e.g. +/-1/3 EV)?

    Flash AEB would be another useful option for the buttons. I have a few presets that I use with flash (if necessary).

    *

    Offline Sergei

    • ***
    • 114
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1596 on: 04 / May / 2012, 15:49:01 »
      Speaking of buttons, I found two buttons: jump in *(int*)(0xC0220134)  and trash in *(int*)(0xC0220130). When button is pressed value of an address will be 0x20 and  0x21 when button isn't pressed. Good for exiting a loop in a script.
    Or can be used to prevent loading of autoexec.bin at startup.
      if(*(int*)(0xC0220130)==0x20)InitializeIntercom(); //if trash button pressed at startup load default IntercomHandler.
      else  my_InitializeIntercom();


    Probably best place is in my_romStart:
    Code: [Select]
    void my_romStart(int startType)
    {
      unknown_cache(&cache_0xFFB602F0, &addr_0x1900, 0xC6B0>>2);
      if(*(int*)(0xC0220130)!=0x20)my_usrInit(startType); // if trash botton is not pressed.
      else usrInit(startType);
    }
    « Last Edit: 04 / May / 2012, 16:02:17 by Sergei »

  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1597 on: 04 / May / 2012, 16:11:35 »
    Currently I use the JUMP button in shooting mode for AEB. Is there a reason why we can't have finer steps for each button press, like we can when setting AEB through the camera menu (e.g. +/-1/3 EV)?

    Flash AEB would be another useful option for the buttons. I have a few presets that I use with flash (if necessary).

    I do not see any reason why these two features could not be implemented.
    Please, open a couple of "feature requests" here, and we'll have a look at them later; thanks!


  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1598 on: 04 / May / 2012, 16:12:42 »
      Speaking of buttons, I found two buttons: jump in *(int*)(0xC0220134)  and trash in *(int*)(0xC0220130). When button is pressed value of an address will be 0x20 and  0x21 when button isn't pressed. Good for exiting a loop in a script.
    Or can be used to prevent loading of autoexec.bin at startup.
      if(*(int*)(0xC0220130)==0x20)InitializeIntercom(); //if trash button pressed at startup load default IntercomHandler.
      else  my_InitializeIntercom();


    Probably best place is in my_romStart:
    Code: [Select]
    void my_romStart(int startType)
    {
      unknown_cache(&cache_0xFFB602F0, &addr_0x1900, 0xC6B0>>2);
      if(*(int*)(0xC0220130)!=0x20)my_usrInit(startType); // if trash botton is not pressed.
      else usrInit(startType);
    }

    Another great finding, Sergei! And many thanks for sharing!

    *

    Offline 0xAF

    • ***
    • 219
      • 0xAF
  • Publish
    Re: Eos 400d ( Rebel XTI )
    « Reply #1599 on: 04 / May / 2012, 16:33:05 »
      Speaking of buttons, I found two buttons: jump in *(int*)(0xC0220134)  and trash in *(int*)(0xC0220130). When button is pressed value of an address will be 0x20 and  0x21 when button isn't pressed. Good for exiting a loop in a script.
    Or can be used to prevent loading of autoexec.bin at startup.
      if(*(int*)(0xC0220130)==0x20)InitializeIntercom(); //if trash button pressed at startup load default IntercomHandler.
      else  my_InitializeIntercom();


    Probably best place is in my_romStart:
    Code: [Select]
    void my_romStart(int startType)
    {
      unknown_cache(&cache_0xFFB602F0, &addr_0x1900, 0xC6B0>>2);
      if(*(int*)(0xC0220130)!=0x20)my_usrInit(startType); // if trash botton is not pressed.
      else usrInit(startType);
    }


    GREAT,
    i was looking for mem address of any button fo so long time.
    since i've ported the bmp stuff now, i was going to make the memspy work with realtime displaying, so i can find btn addresses.
    it seems you already found a way to catch them, thanks for sharing ;)

    preventing the loading of the hack is why i wanted it...

    EDIT:
    http://code.google.com/p/400plus/source/detail?r=1344
    Thanks Sergei !

    EDIT2:
    Sergei, just saw the canon's service manual and it seems only these 2 buttons are connected to the digic processor, so i guess you wont find the other button addresses unless they are mmap'ed from the MPU (which i doubt). Just to let you know, if you're trying to find the other buttons.
    « Last Edit: 04 / May / 2012, 17:50:44 by 0xAF »
    // AF

     

    Related Topics