supplierdeeply

S95 Porting Thread

  • 1000 Replies
  • 149526 Views
*

Offline waldo

  • ***
  • 238
  • Publish
    Re: S95 Porting Thread
    « Reply #10 on: 19 / September / 2010, 21:08:05 »
    Advertisements
    You da man, reyalp!  That was what it needed to start up properly.

    I know you are working on loading executable binaries after CHDK is loaded.  Do you think it is feasible to have a separate and small CHDK loader which then loads a separate file that contains the bulk of the code?  I'm thinking this may reduce the time between pressing the power button and running startup code. and shorten the amount of time the power button needs to be held down to be recognized properly.

    *

    Offline reyalp

    • ******
    • 9866
  • Publish
    Re: S95 Porting Thread
    « Reply #11 on: 19 / September / 2010, 21:32:48 »
    I know you are working on loading executable binaries after CHDK is loaded.
    What I have been working rebooting with a different binary, which is different than loading a binary into an already running OS. That's more along the lines of the ELF project: http://chdk.setepontos.com/index.php/topic,847.0.html
    Quote
      Do you think it is feasible to have a separate and small CHDK loader which then loads a separate file that contains the bulk of the code?
    Yes. This something that I would like to do eventually, but it's a bit complicated. The right way to do it is again something like the ELF concept, with relocatable binaries. You could do it without, but I don't really see it as being worth the effort just to make the time you have to hold the button down less :)
    The other complication is having enough of the OS loaded to do file IO and memory management, while still having time to hook the tasks that you want to hook.

    Note that you could could grab the button state in the very start of loader, and store it where the 0x12345678 flag goes (you could restore the 0x12345678 value if needed after you've read your own value) I'm not sure how much this would help, I suspect the main delay is loading diskboot and and the canon copy and restart function.
    Don't forget what the H stands for.

    *

    Offline waldo

    • ***
    • 238
  • Publish
    Re: S95 Porting Thread
    « Reply #12 on: 23 / September / 2010, 10:58:00 »
    Here's something odd I just noticed.  The uBasic shoot function did not work on the S95.  I tracked this to the PROPCASE_SHOOTING always being 0, so I assumed that the property case address was wrong.  I searched through all the property cases and found what seems to be PROPCASE_SHOOTING located at 303.  I cannot find a reference to this address in the code or on the forum, so I guess they changed it on this camera.  Patching this address in my code makes the shoot function work. 

    If Canon is going to change these addresses more often, it seems like this is a camera-dependent thing that belongs in the Platform/camera directory, but the current code structure puts this information in trunk/include.  It seems a bit cumbersome to create a new propset each time anything changes for one particular camera.

  • Publish
    Re: S95 Porting Thread
    « Reply #13 on: 02 / October / 2010, 02:38:54 »
    Thanks to everyone who is working on the S95 port and so quickly too.  Guys like me really appreciate your work.  Cheers.


  • Publish
    Re: S95 Porting Thread
    « Reply #14 on: 07 / October / 2010, 08:09:37 »
    Hey!, Any chance the very alpha version you guys are working on currently supports triggering via usb (on release)? I thing this should be enough to sync two s95s like the stereodata maker branch does. Any progress so far :):)

    thanks, Vasili

    *

    Offline waldo

    • ***
    • 238
  • Publish
    Re: S95 Porting Thread
    « Reply #15 on: 07 / October / 2010, 10:26:11 »
    The scripting commands for shooting are not working yet - possibly due to not yet implementing the CaptSeq task.  But I'm on it !

  • Publish
    Re: S95 Porting Thread
    « Reply #16 on: 07 / October / 2010, 13:48:10 »
    Thanks for all your efforts on S95 port!

  • Publish
    Re: S95 Porting Thread
    « Reply #17 on: 07 / October / 2010, 18:27:43 »
    I second that thanks a bunch to all those trying to make this possible on the S95.


  • Publish
    Re: S95 Porting Thread
    « Reply #18 on: 08 / October / 2010, 14:45:56 »
    Just registered to thank you and tell you to keep up the good work.

    *

    Offline waldo

    • ***
    • 238
  • Publish
    Re: S95 Porting Thread
    « Reply #19 on: 09 / October / 2010, 16:45:59 »
    I'm having problems getting the screen to redraw properly on the S95.  When I call vid_bitmap_refresh(), the screen draws but does not erase properly.  It is like the screen is locked and prevented from further drawing even when not in ALT mode.

    vid_bitmap_refresh() calls ScreenLock and ScreenUnlock/RefreshPhysicalScreen.  The firmware for these functions looks different when compared to firmware of other cameras I have looked at, so I may have the addresses wrong for these functions.  My best guesses are:

    NHSTUB(ScreenLock, 0xFF8B7E50)
       or
    NHSTUB(ScreenLock, 0xFF8B81E8)

    and

    NHSTUB(ScreenUnlock, 0xFF8B6C8C)
    NHSTUB(RefreshPhysicalScreen, 0xFF8B6C8C)
       or
    NHSTUB(ScreenUnlock, 0xFF8B81C4)
    NHSTUB(RefreshPhysicalScreen, 0xFF8B81C4)

    I've tried all combinations of these with similar results each time.

    I can make the screen erase properly by replacing vid_bitmap_refresh() with:
        draw_filled_rect(0, 0, vid_get_bitmap_screen_width()-1, vid_get_bitmap_screen_height()-1, COLOR_TRANSPARENT);
    This erases OK, but does not always draw correctly.

    Can someone check me on these function addresses?

     

    Related Topics