S95 Porting Thread - page 2 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 102   Go Down

S95 Porting Thread

  • 1015 Replies
  • 319693 Views
*

Offline waldo

  • ***
  • 238
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.
Logged
*

Offline reyalp

  • ******
  • 14036
Re: S95 Porting Thread
« Reply #11 on: 19 / September / 2010, 21:32:48 »
Quote from: waldo on 19 / September / 2010, 21:08:05
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.
Logged
Don't forget what the H stands for.
*

Offline waldo

  • ***
  • 238
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.
Logged
*

Offline Hollywood

  • **
  • 50
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.
Logged
*

Offline vasilip

  • *
  • 1
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
Logged
*

Offline waldo

  • ***
  • 238
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 !
Logged
*

Offline Fernando

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

Offline Hollywood

  • **
  • 50
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.
Logged
*

Offline m4mmon

  • *
  • 20
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.
Logged
*

Offline waldo

  • ***
  • 238
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?
Logged
Pages: 1 [2] 3 4 5 6 7 ... 102   Go Up
« previous next »
 

Related Topics