S95 Porting Thread

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.

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.

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.

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

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:

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.