Another small update for G12 & SX30 (patched against changeset 1067).- updates for exmem memory allocation to allow these cameras to exclude video buffer memory- fixed set_zoom function to correctly wait until zoom is finished before returning- fixed startup code for SX30 so that init_file_modules_task gets called correctly in all cases- changed startup code for SX30 so that short on/off button press starts in record mode and long press starts in review mode (previously was the other way around).

Another small update for G12 & SX30 (patched against changeset 1067).- updates for exmem memory allocation to allow these cameras to exclude video buffer memory- fixed set_zoom function to correctly wait until zoom is finished before returning- fixed startup code for SX30 so that init_file_modules_task gets called correctly in all cases- changed startup code for SX30 so that short on/off button press starts in record mode and long press starts in review mode (previously was the other way around).

I'm hesitant to add the startup change because- It's inconsistent with all other cameras.- Unexpectedly opening the lens is less friendly that unexpectedly not entering REC mode.

I'm open to being convinced otherwise. Ideally this should be a user option, but it happens before we can read the CFG file.

Possible solutions:1) We now have the ability to switch modes from normal CHDK code. This didn't exist when the "long press to start in rec mode" feature was initially added.

We could check a cfg value in main startup, and switch to the desired mode. We could still capture the button state as early as possible to detect a long / short press. This would probably result in slightly longer startup times, since the camera would start fully in play and then switch to REC.

As an aside, it should be possible to capture the switch state earlier, before copy_and_restart and stash the value somewhere (data TCM ?). This should reduce the length of the required press slightly, not clear if it is worthwhile.

2) Make it a compile time option.

3) store the value somewhere else. This would have to be- a specific disk sector- in the CHDK image itself (requiring proper encoding when updating)- in camera flashNone of these are very attractive.

I'm hesitant to add the startup change because- It's inconsistent with all other cameras.- Unexpectedly opening the lens is less friendly that unexpectedly not entering REC mode.

Thanks reyalp,

I change the SX30 because that's the way the G12 was working so I thought I had the SX30 wrong.Attached is a patch to make the G12 work consistently with the standard (long press of on/off to start in record mode, otherwise start in playback mode).

Ideally it would be good to use the value the camera determined during the pre-CHDK startup; but this gets overwritten by the load of diskboot.bin.

One idea I've been thinking about is to not embed the CHDK code into diskboot.bin; but instead load it from another file on the SD card (in the diskboot.bin code).This might speed up the boot process since the CHDK code would not need to be decoded/decrypted and the memory copy could be avoided (by loading the file directly to the correct location).If the resulting diskboot.bin is small enough it would also mean that the original startup state value would not get trashed.

One idea I've been thinking about is to not embed the CHDK code into diskboot.bin; but instead load it from another file on the SD card (in the diskboot.bin code).

This could be a good thing in many ways. However, the fact that you don't have the normal filesystem functions available will make it difficult. Even loading a small diskboot trashes enough of the OS that you really don't want to rely on anything working. Maybe you can boot enough of the canon OS the first time around, but the hooked tasks might give you trouble.

There are enough filesystem functions in the romstarter to load a diskboot, but these will only work with fat16. This might still be OK with multipartition setups, as long as they have the same behavior as the regular OS code with the "first" partition. May be worth investigating.

This is definitely something I've thought about. On the other hand, some kind of generic loadable binary support (like the currently stalled elf project) might be a better use of the effort. The "bootloader" might be a bit bigger, but the other benefits would be large.

Quote

If the resulting diskboot.bin is small enough it would also mean that the original startup state value would not get trashed.

Possible. Be aware that many cameras fail to boot an extremely small diskboot.