ELPH300HS aka IXUS220HS - Porting Thread - page 71 - DryOS Development - CHDK Forum

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 399470 Views
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #700 on: 07 / March / 2012, 17:24:07 »
Advertisements
The code required for setting the "nrflag" was not present, no wonder it didn't work. Here's the next try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB


So close yet so far.   OK, first the good news - I got some long shots without DFS.  Bad news - I can only get 3 with the intervalometer before it reverts to DFS.  From then on all shots >1sec have DFS until I reboot and reload script.  If I start fresh after loading CHDK, I can take a single shot without <alt> turned on and will have no DFS but everything after that will have it on.  In the old days I would guessed that......oh nevermind.  Punched IBM cards can't fit in the camera anyway   :P

Tried every combo of mode (Program mode was consistant) and changes in the CHDK menu to save or not save parms but that made no difference.  So whatever code you added also adds functionality to turn off DFS but only for 1 shot (not under a script) or 3 shots (running intervalometer).  Because I have it running on a A560 I feel the issue is not the setup unless the two bodies need DIFFERENT setup parms.

At least its close enough I can see light at the end and am in no hurry to buy some other camera where its already working.  Sure wish I understood the internals well enough to debug this.....sigh.  Lost my techie card long ago. Thank you for getting it almost there.  One more push maybe.

*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #701 on: 07 / March / 2012, 23:11:32 »
- I can only get 3 with the intervalometer before it reverts to DFS.  From then on all shots >1sec have DFS until I reboot and reload script.  If I start fresh after loading CHDK, I can take a single shot without <alt> turned on and will have no DFS but everything after that will have it on.
Do (some of the) other overrides also work like that, or is it just the dark frame setting?
Anyway, I've relocated the dark frame override call, here's the third try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #702 on: 08 / March / 2012, 00:03:26 »
Do (some of the) other overrides also work like that, or is it just the dark frame setting?
Anyway, I've relocated the dark frame override call, here's the third try: CHDK-ixus220_elph300hs-101g-1.0.0.zip - 0.20MB

Hey!  Thanks for jumping in so fast again.  No, the other overrides all are stable although its been trial and error on some to nail the values....for example ISO i have set at "1" with a "100" factor but often get 160.  A "2" gives me "320" in the EXIF.  I have no complaints there as its consistant and just needs to be remembered.  Anyway, will try your latest and repost in 15min.  As always, many thanks.

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #703 on: 08 / March / 2012, 00:36:22 »
Report on DFS function -

The news just keeps getting better.  Now, if I go straight to Program mode and run the Interval.lua with a 20sec exposure I just ran it 20x twice without a twitch.  Wonderful work SRSA_4c (if I may be so formal with your name).  Noticed 2 things out of the ordinary: first, any exposure greater than 15" still shows up in the display and EXIF as 15".  Not sure yet if that has any side affects.  Also if i shoot with <alt> turned off (need a better term for this) then I still get one shot without DFS before it kicks in again.  It then also hoses the script with <alt> back on such that I got (this is weird) a single DFS delay on the 16th frame of 20, then the script hung on frame 20.  I guess something else could have given the BUSY sign thats when i moved shutter from 4sec to 20sec to make sure it wasnt just a full buffer or something.  So anyway, the most important function for me is to shoot long shots with the intervalometer and YOU DID IT!

Wish i was still involved enough to understand the binaries you keep posting and how to do the programming but guess I will be lucky to make a few script mods that dont smoke the camera.

Many thanks for resolving the only thing in the world keeping me from shooting 24mm wide star trails instead of 35mm not so wides. 


Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #704 on: 08 / March / 2012, 02:38:35 »
Just ONE more item that jumped w/r to DFS;

Flash must be turned off or DFS runs regardless of settings.  This is important when using low output flash to light some foreground (statue, trees) when making a timelapse video or star trails. 

Hey, can I help any dev out by running some scripted (formal) testing?

*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #705 on: 08 / March / 2012, 11:59:41 »
Good to hear it mostly works. But since the behaviour of this override is so inconsistent, it's not good enough for official inclusion into CHDK. Hopefully some developer (who actually has access to this camera) turns up, and completes this feature. I only started implementing this because it seemed simple :-)

Quote
Also if i shoot with <alt> turned off (need a better term for this) then I still get one shot without DFS before it kicks in again.
Have you tried to change the dark frame override (to something else) after this happened? (I mean like: set it back to auto -> take a picture -> set nr off -> take a picture). Pretty weird behaviour btw.

The lockup of the script is probably caused by the use of the shoot() command. This command checks for certain conditions before it takes a shot. When some of these is not fullfilled, it just waits...

The keypress-based shooting sequence used in shoot.lua (also part of the standard CHDK package) may help.

Quote
Wish i was still involved enough to understand the binaries you keep posting
I publish my changes to document what I did (and to give a clue to the next person who will look into this).

Quote
Flash must be turned off or DFS runs regardless of settings.
My guess is that the camera's decision about this subtraction is a bit more complicated. What happens when you disable flash and enable the CHDK forced flash override?

Quote
any exposure greater than 15" still shows up in the display and EXIF as 15"
CHDK doesn't (yet) affect the Exif data, so that's normal (the firmware doesn't expect longer exposures).

Quote
for example ISO i have set at "1" with a "100" factor but often get 160
http://chdk.wikia.com/wiki/CHDK_User_Manual#Override_ISO_value

One more thing: does the lockup with interval.lua only happen when you pause the running script (by exiting ALT mode), take pictures by hand, and try to resume by entering ALT mode again? If so, does it happen with the official release?

The third try was made with these changes:
Code: [Select]
Index: platform/ixus220_elph300hs/sub/101g/capt_seq.c
===================================================================
--- platform/ixus220_elph300hs/sub/101g/capt_seq.c (revision 1715)
+++ platform/ixus220_elph300hs/sub/101g/capt_seq.c (working copy)
@@ -2,7 +2,7 @@
 #include "platform.h"
 #include "core.h"
 
-static long *nrflag = (long*)(0x7514+0x8);  // FF18775C & FF1877C8
+static long *nrflag = (long*)(0x7200+0x08);
 #define NR_AUTO (0) // have to explictly reset value back to 0 to enable auto
 #define PAUSE_FOR_FILE_COUNTER 100          // Enable delay in capt_seq_hook_raw_here to ensure file counter is updated
 
@@ -104,7 +104,7 @@
 " LDR R8, [R0,#0xC] \n"
 "       MOV     R0, R8 \n"
 
-"       BL      sub_FF98B018 \n"
+"       BL      sub_FF98B018_my \n" // ->
 
 "       BL      capt_seq_hook_raw_here\n"           // added
 
@@ -333,6 +333,116 @@
  );
 }
 
+
+
+void __attribute__((naked,noinline)) sub_FF98B018_my(  ) {
+asm volatile (
+      "    STMFD   SP!, {R3-R7,LR}\n"
+      "    LDR     R5, =0x3D48C\n"
+      "    MOV     R4, R0\n"
+      "    LDR     R0, [R5, #0x28]\n"
+      "    LDR     R7, =0x820C\n"
+      "    CMP     R0, #0\n"
+      "    MOV     R6, #0\n"
+      "    BNE     loc_FF98B0A8\n"
+      "    LDR     R0, [R5, #0xBC]\n"
+      "    CMP     R0, #1\n"
+      "    BNE     loc_FF98B090\n"
+      "    LDRH    R0, [R5]\n"
+      "    CMP     R0, R7\n"
+      "    LDRNEH  R0, [R5, #0x96]\n"
+      "    CMPNE   R0, #3\n"
+      "    LDRNE   R0, [R4, #8]\n"
+      "    CMPNE   R0, #1\n"
+      "    BLS     loc_FF98B074\n"
+      "    BL      sub_FF832D6C\n"
+      "    TST     R0, #1\n"
+      "    BEQ     loc_FF98B0A8\n"
+      "    BL      sub_FF888708\n"
+      "    B       loc_FF98B0A0\n"
+"loc_FF98B074:\n"
+      "    MOV     R0, #0xC\n"
+      "    BL      sub_FF8886A0\n"
+      "    TST     R0, #1\n"
+      "    BEQ     loc_FF98B0A8\n"
+      "    BL      sub_FF98B84C\n"
+      "    BL      sub_FF8807AC\n"
+      "    B       loc_FF98B0A0\n"
+"loc_FF98B090:\n"
+      "    MOV     R0, #0xC\n"
+      "    BL      sub_FF8886A0\n"
+      "    TST     R0, #1\n"
+      "    BEQ     loc_FF98B0A8\n"
+"loc_FF98B0A0:\n"
+      "    MOV     R0, #1\n"
+      "    LDMFD   SP!, {R3-R7,PC}\n"
+"loc_FF98B0A8:\n"
+      "    BL      sub_FF88318C\n"
+      "    LDR     R0, [R5, #0x28]\n"
+      "    CMP     R0, #0\n"
+      "    BNE     loc_FF98B170\n"
+      "    MOV     R0, R4\n"
+      "    BL      sub_FF98A948\n"
+      "    TST     R0, #1\n"
+      "    LDMNEFD SP!, {R3-R7,PC}\n"
+      "    MOV     R0, R4\n"
+      "    BL      sub_FF98ACFC\n"
+      "    BL      sub_FF98B790\n"
+      "    LDR     R0, [R5, #0xBC]\n"
+      "    CMP     R0, #1\n"
+      "    BNE     loc_FF98B0FC\n"
+      "    LDRH    R0, [R5]\n"
+      "    CMP     R0, R7\n"
+      "    LDRNEH  R0, [R5, #0x96]\n"
+      "    CMPNE   R0, #3\n"
+      "    LDRNE   R0, [R4, #8]\n"
+      "    CMPNE   R0, #1\n"
+      "    BHI     loc_FF98B104\n"
+"loc_FF98B0FC:\n"
+      "    MOV     R0, #2\n"
+      "    BL      sub_FF889FEC\n"
+"loc_FF98B104:\n"
+      "    BL      capt_seq_hook_set_nr\n" // +
+      "    LDRH    R0, [R5]\n"
+      "    SUB     R1, R0, #0x8200\n"
+      "    SUBS    R1, R1, #0x2D\n"
+      "    BNE     loc_FF98B160\n"
+      "    MOV     R5, #1\n"
+      "    MOV     R2, #2\n"
+      "    MOV     R1, SP\n"
+      "    ADD     R0, R2, #0x15C\n"
+      "    STR     R5, [SP]\n"
+      "    BL      sub_FF895E60\n"
+      "    TST     R0, #1\n"
+      "    MOVNE   R1, #0xBC\n"
+      "    LDRNE   R0, =0xFF98B28C\n"
+      "    BLNE    sub_FF81EC88\n"
+      "    LDRH    R0, [SP]\n"
+      "    CMP     R0, #1\n"
+      "    BLS     loc_FF98B158\n"
+      "    MOV     R0, R4\n"
+      "    STR     R5, [R4, #0xE4]\n"
+      "    BL      sub_FFAF1030\n" // nr-related (read)
+      "    B       loc_FF98B168\n"
+"loc_FF98B158:\n"
+      "    MOV     R0, #0\n"
+      "    STR     R0, [R4, #0xE4]\n"
+"loc_FF98B160:\n"
+      "    MOV     R0, R4\n"
+      "    BL      sub_FFAF0C70\n" // nr-related (read)
+"loc_FF98B168:\n"
+      "    MOV     R6, R0\n"
+      "    B       loc_FF98B180\n"
+"loc_FF98B170:\n"
+      "    LDR     R0, =0x71AC\n"
+      "    LDR     R0, [R0]\n"
+      "    CMP     R0, #0\n"
+      "    MOVNE   R6, #0x1D\n"
+"loc_FF98B180:\n"
+      "    MOV     R0, R6\n"
+      "    LDMFD   SP!, {R3-R7,PC}\n"
+        );
+}
 /*************************************************************/
 
 void __attribute__((naked,noinline)) exp_drv_task(){

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #706 on: 08 / March / 2012, 16:02:42 »
Hi,
I'd like to pass this on to any one who is updating the release code.  The address for recreview_hold in the release (I have 1714) is wrong  for this camera.  The correct address in stubs_min.S  is:
DEF(recreview_hold,  0x3828) as can be seen by reviewing stubs_entry.S.  I have checked this on version 101g.  I think the address is probably the same for all versions.

Jon

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #707 on: 08 / March / 2012, 16:33:39 »

Quote
Wish i was still involved enough to understand the binaries you keep posting
I publish my changes to document what I did (and to give a clue to the next person who will look into this).

One more thing: does the lockup with interval.lua only happen when you pause the running script (by exiting ALT mode), take pictures by hand, and try to resume by entering ALT mode again? If so, does it happen with the official release?


Sorry, I was not clear.  My lack of "keeping up" refers to the the 27 years since I last wrote device specific, low-level code.  Nothing to do with your published code. 

The only real script hang I had was not due to pause/resume the script....I never pause the interval.lua, only interrupt to stop it.

I tried just making a menu change to see if it retriggered DFS but it did not.  Had to recycle the camera and reload CHDK.

Have not tried "force flash" but will tonight.

Thanks for your time!


*

Offline srsa_4c

  • ******
  • 4451
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #708 on: 09 / March / 2012, 00:21:47 »
@imtheguy
Some additional questions.
When the dark frame override stops working
- do the other overrides (like ISO, Tv) still work?
- does RAW work?

Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #709 on: 09 / March / 2012, 01:44:42 »
@imtheguy
Some additional questions.
When the dark frame override stops working
- do the other overrides (like ISO, Tv) still work?
- does RAW work?

Yes, I am sure the ISO and shutter speed overrides always work.  As mentioned before, The ISO when set to "1" and factor of "100" gives me a 160 in the exif.  Change the override to "2" and its now 320 in exif.  Exposure works well but I would love to know if the exif is wrong or if 2 x 100 = 320 for CHDK purposes. 

Have not tried Tv (meaning minimum shutter speed for action shots? ), only 5-20 sec exposures.

RAW works great.  Goes in the jpg folder is directed and no trouble using ACR to convert RAW files.

 

Related Topics