Spent way too long today trying to understand why the CHDK menus seemed to behave strangely >:(. That's part of the problem when you don't know how things are supposed to work and don't have a working camera with CHDK to play with. If I value my time at $1.00 / hour then I could have bought one of the cheaper Canon cameras that work with CHDK and been ahead of the game so far.By the time you are done, you will probably be up to a nice DSLR setup at McJob wages ;)
By the time you are done, you will probably be up to a nice DSLR setup at McJob wages ;)I'd go the DSLR route but I don't like Canon DSLR's. Once you're used to a Nikon, well ....
It's a good idea to reset your CCHDK.CFG after fixing this, some things remember their positions.Thanks - I actually did catch on to the CCHDK.CFG file in the CHDK folder on the SD card. The reset options in the menu seem to work well but every so often I just delete the file itself to see how things initialize with a cold system.
After porting tons of code from firmware to boot.c so I have control of what actually runs, and inserting "break points" that are basically loops to forever blink the green LED, I worked myself into a circle of failure. Maybe it will look different tomorrow. Or maybe I'll just have to live with it when I wear out the battery door.See this thread http://chdk.setepontos.com/index.php?topic=5744.0 (http://chdk.setepontos.com/index.php?topic=5744.0)
See this thread http://chdk.setepontos.com/index.php?topic=5744.0 (http://chdk.setepontos.com/index.php?topic=5744.0)Yup - that worked. Thanks.
If you implement PTP, you can upload without the taking the card out (unless you upload a bad diskboot...)Now that looks interesting. More things to do - never enough time though. Can you download a complete CHDK diskboot.bin file while CHKD is running ? And is that faster than writing the SD card and moving it back and forth from the camera to computer ?
Now that looks interesting. More things to do - never enough time though. Can you download a complete CHDK diskboot.bin file while CHKD is running ? And is that faster than writing the SD card and moving it back and forth from the camera to computer ?Yes, the diskboot is only loaded at startup, you can overwrite it with the camera running. Uploading is very fast, I'd guess less than on second.
Any plans to support firmware 101C?I kind of wondered when this question would come up. There are at least 3 different firmware versions out there according to the wikia. As I only have a camera with version 1.03c, trying to build for another version "blind" without a test camera would be pretty hard. Not to mention finding the time to do that when my port is barely even in "alpha" status at this point.
I may be able to help finding addresses in the code - I started that about a year ago on 101C but never finished it.How far did you get ? It sure would be nice to have someone else to work on this with me. Its amazingly time consuming, especially doing a new camera. If you were working on a different firmware version, I suspect much would be almost the same (hardware especially) or just slightly shifted in memory. We could get a lot more done together.
I found most of the addresses and the patched the code in boot.c, but the camera kept crashing in record mode and I moved on to other things. If you can post your source code, I could pretty quickly drop my stuff into your code and see how that goes.I'm sure it will be no surprise with a newbie doing a first port if I confess that my source code at this point is a mess. Starting from scratch, I've had to tinker to understand how this all comes together. I think that I now understand the build structure basics. The ground rules are to not change stuff in the trunkNNN core, include and lib directories. I'm not so sure about how to treat the platform/generic directory - some of the files have duplicate names with the ones under platform/ixus120_SD940. But the build process seems to sort that out - some don't get compiled and some do despite the name conflict. Not sure how that magic happens yet. In any case, at some point I'll take a day and clean up so that the changes I made in the common files all migrate over to the version specific files.
Some functions also have __attribute__((weak)) versions in the generic code, which may be overridden in camera code. In this case, the weak and non-weak versions must not appear in the same file via includes.So the linker is smart enough to resolve which function to use when two functions have the same name, as long as one of them is tagged __attribute__((weak)). That is slick - I've learned another new thing today. (I assume you can't duplicate names in the same file - the compiler would choke as you've suggested.)
All of this stuff is begging for cleanup :-[I know what you mean. I went through the makefiles trying to figure out how to convince it not to recompile everything from scratch every time. I have a slow computer. But I soon gave that up - although I caught your tip about hiding PRIMARY.BIN. Still, maybe we could capture some of the stuff I've tried to describe in this forum in the wikia sections on building for a new camera ? I could draft it but will need help getting it accurate.
Right. This is a GCC extension. stubs_entry.S and stubs_entry_2.s also depend on this: the NSTUB macro (used in stubs_entry.S) makes a weak symbol, and the NHSTUB macro makes a normal one.Some functions also have __attribute__((weak)) versions in the generic code, which may be overridden in camera code. In this case, the weak and non-weak versions must not appear in the same file via includes.So the linker is smart enough to resolve which function to use when two functions have the same name, as long as one of them is tagged __attribute__((weak)). That is slick - I've learned another new thing today. (I assume you can't duplicate names in the same file - the compiler would choke as you've suggested.)
I know what you mean. I went through the makefiles trying to figure out how to convince it not to recompile everything from scratch every time.If you are using make directly (not CHDK shell) you can just do "make fir" and it will do an incremental build. You have to be aware that it won't necessarily rebuild everything when it should. Generally, changing C files should be OK, but changing headers or compile time options is not. You always want to do a make clean if you change which camera you are building.
Still, maybe we could capture some of the stuff I've tried to describe in this forum in the wikia sections on building for a new camera ? I could draft it but will need help getting it accurate.Sure. If you think what you have is too inaccurate/incomplete to have on the main page, you can always throw it somewhere under your user page on the wiki (like I did with http://chdk.wikia.com/wiki/User:ReyalP/EventProcNotes (http://chdk.wikia.com/wiki/User:ReyalP/EventProcNotes) ), and then move the content when it's cleaned up.
If you are using make directly (not CHDK shell) you can just do "make fir" and it will do an incremental build.I've gotten lazy and have been using CHDK_Shell on my WinXP laptops (work & home) rather than my main Linux box. As result, there are no path / environment variables setup to allow me to just run "make fir". One more thing to work on I guess.
I've gotten lazy and have been using CHDK_Shell on my WinXP laptops (work & home) rather than my main Linux box. As result, there are no path / environment variables setup to allow me to just run "make fir". One more thing to work on I guess.
In CHDK-Shell, click the 'cmdline icon', and type "gmake fir"Wow - that works great. :D I guess that I thought the little command line icon was part of the window wallpaper. I didn't realize it actually did something.
is there a chance to upgrade to 103c? how? it's 2 days i'm searching online, with no result..
I'm still struggling through getting a 103c version running. Someday, when that's done, I hope to be able to help people with other firmware versions of the SD940.
It sure would be nice to have someone else to work on this with me.
I know you do not feel comfortable letting other people look at your code, but keep in mind that my offer to port your code to different firmware versions still stands but I would need to see what you have done.
I didn't understand the CHDK version used (version "2000", no "<ALT>" indicator) so I changed to base it from release 1001.I did mention the code was a little rough - using version 2000 allowed me to ignore updates to the trunk revisions and work on a stable release back when I didn't understand how things worked.
I determined that playrec_mode variable was correct. I also found that the camera was crashing when trying to run histogram_process() when in record mode. The problem was in vid_get_viewport_live_fb. Changing this function to return a null pointer allowed it to run without crashing. I'm not sure how to find the correct addresses for this but returning 0 works for now.I found the same thing today. In fact, I noticed that in the S90 port, vid_get_viewport_live_fb() simply returns 0. Now we know why.
I'm seeing some random vertical shifts of about 20 lines so that the OSD overlay is sometimes too low / sometimes OK. Not sure what's going on there.So far I've commented out things to get the OSD clock to display - I haven't been able to get anything else in OSD to work but that was going to be my next task.
Using the Display key to toggle Alt mode is a little strange. Some features, like the memory browser don't work due to not being able to press Display in Alt mode. I'm not sure how the configurable alt button feature is supposed to work. On the SD940 there is no print button so you can't press the default Alt button (Print) to get to the Alt menu to change the Alt button !I picked the Display key as the ALT key because as you mentioned the SD940 does not have a Print button. I didn't realize it would cause problems in ALT mode, never having actually used CHDK on a camera. Any idea how other cameras handle this ?
I also got the .fir version to work. Just remove the comment from the OPT_FI2=1 line and add the correct fir.inc file and it builds it correctly.What do you use the .fir version for ?
Further to the above, vid_get_viewport_live_fb() is only used by gui_osd.c hostogram.c and motion_detector.c.Nothing breaks, but motion detection and histogram might use older data.
If vid_get_viewport_live_fb() returns NULL or 0, the code seems to substitute vid_get_viewport_fb() and use that instead.
I wonder what breaks because of that? More mysteries to explore.
So far I've commented out things to get the OSD clock to display - I haven't been able to get anything else in OSD to work but that was going to be my next task.I'm not sure what base version you used, but there is some code missing for displaying some of the OSD (such as the ALT indicator).
I picked the Display key as the ALT key because as you mentioned the SD940 does not have a Print button. I didn't realize it would cause problems in ALT mode, never having actually used CHDK on a camera. Any idea how other cameras handle this ?The SD780 uses a short press of Display for Alt and a long press for Display. That might work better.
What do you use the .fir version for ?It's for booting CHDK via the "Firm Update" menu. Not really all that useful to me, but I think it is more useful when using multiple partitions.
I'm not sure what base version you used, but there is some code missing for displaying some of the OSD (such as the ALT indicator).I've never seen the ALT indicator on screen. Might be something I messed up early on - I'll update to the 1001 version and see what happens.
The SD780 uses a short press of Display for Alt and a long press for Display. That might work better.This actually works I think. In normal mode, if I press the Display key briefly then CHDK goes into ALT mode. If I hold the Display button down then the display mode changes. In Alt mode, I'm not sure it does anything other than toggle back to normal mode.
if(!_strcmp(tcb->name, "MovieRecord"))
tcb->entry = (void*)movie_record_task;, the camera crashes when I call strcmp. I have confirmed the strcmp address. The problem is with taking the value tcb->name. I also confirmed that gcc is using 1 byte struct alignment for task_t as defined in dryos31.h. I can go back to the older style hard-coded address compare, but this is supposed to work.
waterwingz, have you gotten the new style taskHook dispatching working?Short answer = no.
What 19xx addresses for the taskHook worked?in boot.c, this worked
And did the addresses you dumped include references to all the tasks we need to patch (capt_seq_task, movie_record_task, init_file_modules_task and exp_drv_task) ?Yes. There are 58 task hooks that show up at 0x1938 at startup and 3 tasks at 0x1940. Another 17 task hooks show up when you enter shooting mode. I wrote them all down by hand and then compared to SD980 tasks to figure out the four we need for the SD940. The addresses in the code I sent you work for 103C - I would not expect your release to be off by much ? I'll take a look at the two firmware dumps and see if I can give you the four addresses for 102c ?
if(p[0]==0xFF8331C4) p[0]=(int)mykbd_task; // SD940 103c
if(p[0]==0xFF88E57C) p[0]=(int)init_file_modules_task;
if(p[0]==0xFF872FE0) p[0]=(int)capt_seq_task;
if(p[0]==0xFF8B2FD0) p[0]=(int)exp_drv_task;
if(p[0]==0xFF93D810) p[0]=(int)movie_record_task;
if(p[0]==0xFF8331C4) p[0]=(int)mykbd_task; // SD940 102c
if(p[0]==0xFF88E570) p[0]=(int)init_file_modules_task;
if(p[0]==0xFF872F84) p[0]=(int)capt_seq_task;
if(p[0]==0xFF8B2F74) p[0]=(int)exp_drv_task;
if(p[0]==0xFF93D648) p[0]=(int)movie_record_task;
Does this look right then ?Code: [Select]
if(p[0]==0xFF8331C4) p[0]=(int)mykbd_task; // SD940 103c
if(p[0]==0xFF88E57C) p[0]=(int)init_file_modules_task;
if(p[0]==0xFF872FE0) p[0]=(int)capt_seq_task;
if(p[0]==0xFF8B2FD0) p[0]=(int)exp_drv_task;
if(p[0]==0xFF93D810) p[0]=(int)movie_record_task;
if(p[0]==0xFF8331C4) p[0]=(int)mykbd_task; // SD940 102c
if(p[0]==0xFF88E570) p[0]=(int)init_file_modules_task;
if(p[0]==0xFF872F84) p[0]=(int)capt_seq_task;
if(p[0]==0xFF8B2F74) p[0]=(int)exp_drv_task;
if(p[0]==0xFF93D648) p[0]=(int)movie_record_task;
I believe init_file_modules should be 0xFF88E520, not 0xFF88E570 for 102C (the task, not the createTask).
It appears that the SD940 uses propset3, not propset2 in camera.h. Changing this should help.Is there a short explanation of what the propset #defines control ? Some sort of offsets into the camera's data structures ?
Here's where I am at on the 102CAre you going to post your "alpha" build somewhere. Seems like there are more than a few SD940 owners who are interested - my useless 103c version has had over 25 downloads.
I noticed the propset problem when all the pictures used the same shutter speed. I traced it to the prop case for Tv being always 0. I checked several other prop cases and it looks like propset 3 is a good match. Using the prop case debug screen helps to figure out which settings go with which prop case number.Here's where I am at on the 102CAre you going to post your "alpha" build somewhere. Seems like there are more than a few SD940 owners who are interested - my useless 103c version has had over 25 downloads.
Also, gcc 3 is faster than gcc 4 from what I've heardAbout twice as fast
you could probably also remove the tools and lib directories from the compile part of the build if you know that those did not change, but I haven't tried that yet.probably not much to be gained there; on the other hand, once your stubs & sigs are properly generated,
movie record:
optical zoom works
Did you find a better workaround for vid_bitmap_refresh() than what I did ?
I posted at http://chdk.setepontos.com/index.php?topic=5857.0 (http://chdk.setepontos.com/index.php?topic=5857.0) and a few other place but never came up with anything that actually worked properly.
On the S95 I came up with a workaround like yours:
I eventually figured out a better location for the screen lock/unlock routines on the S95. I'll look into this on the '940.
Code: [Select]extern void _LockAndRefresh(); // wrapper function for screen lock
extern void _UnlockAndRefresh(); // wrapper function for screen unlock
Okay - maybe I just don't understand the terminology here so I'll ask a dumb question. What do you mean by wrapper function ? I can find ScreenLock() and ScreenUnlock() by matching the S90 port. The code even seems to make some sense - incrementing and decrementing some sort of lock counter each time the respective routine is called. When you get a minute, would you mind doing a cut&paste of code for the wrapper function so I can see what you mean? ScreenLock & Screenunlock seem to get called from a lot of place ( over 450 each ).
Bern R managed to get his compile time down to 5.5 sec using gmake fir on GCC 3.4.6:
Source:I'm really liking your source. Makes me realize I should have started looking at the S90 port from the start rather than the beta S980.
http://www.zshare.net/download/83836185dbd6d38e/ (http://www.zshare.net/download/83836185dbd6d38e/)
// @FF8586DC
if ((*(int*) 0xC0220128) & 1) // look at play switch
*(int*)(0x22FC) = 0x400000; // start in play mode
else
*(int*)(0x22FC) = 0x200000; // start in rec mode
One question about boot.c ? Does this actually work ?Code: [Select]// @FF8586DC
if ((*(int*) 0xC0220128) & 1) // look at play switch
*(int*)(0x22FC) = 0x400000; // start in play mode
else
*(int*)(0x22FC) = 0x200000; // start in rec mode
Yes, it does if you press and hold the Power button until the lens extends.
Hmmm .. all I changed on the 103c code was adding those 5 lines. Now if I hold the shoot on/off button down ( the one on the top of the camera ) instead of a short press, the camera starts ( my added AF LED blink happens ) but never gets to turning on the display or anything beyond that. Some other change I missed maybe ?
In your version of boot.c there is a line with the comment "removed for correct power-on on 'on/off' button." You should comment out the code on this line.
In your version of boot.c there is a line with the comment "removed for correct power-on on 'on/off' button." You should comment out the code on this line.
Works now. Wow - have you also got any tips for me on the stock market?
I spent some time on the SD940 port. Here's what's different today:
battery readout is always 0V [strange problem !
I'm hoping that more than the two of us are using this. I'm counting on others to test this, since I only rigorously test what I use, which is about 10% of the features.
I get a voltage reading of 3.638 in text mode but the icon does not fill. I assume its supposed to do that but maybe needs some sort of scaling factor ?The battery voltage code has a low pass filter on the value from the firmware function, otherwise it is a thin wrapper around the firmware. I bypassed the filter with no difference, The stub address for 102c is the same as for 103c so I'm a little mystified by the difference. I suppose I'll find a misplaced semicolon eventually. Until then, I can convince myself that I don't need a battery readout.
The SD940 was always a bit of a niche camera. It's basically a SD780 with a larger LCD, no optical viewfinder, a bigger lens and a higher price.
I'm hoping that more than the two of us are using this. I'm counting on others to test this, since I only rigorously test what I use, which is about 10% of the features.
Scripts run in the alpha version. However, none of the scripting functions have been tested so likely some will work and some will not.
FWIW, I'm working on a fairly complex time lapse script involving exposure overrides, math, timers, and shooting and it all works perfectly on the SD940.
Now that I have a spare moment this week, I'm folding my code into yours so the 1.02c and 1.03c versions work the same. Do you think we can be brave enough to claim we have reached Beta status ?
I've never really understood the alpha/beta thing with regard to CHDK. Compared to any commercial software, I would say that the most well-refined version of CHDK is still "alpha". I would say that 1 week after the last unresolved bug report, you should release it to the trunk for auto-builds.
Having a problem with capt_set.c. At first I thought it was not saving images to the SD card. But when I look at the SD card, images are being stored in the right subdirectories under DCIM. However, the file names are not prefixed by "IMG_" - they are just stored as (for example) 1234.jpg rather than IMG_1234.jpg . This means the camera does not see them in playback mode.
Right now, I think I have the code stripped so that its an exact copy of the ROM code - no links to CHDK functionality - and I'm still not getting the right file names. Any ideas ?
I will run to the shop and buy a camera. Is it firmversion 1.02c and 1.03c I should be looking for?
I saw one in a shop today and have also seen a few on different online-shops. Any idea why these go for the price of eg. Ixus130IS + 50-100% ?I think that newer models tend to have better prices while they are in mass market sales mode. A quick look at the specs of SD4000 (IXUS130) says its a bit of an upgrade from the SD940. Might be a better buy ?
Still having problems with pictures being saved without the IMG_ prefix (just as nnn.jpg not IMG_nnn.jpg).Camera jpegs are saved without prefix ? CHDK doesn't (intentionally) change this at all...
Camera jpegs are saved without prefix ? CHDK doesn't (intentionally) change this at all...That's what I thought too - trying to do it on purpose would be difficult. I'll keep digging.
Hi all, trying to dump my 940's 1.03B FW image. If I boot newdryos version of diskboot.bin I get black screen but if I wait 1 min. empty.dum is just nulls. Trying dryos version of diskimage.bin gives me disk locked after multiple attempts. I'm using cardtricks 1.44 to make the SD card dumper.
Any ideas as to what I might be missing?
I would try deleting the CCHDK.CFG. Let it get rebuilt and see if that helps. Also, problems with conf_restore can be the result of bad addresses for file I/O functions, although I can't think of a reason that would cause your particular file name symptoms.Thanks waldo. That wasn't it but the problem is solved - sort of. Did a binary search of each entry in conf_info[] and eventually tied the strange filename behaviour to whether or not the splash screen was enabled. Ouch. More trial and error led me eventually to my old friend vid_bitmap_refresh(). The other day I had been trying to implement the various combinations of _ScreenLock() and _ScreenUnLock() that I have seen on this forum. (I had originally hacked this rountine to simply do draw_filled_rect(0, 0, screen_width, screen_height, 0x00)). I had left some of the Lock/Unlocks laying around there. No idea why it caused the weird filename behaviour - once I commented it out everything started working properly.
Pick up the much better 120 IS, even if it is a few millimetres thicker.That's what I think too - but I might be a little biased. 8)
Besides, I don't think there is a chdk port ready for the 130IS yet.
# made with checksum.. point-and-click hashing for windows.
# from corz.org.. http://corz.org/windows/software/checksum/ (http://corz.org/windows/software/checksum/)
#
2f4ce34f6ed0d8a507ccad97aa8fafb6 *PRIMARY.BIN
All of which leads me to my conclusion that the small cadre of SD940 owners will be pretty excited once CHDK is available for their favorite camera.
Quickly setup the CHDK-shell build environment on a win7 laptop I have here. Dropped in sd940-source-v4.zip as a platform and tried to build 103C. It errored out because I don't have fi2.inc with the correct keys. Are you fellas using an environment that doesn't require fi2.inc?if you turn off OPT_FI2 you do not need it. Otherwise, you need to read platform/fi2.inc.txt and find the appropriate keys.
========== E:\CHDK\TRUNK\TRUNK1005\BIN\LOGS\ERR-IXUS120_SD940-103C.TXT ==========
../platform/ixus120_sd940/libplatform.a(lib.o): In function `vid_bitmap_refresh':
lib.c:(.text+0x24): undefined reference to `_ScreenLock'
../platform/ixus120_sd940/libplatform.a(lib.o): In function `vid_turn_off_updates':
lib.c:(.text+0x10c): undefined reference to `_ScreenLock'
collect2: ld returned 1 exit status
E:\CHDK\gcc451\bin\gmake.exe[1]: *** [main.elf] Error 1
gmake: *** [all-recursive] Error 1
Can you confirm that this is the same checksum you get for your 1.03B PRIMARY.BIN image file?:
Quickly setup the CHDK-shell build environment on a win7 laptop I have here. Dropped in sd940-source-v4.zip as a platform and tried to build 103C.
The code you downloaded was posted by waldo, who is working on the 102c version. I'm pretty sure the 103c version does not build with that code - at least not yet.
Btw, with regard to the different firmware-versions; would it not be easier to change the firmware on the camera -instead of creating separate ports of chdk for every firmware-version?I would probably be easier but Canon does not support changing firmware on their cameras. There is no know firmware upgrade method.
It seems the alphabuild placed on zshare is missing the ps.fi2, or am I missing something here?I have not tried to build a ps.fi2 file as I just copy the Diskboot.bin file to my SD card and boot using the "write protect" switch. Is there a need for a ps.fi2 file for the SD940? I thought that was only used on cameras that for some reason don't boot with the "write protect" method.
Is there an equivalent archive for the 103C source that I could d/l, drop onto trunk and try to build with CHDK-shell?I'll post my version as soon as I finish cleaning up from the mess I made tracking down the bug mentioned yesterday in this forum. Probably in the next couple of days - I modified the makefile and makefile.inc files so that building either version is supported. I guess I'll also add the 1.03B version as well. Other than that I'm working off Waldo's files for the core, include and platform stuff.
It seems the alphabuild placed on zshare is missing the ps.fi2, or am I missing something here?I have not tried to build a ps.fi2 file as I just copy the Diskboot.bin file to my SD card and boot using the "write protect" switch. Is there a need for a ps.fi2 file for the SD940? I thought that was only used on cameras that for some reason don't boot with the "write protect" method.
Well, without the ps.fi2 I don't get the firmware update option in the menu, with the file I do, though a zero-byte file with the name ps.fi2 doesn't seem to load the chdk properly (camera hangs with a black screen, have to remove the battery to get it goin' again)...I just looked at the forum thread for making the fi2.inc file needed to produce a ps.fi2 file.
Having said that, my first attempt at RAW crashed the camera after creating a new directory on the SD card with an empty RAW image there.This most probably isn't the reason for crashing, but: since Canon changed the folder layout / folder creation mechanism for the newer Powershots, it's recommended to disable the "RAW File in Dir with JPEG" setting from the CHDK RAW menu.
it's recommended to disable the "RAW File in Dir with JPEG" setting from the CHDK RAW menu.
@Waldo
I am having great difficulty porting this to SDM.
The camera crashes on booting when restoring CFG values.
That function also executes if there is no existing CFG file.
For conf values that have an associated conf_change_script_file() function, script_load() is called.
That calls script_scan(..) and crashes.
That code is common to all cameras.
Have you had similar problems ?
// CONF_INFO( 63, conf.alt_mode_button, CONF_DEF_VALUE, i:KEY_PRINT, conf_change_alt_mode_button),
// change default to Print for sd940
CONF_INFO( 63, conf.alt_mode_button, CONF_DEF_VALUE, i:KEY_DISPLAY, conf_change_alt_mode_button),Thanx for the hint, I got it working now with a different SD card with the writeprotect enabled, gonna do some testingWell, without the ps.fi2 I don't get the firmware update option in the menu, with the file I do, though a zero-byte file with the name ps.fi2 doesn't seem to load the chdk properly (camera hangs with a black screen, have to remove the battery to get it goin' again)...I just looked at the forum thread for making the fi2.inc file needed to produce a ps.fi2 file.
http://chdk.setepontos.com/index.php/topic,2995.0.html (http://chdk.setepontos.com/index.php/topic,2995.0.html)
Looks like more work than I have time for right now. Did you try using the other (SD card write protect) method of booting - it does not need the ps.fi2 file.
Thanx for the hint, I got it working now with a different SD card with the writeprotect enabled, gonna do some testing
I spent some time on the SD940 port.
.....
I'm hoping that more than the two of us are using this. I'm counting on others to test this, since I only rigorously test what I use, which is about 10% of the features.
Thanx for the hint, I got it working now with a different SD card with the writeprotect enabled, gonna do some testing
Latest Beta release at the start of this thread has what you were looking for. I haven't tested it so if you get a chance you might see if it works ?
i sometimes had that message while messing up with zooming and some random camera, but it automagically fixed itself rebooting the camera without injecting code. maybe you have some code that's calling bad firmware addresses?That message should normally comes up only when the lens is jammed (dirt, misshandling etc). In this case, all I did was swap in and out the SD card. Lens is fine. Whatever got toasted, it generates the error with a normal SD card - no CHDK.
A link to the proper instructions would be nice.http://chdk.wikia.com/wiki/CHDK_for_Dummies (http://chdk.wikia.com/wiki/CHDK_for_Dummies) Look 1/3 of the way down for the section called "Load CHDK onto the card"
Thanks, The "for dummies"-paper seemes to be exactly what I have been looking for. Will try it out tomorrow.
Really interested in putting this on my camera, how far along is the hack?For the two firmware version ported so far, all the coding and porting work is complete. In theory, everything should work but with only a little testing so far we do not have a good understanding of what does and what does not function as required. Your volunteer work helping to test would be most appreciated.
Is it safe to use without much loss of CHDK functionality?From the wiki : http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera.C2.A0.3F (http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera.C2.A0.3F)
Any ideas for what I could try?
void my_kbd_read_keys()
{
static int altDownTimer=0;
const int DISP_DOWN_TIME = 20;
kbd_prev_state[0] = kbd_new_state[0];
kbd_prev_state[1] = kbd_new_state[1];
kbd_prev_state[2] = kbd_new_state[2];
_platformsub_kbd_fetch_data(kbd_new_state);
kbd_new_state[2] |=0x00008000; /// disable the battery door switch
// support for short/long press of Display
if (kbd_is_key_pressed(KEY_DISPLAY)) { // Display held down
altDownTimer++; // timer for DISP
}
else {
altDownTimer = 0;
}
if (kbd_process() == 0) {
// leave it alone...
physw_status[0] = kbd_new_state[0];
physw_status[1] = kbd_new_state[1];
physw_status[2] = kbd_new_state[2];
physw_status[0] |= alt_mode_key_mask; /// disable the ALT mode button
physw_status[SD_READONLY_REG] = physw_status[SD_READONLY_REG] & ~SD_READONLY_FLAG;
}
else {
// override keys
physw_status[0] = (kbd_new_state[0] & (~KEYS_MASK0)) |(kbd_mod_state[0] & KEYS_MASK0);
physw_status[1] = (kbd_new_state[1] & (~KEYS_MASK1)) | (kbd_mod_state[1] & KEYS_MASK1);
physw_status[2] = (kbd_new_state[2] & (~KEYS_MASK2)) |(kbd_mod_state[2] & KEYS_MASK2);
if (altDownTimer > DISP_DOWN_TIME) {
physw_status[0] &= ~alt_mode_key_mask; // press the Display button
}
}
_kbd_read_keys_r2(physw_status);
physw_status[2] = physw_status[SD_READONLY_REG] & ~SD_READONLY_FLAG;
remote_key = (physw_status[2] & USB_MASK)==USB_MASK;
if (remote_key) {
remote_count += 1;
}
else if (remote_count) {
usb_power = remote_count;
remote_count = 0;
}
if (conf.remote_enable) {
physw_status[2] = physw_status[SD_READONLY_REG] & ~(SD_READONLY_FLAG | USB_MASK);
} else {
physw_status[2] = physw_status[SD_READONLY_REG] & ~SD_READONLY_FLAG;
}
}I think some of the current SD940 issues may be getting lost due to the length of this thread.I was wondering about that too so I've proposed a bit of an experiment. There is probably a better way to do this but at least this is a start :
Here's my list of what is not working:
Edge overlay not working
http://chdk.setepontos.com/index.php?topic=5855.msg58277#msg58277 (http://chdk.setepontos.com/index.php?topic=5855.msg58277#msg58277)
Difficult or impossible to use long press of DISP to get to Canon DISP functions
http://chdk.setepontos.com/index.php?topic=5855.msg58074#msg58074 (http://chdk.setepontos.com/index.php?topic=5855.msg58074#msg58074)
Battery readout not working in 102c
Before I continue, am I on the right track with this?So far, so good. To go any farther, you are going to need a dissassembly of the PRIMARY.BIN file so that you can figure out the correct entries for stubs_entry_2.s, lib.c, stubs.asm.h and the code for boot.c, capt_seq.c and movie_rec.c.
I dropped the PRIMARY.BIN I extracted from my 103B camera into ixus120_sd940/sub/103b and then used CHDK shell to build 103b.There are two relevant settings for this in the "Compile Options" menu: OPT_GEN_STUBS and OPT_GEN_SIGS
The PRIMARY.BIN files in the sub folders were all 0 length but the stubs_entry.S was present and populated. Is that just to save space when distributing?No; the firmware dumps (PRIMARY.BIN files) are not in the SVN tree; without a corresponding firmware dump file the build process creates an empty spare file and skips searching for signatures...
What is the 103B directory in the trunk1001-SD940-BETA1.zip archive based on? I just noticed that boot.c is quite different between it and the one for 103C. Should I be using the files for 103C as a 103B baseline?Sorry for the confusion. I had put your Primary.BIN file in the the 103B folder when I was setting up the directories and I ran a trial build of the 103B. So the stubs_entry.S is based on your firmware dump. I deleted the firmware dumps when making the zip file. You can put it back in and follow fe50's suggestions from above to rebuild. The boot.c file in there is an older version of the 103C build - probably better to just discard it and work from the current 103C or 102C files. They are now pretty close to being the same. The S90 port also makes a good reference.
@waterwingz, You may want to test while enabling raw, dng, edge overlay and zebra.Raw seems to be okay on its own although the image is useless. I suspect buffer address needs work. Dng won't work because LUA will not create a badpixel file. In fact most of LUA functions seem to crash - could not run the LLIBTST.LUA script for example. Have not been able to get anything but snow from my first looks at edge overlay and zebra. Not sure if that's RAM or bad addresses yet.
My camera shows virtually no free memory and will crash when enabling combinations of those features.Stupid question time - how do you tell how much free memory you have ? Also, does this mean doing a more custom port and cutting out things like games and/or maybe one of the two scripting engines ?
Stupid question time - how do you tell how much free memory you have ? Also, does this mean doing a more custom port and cutting out things like games and/or maybe one of the two scripting engines ?
It changes as features are turned on and off, but I have seen as little as 512 bytes free.
Free Memory shows about 130K using the Show Memory Info menu item. It varies a few K depending on what's enable. I assume this probably means its calculating free memory based on some parameter not set correctly in one of the many files that need to be edited.
Analyzing 103c/stubs_entry.S and 103b/stubs_entry.S to determine offset ranges.
For addresses less than 0xFF87E5C8 no offset required
For addresses between 0xFF87E5C8 and 0xFF925848 add the offset: -80(0x50)
For addresses between 0xFF9358EC and 0xFFB0A224 add the offset: -444(0x1BC)
For addresses greater than 0xFFB0A224 use offset: -444 (0x1BC)
36 addresses updated in 103b/stubs_entry_2_with_offsets.S
24 addresses updated with offsets in 103b/boot.c_with_offsets
277 addresses updated with offsets in 103b/capt_seq.c_with_offsets
391 addresses updated with offsets in 103b/movie_rec.c_with_offsets
Compare these files to the originals in 103b/ and save as such if they look good
Looking at the modified addresses (including sub_ and loc_ tags) in my PRIMARY.BIN's dissassembly it seems to be working. If I'm on the right track I need to go through the offset files and find/fix any discrepancies.Ha ha - I did something very similiar while I was working through it - although I used an Excel spreadsheet to calculate variances between the SD940 and SD980 releases I was trying to understand. Turned out to be a pretty much useless exercise as, in the end, I put the two dissassembly dumps side by side and matched address from the first stubs_entry_2.S to the source code for that camera and then found the same source code for the other camera and saved the resulting address in its stubs_entry_2.S.
waterwingz, you must have gotten that 103B file from somewhere else as I didn't upload mine until now.Yes - lost track of where things came from - somebody named http://chdk.wikia.com/wiki/User:Spike940 (http://chdk.wikia.com/wiki/User:Spike940) did the dump for the 103B and was hoping somebody else was going to be able to do the port.
--[[
@title LUA Test 1
--]]
repeat
press("shoot_full")
release("shoot_full")
sleep(5000)
until false--[[
@title LUA Test 2
--]]
function TakePicture()
press("shoot_full")
release("shoot_full")
end
repeat
TakePicture()
sleep(5000)
until false
@waldo : Does LUA work for you ? I cannot call functions in my version - makes me suspicious about stack allocation.
This works :Code: [Select]--[[
@title LUA Test 1
--]]
repeat
press("shoot_full")
release("shoot_full")
sleep(5000)
until false
this does not ( camera shutsdown with nothing saved )Code: [Select]--[[
@title LUA Test 2
--]]
function TakePicture()
press("shoot_full")
release("shoot_full")
end
repeat
TakePicture()
sleep(5000)
until false
Would you mind trying this on your port ?
Thnk
please someone who owns sd940 test how much memory is free after chdk loading on SD940 in play mode with empty memory card ( black screen - no pictures),
I see results of your free memory from previous posts(cca 130k) but I dont know conditions of test (play/capture mode start, empty/ not empty memory card).
Please, start in play mode with empty memory card to test free memory.
To get zebra working, you need add in camera.h this i think
#define CAM_ZEBRA_ASPECT_ADJUST 1
#define CAM_ZEBRA_NOBUF 1
your memory is lower.IX 1000 have 251xxx bytes
maybe you try out to disable in chdk shell compiler options opt_game xxxxx opt_textreader if things go better.if not, then its no mem problem
Here's my proposal for the DISP key issue:
<snip>
It seems fairly intuitive once you get the hang of the key press timing. It's not ideal and will cause confusion for new users, but it's the best I came up with so far.
With memory 200K - 300K less than other cameras, somehow saving 5K to 10K does not seem like much help. Still, its worth a shot. I read in another thread that using gcc4 saves space too - but its was awefully slow the last time I tried it.There are some more cameras with < 300kb free RAM successfully running the "standard" CHDK build...
There are some more cameras with < 300kb free RAM successfully running the "standard" CHDK build...
This wikia article may be helpful for you:
@waldo
>It seems fairly intuitive once you get the hang of the key press timing. It's not ideal and will cause >confusion for new users, but it's the best I came up with so far.
I use such a long press code on IX1000 to enter alt mode.because this camera have only set/func and menu key and cursor key
But what i miss, is a short sound from camera speaker when time is reach.Do you know how can add such a sound ?
So the user get a notify when the key is press long enough to do a long press action.then he can release the key or wait for another beep, if he want a third option on this key
have you fix the offset Problem in Zebra ?
if this is not do, then zebra and edge overlay work only in W (16:9) shooting Mode correct.
Have your Cam no W mode with 16:9 aspect ?SD940 manual says it does (p. 148)
have you fix the offset Problem in Zebra ?
if this is not do, then zebra and edge overlay work only in W (16:9) shooting Mode correct.
Posted Beta 2 release for firmware 103c
Can you post a build for 102c as well? Thanks.http://www.zshare.net/download/84642295f5a0c8ce/ (http://www.zshare.net/download/84642295f5a0c8ce/)
Can you post a build for 102c as well? Thanks.http://www.zshare.net/download/84642295f5a0c8ce/ (http://www.zshare.net/download/84642295f5a0c8ce/)
Obviously, not tested - let me know how it works ? (I'll update the root post once I know this boots)
Your version boots just fine and seems to work like the version I compiled
Your version boots just fine and seems to work like the version I compiled
Something has been bugging me for a while - since we've been wrestling with this whole memory issue. It just came to me a few minutes ago what it was - something I noticed months ago but ignored while chasing bigger problems.
In my version of trunk/platform/ixus120_sd940/sub/103c/makefile.inc, the value of MEMISOSTART=0x153E84. I can't remember why or where that came from.
In trunk/platform/ixus120_sd940/sub/102c/makefile.inc, the same constant is MEMISOSTART=0x13CA18
Could that be a clue ?
Yes, that would make a difference. I believe the 0x13CA18 value is correct for both versions.
Maybe I'll do a stripped-down version for my own use.
have you change something ?Only changes were this : http://chdk.setepontos.com/index.php?topic=5855.msg58941#msg58941 (http://chdk.setepontos.com/index.php?topic=5855.msg58941#msg58941)
currently all 16:9 display camera have the problem that zebra only work without offset in W mode
#define ASPECT_GRID_XCORRECTION(x) ( (x) ) //grids are designed on a 360x240 basis DOH !
I was using the wrong address for free() - should be 0xFF814138. Much better now...
While you're at it, you can make it refocus in video mode:
Still Badly Broken :
1) Invalid RAW images stored
char *hook_raw_image_addr()
{
return 0x4219D120; // @FF874840 for 102C / FF87489C for 103C
}
Try this:Code: [Select]return 0x4219D120;
Try this:Code: [Select]return 0x4219D120;
That's what I already have - at least in the current Beta releases. Might have been different in what I originally sent to you.
I'm thinking the problem might be in camera.h - CAM_RAW_ROWPIX, CAM_RAW_ROWS maybe ?
The 102c code still had something else in that function. The 102c works now with only that change, so you may want to compare the 102c code to the 103c code for other differences.Working on that. Are you using the camera.h I put in the beta release or your own ? Can you send my your own if its different ? TIA.
Working on that. Are you using the camera.h I put in the beta release or your own ? Can you send my your own if its different ? TIA.
#elif defined (CAMERA_ixus120_sd940)
#define CAM_DRYOS_2_3_R39 1//stat is different, as well as some other functions
#define SYNCHABLE_REMOTE_NOT_ENABLED 1
#define CAM_PROPSET 3
#define CAM_DRYOS 1
#define CAM_RAW_ROWPIX 4080 // from calcs see 100C lib.c
#define CAM_RAW_ROWS 3048 // " " " " "
#undef CAM_SWIVEL_SCREEN
#define CAM_ADJUSTABLE_ALT_BUTTON 0
#define CAM_CAN_SD_OVER_NOT_IN_MF 1
#define CAM_CAN_UNLOCK_OPTICAL_ZOOM_IN_VIDEO 1
#define CAM_HAS_VIDEO_BUTTON 1
#define CAM_VIDEO_QUALITY_ONLY 1
#define CAM_BRACKETING 1
#undef CAM_VIDEO_CONTROL
#undef CAM_HAS_IRIS_DIAPHRAGM
#define CAM_MULTIPART 1
#undef CAM_HAS_JOGDIAL
#undef CAM_USE_ZOOM_FOR_MF
#undef CAM_UNCACHED_BIT // shut up compiler
#define CAM_UNCACHED_BIT 0x40000000
#define CAM_HAS_ND_FILTER 1
#define CAM_CAN_SD_OVERRIDE 1
#define DNG_SUPPORT 1
// pattern
#define cam_CFAPattern 0x02010100 // Red Green Green Blue
// color
#undef CAM_BITMAP_PALETTE
#define CAM_BITMAP_PALETTE 3
#define CAM_COLORMATRIX1 \
827547, 1000000, -290458, 1000000, -126086, 1000000, \
-12829, 1000000, 530507, 1000000, 50537, 1000000, \
5181, 1000000, 48183, 1000000, 245014, 1000000
#define cam_CalibrationIlluminant1 1 // Daylight
// cropping
#define CAM_JPEG_WIDTH 4000
#define CAM_JPEG_HEIGHT 3000
#define CAM_ACTIVE_AREA_X1 20
#define CAM_ACTIVE_AREA_Y1 12
#define CAM_ACTIVE_AREA_X2 4056
#define CAM_ACTIVE_AREA_Y2 3038
// camera name
#define PARAM_CAMERA_NAME 4 // parameter number for GetParameterData
#undef CAM_SENSOR_BITS_PER_PIXEL
#undef CAM_WHITE_LEVEL
#undef CAM_BLACK_LEVEL
#define CAM_SENSOR_BITS_PER_PIXEL 12
#define CAM_WHITE_LEVEL ((1<<CAM_SENSOR_BITS_PER_PIXEL)-1)
#define CAM_BLACK_LEVEL 127
#define CAM_EXT_TV_RANGE 1
#define CAM_SHOW_OSD_IN_SHOOT_MENU 1
//nandoide sept-2009
#undef CAM_USES_ASPECT_CORRECTION
#undef CAM_USES_ASPECT_YCORRECTION
#define CAM_USES_ASPECT_CORRECTION 1 //camera uses the modified graphics primitives to map screens an viewports to buffers more sized
#define CAM_USES_ASPECT_YCORRECTION 0 //only uses mappings on x coordinate
#undef ASPECT_XCORRECTION
#define ASPECT_XCORRECTION(x) (((x)<<1)) //correction x*screen_buffer_width/screen_width = x*960/480 = x*2/1
#undef ASPECT_GRID_XCORRECTION
#define ASPECT_GRID_XCORRECTION(x) ( ((x)<<3)/9 ) //grids are designed on a 360x240 basis and screen is 320x240, we need x*320/360=x*8/9
#undef ASPECT_GRID_YCORRECTION
#define ASPECT_GRID_YCORRECTION(y) ( (y) ) //y correction for grids made on a 360x240 As the buffer is 720x240 we have no correction here.
#undef ASPECT_VIEWPORT_XCORRECTION
#define ASPECT_VIEWPORT_XCORRECTION(x) ASPECT_GRID_XCORRECTION(x) //viewport is 360x240 and screen 320x240, we need x*320/360=x*8/9, equal than grids, used by edgeoverlay
#undef ASPECT_VIEWPORT_YCORRECTION
#define ASPECT_VIEWPORT_YCORRECTION(y) ( (y) )
#undef EDGE_HMARGIN
#define EDGE_HMARGIN 20
//games mappings
// renamed GAMES_SCREEN_WIDTH / GAMES_SCREEN_HEIGHT
#undef GAMES_SCREEN_WIDTH
#undef GAMES_SCREEN_HEIGHT
#define GAMES_SCREEN_WIDTH 360
#define GAMES_SCREEN_HEIGHT 240
#undef ASPECT_GAMES_XCORRECTION
// 720/360=2 same aspect than grids and viewport but another approach: there is a lot of corrections to do in game's code, and we decide to paint directly on display buffer wirh another resolution
// used by gui.c that configures the draw environment (trhough new draw_gui function) depending on gui_mode: we have then 360x240 for games (but deformed output:circles are not circles) and 320x240 for
// other modes in perfect aspect ratio 4/3: slightly better visualization: file menus more readable, ...
#define ASPECT_GAMES_XCORRECTION(x) ( ((x)<<1) )
#undef ASPECT_GAMES_YCORRECTION
#define ASPECT_GAMES_YCORRECTION(y) ( (y) ) //none
//zebra letterbox for saving memory
#undef ZEBRA_HMARGIN0
#define ZEBRA_HMARGIN0 30 //this 30 rows are not used by the display buffer is 720x240 effective, no 960x270, i.e. (270-240) reduction in widht possible but not done (more difficult to manage it and slower).
#define CAM_AF_SCAN_DURING_VIDEO_RECORD 1
@waldo : Can you run any of the LUA test scripts in the default script folder ( badpixel.lua, llibtst.lua, tstcallf.lua ) ?
So maybe I've got tools that understand the SD1200 dump and not the SD940 ?Most programs that understand CHDK CRW use code from dcraw. dcraw is updated occasionally to support new cameras.
I use DNG. To use, create a file called badpixel.bin in \CHDK. Maybe an empty file will work, otherwise try 8 or 16 bytes of 0x00.Needs to be at least 16 0x00's. I get a CRW file that I can open and see an image. If I ask FSViewer to show it full size it is a whole lot bigger than my computer screen so I'm hoping its not just scaling up the jpg thumbnail that I think is embedded in each DNG version of a CRW file ? If not then what this means is that it has been working all along - doh!
I'd suggest using rawconvert (in the tools directory) to turn it into an 8bpp greyscale. That should be enough to tell if you have the correct dimensions and image buffer.
Needs to be at least 16 0x00's. I get a CRW file that I can open and see an image.Don't confuse the *extension* with the *format* of the file. If you have DNG turned on you get a DNG. Some programs are smart enough to figure out a file with a format that doesn't match the extension.
Okay - worked out how to get the makefile in the tools directory to build an executable version of rawconvert. What should I use as command line parameters to get an 8bpp greyscale - that was not obvious and trial & error has not helped. Also - any suggestiong on what image viewer should understand the resulting output ?http://chdk.wikia.com/wiki/CHDK_Tools (http://chdk.wikia.com/wiki/CHDK_Tools)
Thank again!
I need a little debugging advice here.Maybe stomping on something that ends up killing spytask.
I'm chasing whatever it is that make LUA crash in my port. I've read through the wiki on debugging http://chdk.wikia.com/wiki/Debugging#Reading_the_romlog (http://chdk.wikia.com/wiki/Debugging#Reading_the_romlog).
The good news is that I get what looks like a valid camera dump after each crash. First line is almost alway "Exception!! Vector 0x10" - an attempt to access an invalid memory address. I think I also once saw a "Exception!! Vector 0x04" - undefined instruction. Either way, the camera appears to head off into the void while running LUA scripts.
Other information : its always "Task name: SpyTask" in the dump logs. Why ? I though LUA and BASIC run from the mykbd_task() ?
Since you are getting an exception, you should look at PC (R15) in the register dump. That should be the address of the offending instruction. More likely to be useful with data access exception. If you want to post the register dump and the first bit of the stack dump here, I may be able to provide some help.I cut and pasted four ROMLOG files below. R15 seems only seems to point into ROM once in the four logs.
==========================================================================
Exception!! Vector 0x10
Occured Time 2011:01:02 09:43:32
Task ID: 12910616
Task name: SpyTask
Exc Registers:
0x00307534
0x00197E50
0x00000001
0xD1B560C4
0x0019ACD4
0x00000000
0x00000000
0x00000000
0x19980218
0x001611BB
0x19980218
0x00307524
0xFFB0D484
0x00307518
0x0016B3E4
0xFF87E580
0x00000013
StackDump:
0x00307554
0x00307528
0x0015F083
0x0016B3E0
0x0000B471
0x00000201
0x00000000
0x4D2048C4
0x0019ACD4
0x00000100
0x0019ACD4
0x00000201
0x00159B95
0x00000000
0x00000140
0x00000000
0x0016B51D
0x0019ACD4
0x0015A23D
0x0019554C
0x00000000
0x00154055
0x002F2D44
0x19980218
0x19980218
0xFF816A20
0x19980218
0x19980218
0x00000808
==========================================================================
Exception!! Vector 0x10
Occured Time 2011:01:05 18:34:06
Task ID: 12910616
Task name: SpyTask
Exc Registers:
0x00000000
0x00000000
0x00000000
0x00000000
0x60000013
0x00000000
0x00163587
0x002C2000
0x00307554
0x001635CD
0x003078F4
0x003078F4
0x0030761C
0x00307538
0x00165FC9
0x0030762C
0x00000010
StackDump:
0x003078F4
0x002C1DD0
0x003078F4
0x002C5600
0x0030761C
0x003078F4
0x00166073
0x002C5600
0x00000004
0x0016159B
0x0030761C
0x00307BA8
0x0030761C
0x00162245
0x0030761C
0x00307BA8
0x0030761C
0x00162387
0x003078F4
0x00000024
0x0000000D
==========================================================================
Exception!! Vector 0x10
Occured Time 2011:01:05 18:52:24
Task ID: 12910616
Task name: SpyTask
Exc Registers:
0x00005555
0x00307558
0xE12FF001
0x7A3A834C
0xE59F110C
0x1777CD2C
0xE5911000
0x003075F1
0x80000013
0xFF812C3C
0x002C4CB8
0xFF814114
0x00000000
0x00307538
0x002C4CC0
0x00000362
0x800000B8
StackDump:
0x00154180
0x00307D58
0x0030754C
0x00165C3B
0x00154180
0x00005555
0x00000000
0x003075F1
0x00160D89
0x00000000
0x00000005
0x00000004
0x00000004
0x002C1908
0x00160DFF
0x002C1B08
0x00000000
0x002C1AD8
0x003078F4
0x00000024
0x0000000D
==========================================================================
Exception!! Vector 0x10
Occured Time 2011:01:05 18:52:24
Task ID: 12910616
Task name: SpyTask
Exc Registers:
0x00005555
0x00307558
0xE12FF001
0x7A3A834C
0xE59F110C
0x1777CD2C
0xE5911000
0x003075F1
0x80000013
0xFF812C3C
0x002C4CB8
0xFF814114
0x00000000
0x00307538
0x002C4CC0
0x00000362
0x800000B8
StackDump:
0x00154180
0x00307D58
0x0030754C
0x00165C3B
0x00154180
0x00005555
0x00000000
0x003075F1
0x00160D89
0x00000000
0x00000005
0x00000004
0x00000004
0x002C1908
0x00160DFF
0x002C1B08
0x00000000
0x002C1AD8
0x003078F4
0x00000024
0x0000000D
==========================================================================
Do you have a link for a 103c dump ?
For 102C, the edge overlay and zebra still do not work.When you sent my your camera.h section for the SD940 the other day, it did not contain the two additional defines that Bernd R had give me.
When you sent my your camera.h section for the SD940 the other day, it did not contain the two additional defines that Bernd R had give me.
Are you still using your camera.h or did you switch to the one from the Beta source code release ?
Only issues I noticed was that the battery meter is not working (fixed at 0%)
Only issues I noticed was that the battery meter is not working (fixed at 0%)
Battery meter works properly on my camera if I set the max and min voltage values in the OSD setup menu - try 4.25 and 3.5.
Then again, in a camera with such a small image sensor, most people would probably want the default Canon behavior for lower noise (i.e. the "Auto" setting).I hear you. Looking at the barrel distortion in my DNG images, I also wonder why RAW seems attractive on a small camera to people ? Sure, on a $1500 DSLR with a good 50mm lens there is something to be said for not having jpeg compression. But I must be missing something - what does it get me with something like the SD940?
Crashing problem in LUA fixed - mykbd_task() was running out of stack space. Changed 1.03c version to use same startup code as 1.02c as that code created the task with a 4X larger stack.Thanks for the hint! Had the same problem on SD4000 (hooked mykbd_task() without increased stack size).
void taskHook(context_t **context) {
...
if(!_strcmp(tcb->name, "PhySw")) tcb->entry = (void*)mykbd_task; // cause crash with large scripts because we hook task without increased stack size
...
}
Thanks for the hint! Had the same problem on SD4000 (hooked mykbd_task() without increased stack size).This community development thing seems to work. I know my productivity went way up once I had enough of a port to start this thread and starting getting help from the more senior members of the forum.
Then again, in a camera with such a small image sensor, most people would probably want the default Canon behavior for lower noise (i.e. the "Auto" setting).I hear you. Looking at the barrel distortion in my DNG images, I also wonder why RAW seems attractive on a small camera to people ? Sure, on a $1500 DSLR with a good 50mm lens there is something to be said for not having jpeg compression. But I must be missing something - what does it get me with something like the SD940?
Yes, that seems to be the problem with the battery display. For some reason, the values in get_vbatt_min() and get_vbatt_max() are wrong.AFAIK SD940 has a 3,6V or 3,7V battery. If battery is fully charged it will be around 4,1V.
long get_vbatt_min()
{
return 4550; // 4550 = 4.5V
}
long get_vbatt_max()
{
return 5150; // 5150= 5.1V
}
obviously does not fit if battery max voltage is 4,1V ;)// Battery min. Voltage
long get_vbatt_min() {
return 3200; // ToDo: use real value, this is just a guess
}
// Battery max. Voltage
long get_vbatt_max() {
return 4100; // ToDo: use real value, this is just a guess
}
Also keep in mind you can override this in your settings, and if you do this, you won't see any subsequent changes from the code.Yes, if code is changed one need to reset chdk settings or delete chdk config to see changes in chdk.
But I must be missing something - what does it get me with something like the SD940?
I'd also like to change the default setup so that CCHDK.CFG is tuned to the camera (OSD colors, screen position etc). What's the best way to do that ?
In conf.c, function conf_init_defaults() can load specific values for each camera.
Just to be sure, you are talking about the conf.c in the trunk1031/core directory ?
SystemEventInit failed
GetLogToFile return -1
A/ROMLOG.LOG not writtenI'm REALLY new to this, so excuse me. Did I just mess up something or is it not working yet?
Tried the romlog.lua too and it gave me this:Use the latest version of the script, from a "full build" on the autobuild or http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/romlog.lua (http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/romlog.lua)Code: [Select]SystemEventInit failedI'm REALLY new to this, so excuse me. Did I just mess up something or is it not working yet?
GetLogToFile return -1
A/ROMLOG.LOG not written
Use the latest version of the script, from a "full build" on the autobuild or http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/romlog.lua (http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/romlog.lua)Alright, that worked, thanks.
Same with set_zoom(0) but then it zooms out a tiny bit before crashing.The SD940 port has not had a lot of testing. However, see http://chdk.setepontos.com/index.php?topic=5855.msg59663#msg59663 (http://chdk.setepontos.com/index.php?topic=5855.msg59663#msg59663) up above - might be related. I'll upload a build with that change made tonight - let's see what happens ?
Yeah, I figured it probably isn't that stable yet, I just wasn't sure if my problem was with CHDK in general or this particular port.Here's my latest build with the fix for set_control_event() mentioned earlier.
max_zoom = get_zoom_steps() - 1get_zoom_steps() returns 11 so max_zoom is 10, but apparently the range that works is only 0-8 and anything above that will result in a crash. Set_zoom_speed() will crash too, though I'm not sure if that's even available in this camera(?).So, yeah, I think that fixed it, unless you can make set_zoom_speed() somehow available.
To clarify, did things start working with the new version I sent you that did not work with the Beta4 release ?
Yes, the set_zoom did not work at all and now works as long as you don't go out of range.
Anything new about 103b? =)RoninTech was working on the 1.03B version but we have not heard anything in weeks here.
From the reply I got the impression I was on the wrong track.
Hi.
OK. It's been a long time. I created a dump of 1.02c long, long ago for CHDK, with the intention to port - and fell off the face of the planet after that. Back now.
Had a play with the current (beta 5) port a few mins ago - and have found hang on load scenario under the 1.02c version. Had a good look to see if they were resource fork related issues on the SD card (from a Mac OS X host), but it wasn't the case. Tried applying with card-tricks, and same scenario. Crashes shortly after CHDK loading screen.
Do you have any debug flags or "got this far then core dumped" style utilities I could run, then send you outputs of?
Cheers.
z
Wonder what I am doing wrong. There is no region dependency or model type dependency, is there?This has not been observed in any of the other models CHDK has supported. I would say it is extremely unlikely.
I.e - I'm running PAL-E region GM1.02C fw, with an IXUS 120IS branded variant - not the _940.
OK. Next step is to try an entirely different SD card. Currently attempting to use a fairly pricey SD-HC card. Will swap to a low density SD and see if it makes a difference...I have to confess to only having ever used a spare el-cheapo 2G card I had laying around. Have not tested to see if there are any partition issues with cards larger than 4G that I see in some of the other threads. Hopefully not.
If multipartition works, it shouldn't depend on card size.OK. Next step is to try an entirely different SD card. Currently attempting to use a fairly pricey SD-HC card. Will swap to a low density SD and see if it makes a difference...I have to confess to only having ever used a spare el-cheapo 2G card I had laying around. Have not tested to see if there are any partition issues with cards larger than 4G that I see in some of the other threads. Hopefully not.
If multipartition works, it shouldn't depend on card size.That makes sense - I guess I could test multiparitions on a 2G or 4G cae okay. Still, not short of other things to test so I'm thinking that as long as I didn't mess up the FAT32 stuff in boot.c it should be okay unless i hear otherwise.
int raw_savefile() {
int ret = 0;
int fd, m=(mode_get()&MODE_SHOOTING_MASK);
static struct utimbuf t;
static int br_counter;
...1. It took a good 6 or 7 seconds with orange LED polling/processing to write out the image.This seems a bit long for non-DNG. Are you using a decent, recently formatted SD card ?
2. After the write out has complete, seemingly, camera is locked/hung and needs power cycle to be responsive again.How have you determined that the raw is corrupt ? Most programs will NOT be able to open a CHDK raw from a new camera without modification. They are just a sensor dump, not the CRW format suggested by the extension. The correct way to determine if the raw is corrupt is to examine the data and see whether it contains the image you attempted to capture.
3. Every RAW acquired appears to be corrupt, so far.
Seemed pretty spartan and lean, and started to wonder if it was related to the little processor in the IXUS 120 IS never really being geared to push ~18MB of captured CCD Data around that quickly, and this is more a function of the camera's hardware limitations than that of unoptimised code?Unlikely. Users of other firmwares have reported obtaining valid images without crashing. This is not something that is likely to change between firmware versions.
bash-3.2# /Users/z/Downloads/usr/bin/dcraw -i -v CRW_1795.CRW
Cannot decode file CRW_1795.CRW
Tried dcraw and Picasa 3 to open, as allegedly, Picasa 3 supports CHDK RAW now. Invalid image messages and things like this from dcraw:There is no such thing as supporting "CHDK raw", because "CHDK raw" is not a format, it's just a dump of the sensor data. Some programs (like dcraw and picasa) support raw files from some CHDK cameras. If the sensor layout is different, then any program will need new code or configuration to support it.
That works for me in 102C.Do you still have a crashing problem with RAW - presumably after it saves a valid DNG image ?
That works for me in 102C.Do you still have a crashing problem with RAW - presumably after it saves a valid DNG image ?
Tried to gen a DNG, and found the badpixels LUA script didn't seem to execute correctly, and again, would lock the camera up...
I think I also saw some recent posts from reyalp that the LUA version is going away, replaced by a Basic script ?No, it's built into the raw menu now. However, if the script failed, this is likely to fail as well.
@ dvip: in the raw menu, I see no "Create badpixel.bin". Am I looking in the wrong place. Rough menu navigation went like this:This is a very recent addition to the CHDK trunk. It's likely the build you are using is from sources without this.
This is a very recent addition to the CHDK trunk. It's likely the build you are using is from sources without this.Sounds like its time for a Beta6 release.
With regard to the raw crashing on 102C, the address of SetFileTimeStamp should be 0xff835640.Made the change for 1.02C. It was already set to that address in the 1.03C.
Also, you should uncomment the "fixes overrides behavior at short shutter press" lines. Overrides did not consistently work for me unless I did that.Made the change for 1.02C. It was already set to that way in the 1.03C.
You should also check if capt_seq_hook_set_nr is ever called. I don't think it is. I moved the call to another location where it gets called, but it still does not seem to work. If we can't get that working, we should probably remove it from the code for now to avoid corrupting memory if nrflag is written to.I guess I need to study what this is supposed to do. Does the call to wait_until_remote_button_is_released() immediately before the call to capt_seq_hook_set_nr() suggest its only called when you are using a USB remote to trigger the shutter ?
Also, did you get the zebra and edge overlay to work on 103c? It has never drawn properly on 102c.Zebra and edge overlay work perfectly in the 1.03C. I posted a couple of changes a while back :
Does anyone actually have the 1.03C fw dumped, and can I flash my 1.02C unit to 1.03C reliably?I think it would be a safe guess that I have the 1.03C fw dumped :)
Does anyone actually have the 1.03C fw dumped, and can I flash my 1.02C unit to 1.03C reliably? Sort of surprised I cannot find an official Canon flasher.Canon does not generally issue firmware updates, except for major, customer visible problems.
I'm assuming units shipped with 1.02C have no hardware differentiators to the units shipped with 1.03C. This is a safe assumption?It's not a safe assumption. I'd say it's very likely the hardware is the same (or similar enough not to matter), but hardware changes in a production run aren't out of the question.
Beta 6 now ready. Updated to source tree version 1050 with version 1.02C patched for correct RAW operation.
http://www.zshare.net/download/85479062ffe6454f/ (http://www.zshare.net/download/85479062ffe6454f/) SD940 1.02c Beta6
http://www.zshare.net/download/85479097d4f68177/ (http://www.zshare.net/download/85479097d4f68177/) SD940 1.03c Beta6
http://www.zshare.net/download/8547912719543f2f/ (http://www.zshare.net/download/8547912719543f2f/) SD940 trunk1050 Source Code Beta6
http://www.zshare.net/download/85479728d805f58d/ (http://www.zshare.net/download/85479728d805f58d/) firmware dump of version 1.03C
What needs to be dealt with next?
2) ND filter (neutral density filter) apparently moves in and out of light path to control exposure range as SD940 has no iris control. Does this work yet ?
I've used the ND filter in 1.03C Beta 3 through Beta 5. At least it worked in those.
1) USB remote - I need to build something to test this so I don't know if it works yet.You can do minimal testing by plugging and unplugging into a PC with remote enabled ;)
You can do minimal testing by plugging and unplugging into a PC with remote enabled ;)Interesting. I tried that with Remote Enabled. When I connect the USB cable it does the equivalent of a "half press". Is that normal and if so is there an easy way to make it complete the process ?
When I connect the USB cable it does the equivalent of a "half press". Is that normal and if so is there an easy way to make it complete the process ?--> http://chdk.wikia.com/wiki/CHDK_User_Manual#Remote_Parameters (http://chdk.wikia.com/wiki/CHDK_User_Manual#Remote_Parameters)
--> http://chdk.wikia.com/wiki/CHDK_User_Manual#Remote_Parameters (http://chdk.wikia.com/wiki/CHDK_User_Manual#Remote_Parameters)Thanks - that explains how to use the remote in "non-scripted mode". I was trying to work with this :
I just had a problem starting it via "firmware update" but now it works with the autostart readonly card modus, which is fine.
i would like to use my cam for timelapse movies so i need delay-shooting. i tried the "7upLight.bas" script and it works well until the script wants to power down the display. i think the script crashed at this action.
so thats one issue i "found" and the battery-display always says "0%"... but i think that was mentioned earlier.
You need a ps.fi2 file built for your specific release to use the firmware update method. These are typically not included - search this forum for more details.Ok thanks but i think its more comfortable with the autostart-mode!
Can't find that script on the forum or wiki. I find that its a major problem trying to find scripts here - lots out there but hard to search. Please post a link or cut&paste it into a code box here ?i found the script in a german beta-release of the ixus100. i also attached the script to this post. or do you have a "timelapse"-script which works with power down the display?
Works for me but for some reason you might have to reset the limits in the OSD -> Battery menu. Set the Max voltage to 4500 and the MIN voltage to 3000 and see what that does ?Ok thanks, will try it out when i'm home!
Is there any hope for 102c catching up with the progress of 103c any time soon?As far as I know, the 102c is current with the 103c. Download available here http://chdk.setepontos.com/index.php?topic=5855 (http://chdk.setepontos.com/index.php?topic=5855)
(Or maybe a tutorial on how to help porting it to 102c? CS student here.)
As far as I know, the 102c is current with the 103c. Download available here http://chdk.setepontos.com/index.php?topic=5855 (http://chdk.setepontos.com/index.php?topic=5855)
There might still be a small offset problem with some of the display modes - I have not seen anything from waldo about that in a while.
Are you sure about this? The Beta Testing Status Page as referenced in the first thread post does not reflect a match up. Quite the opposite. The column for 102c is pretty much empty (=>"no") while 103c is almost entirely filled with "yes". Or am I mistaken?I see the confusion now.
I see the confusion now.That clears up things. Thanks :P
Some time ago I added the Beta Testing Status page to track what works and doesn't work. What mostly doesn't work is the Beta Testing Status page itself - nobody seems really interested in keeping it up to date (unfortunately including me). I guess I should probably delete it.
Meanwhile, in answer to your question, yes, I'm sure the 102c and 103c version are pretty much in the same state.
EDIT : @bugemenot - if you have a 102c - how about loading up Beta 6, testing and updating the Beta Testing Status page for that firmware ?
Could you upload both firmwares again, the zshare links have expired ?
Turned out to be a 1.03b... which seems like a worst case scenario to me.
Since I haven't a clue how to port or even analyse firmware, I'm wondering if I should sell the camera.
Will it be difficult to make chdk available for 1.03b? I've read that RoninTech tried to do it, but unfortunately he's to busy now to continue.
Well, the good news is that I'm working with another rookie developer who has started on the 1.03b for his camera. Should be a lot faster for him than it was for me as he's working from an existing port and getting coaching and encouragement from me. If he gets stuck and I get the time I'll probably do some of the port too.
So no guarantees but I would not sell that camera just yet ?
Hi there, I own a SD940 with 1.03b firmware and would like to contribute to the port. I need some guiding/mentoring though, can anyone help?Take a look at these pages :
Yesterday I've even tried the file for 1.03c and 1.02c because I was so curious. :)
At least the AF light turned on.
We have your ixus120 versions integrated into CHDK-DE based on this patch file (http://chdk.setepontos.com/index.php?topic=650.msg60921#msg60921). Thanks for your great job.Thanks - feels really good to see this. It has been a long learning curve and way more work than I ever expected over last 5 months. But its been a lot of fun too. Still more to do but I'm happy that it will bring most of CHDK to IXUS120 SD940 owners as is.
Added in the trunk, great job waterwings. Sorry for the delay getting to this, 12+ hour days in the day job don't leave much time for CHDK...Thanks reyalp. I wasn't in any hurry - the SD940 doesn't exactly have a huge user base and I would expect that most of those have probably found the porting thread on the forum. Still, nice to see it move into a "release" state. Like everything else in CHDK, getting a release accepetd has been a lot of reading forums, trying things and seeing what works.
CAM_HAS_VIDEO_BUTTON is defined in camera.h. Does this camera actually have a distinct video button to start recording video, separate from the shutter button ? On some cameras the DP button can be programmed for this, but these generally don't get CAM_HAS_VIDEO_BUTTON, and it looks like sd940 doesn't have a DP button anyway.As you noticed, no video button or jog dial - this is a really small camera. The code is hang-overs from my early attempts at a port where I started with the SD980 Beta source. Thanks for the clean-up.
CAM_HAS_JOGDIAL is undefined (which looks correct from the pictures), but some jogdial functions are present in plaform/.../lib.c I've removed them.
draw_filled_rect in lib.c is probably a bad thing.I agree but its the best I've been able to do and it seems to work pretty well. Posted about it at http://chdk.setepontos.com/index.php?topic=5857.msg57276#msg57276 (http://chdk.setepontos.com/index.php?topic=5857.msg57276#msg57276). Since then I've tried to improve it by looking at many other camera dumps - most recently for the SD4000 and S90 - and while I can match the stubs, I can't get their version of draw_filled rect() to work. Curiously, Waldo ended up with a very similiar hack for his original port of the SD940 1.02c too. I'm open to suggestions here.
vid_get_viewport_live_fb not being implemented means MD will be slow.I'll add that to my "to do" list - really looking forward to lightening pictures this summer.
In the modemap:Completely untested I confess - another c&p from the SD980. I've not been too interested in video in general.
{ MODE_VIDEO_STD, 2603 }, // video standby
{ MODE_VIDEO_STD, 3622 }, // video in progress
Usually MODE_VIDEO_STD is when the mode is selected, not recording in progress. How recording in progress is handled isn't well defined and actually needs some reworking in CHDK in general :[
I added a few things to notes.txt, please check if they are correct.Notes.txt looks correct - thanks again. Did not understand the comment about fast MD not being implemented but your note about vid_get_viewport_live_fb explains that now.
How impossible would it be to flash my 1.03B to 1.03C. I couldn't find if this was asked before, but I'm genuinely curious. I mean, I'm sure it's possible, but not as straight forward as putting CHDK on an SD card.The general consensus on this forum is that its not possible to update firmware on Canon cameras. Or, at least, Canon does not make firmware updates available, you can't just move a firmware dump from one camera to another and nobody has been willing to risk "bricking" their camera experimenting with a CHDK version that does it.
I would gladly like to assist in development in anyway that I can, but I wondered..Even done any assembler programming? I have some fairly straight forward code conversion projects that need doing - take the 1.03C code, find the equivalent code in a 1.03b dump and create the 1.03b version of the file. I'll get to it eventually but additional experienced hands would be better.
The general consensus on this forum is that its not possible to update firmware on Canon cameras.
Even done any assembler programming?
There is a misunderstanding. It is certainly possible to update Canon P&S cameras, Canon simply doesn't release firmware updates for them most of the time.The general consensus on this forum is that its not possible to update firmware on Canon cameras.
That's interesting, as with Canon's DSLR line you can update firmware just fine. Simply copying the .fir file to the SD card gets the job done. I wonder if it's possible to add this functionality within CHDK, by examining the firmware dump of a DSLR.
vid_get_viewport_live_fb not being implemented means MD will be slow.
I know D10 is correct, but it's quite a bit older so I don't know how much help it will be.vid_get_viewport_live_fb not being implemented means MD will be slow.
@reyalp : any suggestions for DIGIC IV cameras that have this implemented well? I've looked at the G12 and S90 code and its either not implemented or too different than anything I can find in the SD940 code.
TIA
do anyone knows if anybody is working on firmware 1.01a ?I don't believe anyone is currently working on this version. However, now that we have releases for two firmware versions and a third on the way, the process is much easier than back when your camera was released and no port existed. Maybe other owners of cameras with firmware 1.01a will come forward to help product a port.
I know D10 is correct, but it's quite a bit older so I don't know how much help it will be.
Watching the value with misc debug values should show addresses that look like framebuffer addresses, alternating. If the are, and the logic is the same as known working cameras, that may be good enough.I know D10 is correct, but it's quite a bit older so I don't know how much help it will be.
@reyalp : Found some good code matches for the SD940 in the SD780 and SD980 ports so I now have a version of vid_get_viewport_live_fb() that build and seems to run.
Any suggestions of how to test and validate that its working for fast MD ?
I now have a version of vid_get_viewport_live_fb() that build and seems to run.
In my ports, I try to put some clues / reminders of how I found in the comments.I now have a version of vid_get_viewport_live_fb() that build and seems to run.
So, with other builds such as the IXUS105, what exactly are we looking for ?
Any distinctive text strings or unusual assembler code ?
There are some MD test tools floating around as well: http://chdk.wikia.com/wiki/Software (http://chdk.wikia.com/wiki/Software)First pass testing with the web based tool gives me 180 - 200 mSec response times. I loaded the previous version of the port (without my new vid_get_viewport_live_fb() code) and I also get 180-200 mSec response.
Any idea how fast vid_get_viewport_live_fb() should be ?IMO you should get something around 80-120ms when working with two raw buffer addresses (SD870 sample (http://tools.assembla.com/chdk/browser/trunk/platform/ixus860_sd870/sub/100c/lib.c#L23)), most cameras are in this range (e.g. my SD400, SD870 & SX10). Using only one buffer address slows done MD speed...
IMO you should get something around 80-120ms when working with two raw buffer addressesIf I read the code from the SD870 and D10 correctly, there are three possible buffer address returned by *vid_get_viewport_live_fb() - not two ?
Yes.IMO you should get something around 80-120ms when working with two raw buffer addressesIf I read the code from the SD870 and D10 correctly, there are three possible buffer address returned by *vid_get_viewport_live_fb() - not two ?
Also, in my port vid_get_viewport_fb() returns the same address as vid_get_viewport_live_fb()'s first buffer. Does that seem right ?Yes, one of the buffers should be the same.
EDIT : I guess what I should have asked for is a link or short explanation of the different buffers that CHDK hooks into ??I don't think such a thing exists. It would be good to have.
Yes, one of the buffers should be the same.Thanks - I think I've got vid_get_viewport_live_fb() solved then. I'll update the two firmware beta files on this thread and submit a patch file for the trunk.
I actually started writing a page about frame buffers a long time ago. I've posted my work-in-progress here: http://chdk.wikia.com/wiki/Frame_buffers (http://chdk.wikia.com/wiki/Frame_buffers)Thanks ! That was actually helpful - even in its current state. Did you link it to the "For Developers" wiki page ?
Don't think it will help you, but maybe someone wants to add too it ;)
Any distinctive text strings or unusual assembler code ?I looked at four different DigicIV cameras and was able to convince myself that I had found the same routine in all four - but they were all different code (register usage, additional subroutines in places) so it was just reading the general flow. One of the two necessary variables (pointer to the viewport base address?) is used in four places while other (the index value) shows up 65 times in the code. Not much help I'm afraid.
In my ports, I try to put some clues / reminders of how I found in the comments.I've started documenting the ROM address (for stubs_min.S and lib.c) where I've found things in the dump for my camera. At least that way somebody can compare my camera's code to their camera to try and find something similar in their camera.
CHDK Porting for the IXUS120-SD940 Update
1.03B owners :
Still working on that. Its moving ahead - you are not forgotten.
1) do the <ALT> mode menus draw correctly when you change from a long menu to a shorter menu ?This works for me.
2) do the Motion Detection (MD) scripts work ?Sometimes it takes a picture, sometimes not. I'll test it later in detail...
Early Alpha release of 1.03B firmware. Logo displays and menus work. Other features not enabled just yet.
ixus120_sd940-103b-0.9.9-1067-full.zip - 0.51MB (http://www.zshare.net/download/87333005e9c140a9/)
Mirror dl location: http://www.box.net/shared/208h7icjry (http://www.box.net/shared/208h7icjry)I guess I should switch to box.net - no annoying pause before downloading.
Early Alpha release of 1.03B firmware by Rulen (http://chdk.setepontos.com/index.php?action=profile;u=15772). Logo displays and menus work. Other features not enabled just yet.
ixus120_sd940-103b-0.9.9-1067-full.zip - 0.51MB (http://www.zshare.net/download/87333005e9c140a9/)
First beta release of 1.03B firmware by Rulen (http://chdk.setepontos.com/index.php?action=profile;u=15772). All functions now implemented - testing and feedback needed.
zShare :
ixus120_sd940-103b-0.9.9-1067-full.zip - 0.51MB (http://www.zshare.net/download/877450297c33a752/)
I can access the script menu but it shuts down randomly.Do the menu's dissappear in shooting mode or playback mode or both ? My nemisis RefreshPhysicalScreen() might be coming back to haunt me still.
Correction: I think it doesn't shut down but isn't visible anymore. When you press a button it appears again.
Battery icon in the middle shows 0% all the time.Easy one - you just need to calibrate the camera by changing the battery min and max voltage using the OSD parameters menu to go to the Battery menu. Rulen report good results setting Battery MAX Voltage (mV) to 4200 and Battery MIN Voltage (mV) to 3200.
but i cannot find a way to make the camera use the big partition to save media on, so it doesn't have the space to save raw files..Hmmm - I can get lots of raw files on a 2G card so I assume you have partiioned your card into a small FAT16 partition and a larger FAT32 parition ?
At what point does the SD940 not match what you see there - I don't have a big SD card so have not tried this. I guess that I really need to buy a big card and try it out.You don't need a big card, you can partition a smaller card with a FAT16 and FAT32 partition to test.
You don't need a big card, you can partition a smaller card with a FAT16 and FAT32 partition to test.Yea, I know - we talked about that a while back - http://chdk.setepontos.com/index.php?topic=5855.msg59916#msg59916 (http://chdk.setepontos.com/index.php?topic=5855.msg59916#msg59916).
i solved it using cardtricks on a pc to ake my 4Gb card bootable.. thanks for the info!!
anyway as everything looks like it's working, still on my 103b raw files aren't saved, it just saves jpgs..RAW is tricky - lots of post on this forum about that too. I'll dig some up but what immediately comes to mind is that RAW is saved in a different folder on the SD card and you can't see them over a USB cable from your computer. You need to plug the card into a card reader on your PC and navigate the folders. All that assumes you have enabled RAW via the CHDK menus on your camera of coarse.
no, it's not that..
i always connect a card reader and import through Lightroom with it looking into all subfolders..
but i also checked card space and every folder manually and it simply doesn't write them down.. it looks..
it gives on screen info about how many raws i could save on the camera..
i'll check that out tomorrow, i think..
thanks for every effort btw!
Tommaso
Have you tried looking using the CHDK file browser ? (misc->file browser in the CHDK menu)This is a really good way to see if the camera is writing RAW images. If the CHDK browser can see them. PC software makes no difference here.
If you are using multiple partitions (rather than just formatting 4gb fat32) then you would need to swap partitions to the large one for to see the raws on your card reader.reyalp - do you mean 4gb fat16 ("rather than just formatting 4gb fat32)" - I think the bootable CHDK partition needs to be FAT16 ?
You should be able to tell if raws are being saved, because the save time will be much longer.Oh yea - no mistaking when the camera is storing RAW files !
no, it's not that..
Tommaso
reyalp - do you mean 4gb fat16 ("rather than just formatting 4gb fat32)" - I think the bootable CHDK partition needs to be FAT16 ?Yes
Do the menu's dissappear in shooting mode or playback mode or both ? My nemisis RefreshPhysicalScreen() might be coming back to haunt me still.
Ok, so I tried it with a bootable 2GB SD. The splash screen graphic is the full graphic, unlike when it is loaded on a partitioned 8GB SDHC which only displays the text in the box, without the camera dials graphic above it.The splash screen logo is read from a file on the SD card. If it was in the wrong partition on your 8G card that might explain why you can't see it.
"Firm update..." option is available after autoboot with 2GB SD, unlike with 8GB SDHC.Where do you see a "Firm update.." option ? The Canon menus or the CHDK menus ?
Persistent splash menu when 'show memory info' is activated is still present.Works properly in the 1.03C release. I'll add it to the things still to fix on the 1.03B.
Playback mode works just fine. The menu only flickers or disappears in both of the shooting modes.Confirmed on the 1.03C too. I'll take a look later this week but we might have to live with pressing a key to make the menu appear again. Its still there - just overwritten.
When I enter the regular menu in shooting mode the chdk menu works fine, too.
There are only problems when there's a "live image" in the background.
Confirmed on the 1.03C too. I'll take a look later this week but we might have to live with pressing a key to make the menu appear again. Its still there - just overwritten.This sounds like normal CHDK behavior to me.
Where do you see a "Firm update.." option ? The Canon menus or the CHDK menus ?It's present in the Canon menu when I autoboot from the 2GB card, but not when I autoboot the partitioned 8GB SDHC. Maybe it's something to do with the CDHK folder not in the right partition as well?
This sounds like normal CHDK behavior to me.I was wondering about that. RefreshPhysicalScreen() doesn't really do a lock/unlock thing that would tell the Canon f/w not to overwrite the screen. Nor does anything else in CHDK from what I can tell.
Are the visual settings (color) supposed to be set separately in the shoot modes and in playback/canon menu modes? Default loads a white/green scheme in the shoot modes, and a white/gray scheme in playback/canon menu.Different colors in playback and shoot modes are normal. Some time I'll pick something less ugly and make them the same for both playback and shoot modes. It just has not been a high priority.
Is the built-in bracketing supposed to work yet? How about zooming during video capture? They both don't work.Rulen is still plugging away at getting thinks working. With so much to test, you are discovering things that he has not tried yet. Both functions work on the 1.03C version so its just a matter of time to see which addresses he did not quite get right.
Is the OSD supposed to vanish when you press the FUNC.SET key during a shoot mode? It doesn't.Doesn't do that on the 1.03C either. Is it supposed to ? (In my case, it actually launches a Canon BASIC file that I have laying around on my SD card.)
Different colors in playback and shoot modes are normal. Some time I'll pick something less ugly and make them the same for both playback and shoot modes. It just has not been a high priority.
oh I see. FYI, the color tables for playback and shoot modes are different; that is 0x44 is gray in one mode, and green in another.True. There was a big discussion about that a couple of times here in the forum - you can probably search for it. The best way to handle it is to pick colors from the first two rows in the color map. Those are the same in both modes.
What I made:The card must also be CHDK-bootable --> http://chdk.wikia.com/wiki/Bootable_SD_card (http://chdk.wikia.com/wiki/Bootable_SD_card)
1. Downloaded zip file and unpacked it
2. Formated SDHC card to one FAT16 partition and made it bootable
3. Putted files from zip file to card (DISKBOOT.BIN, vers.req, CHDK)
4. Turned SDHC card to LOCKED
5. Power on camera with this card.
Nothing happens
(the file PS.FI2 is essential for manual loading)Note that the .zip archive for 1.03b does not contain the PS.FI2 file.
Is chdk working on 1.03b?Yes - people are successfully booting the 1.03b firmware using a bootable card and the card lock switch. There is a lot of detail on the wiki and this forum on how to do that so I won't try to repeat it here.
The card must also be CHDK-bootableThat's it. I missed
echo -n BOOTDISK | dd bs=1 count=8 seek=64 of=/dev/sdx1 Now it works like a charm. So you have another happy CHDK user. Thanks all of you for help and hard work :)
Now it works like a charm. So you have another happy CHDK user. Thanks all of you for help and hard work :)Just be aware that the 1.03B version is still very new and mostly untested. Many things will not work quite correctly yet.
3. Is not opening the lens and flashing the autofocus LED after pressing the power button intentional?To open the lens on power up, press and hold the power button on top (rather than just briefly press it).
but unfortunately, my camera doesn't even give me the option to upgrade the firmware.
my camera doesn't even give me the option to upgrade the firmware.Your SD card MUST be LOCKED! Only then you will see "updated firmware" but for now you can only use CHDK with 1.03B by bootable SD.
You SD card MUST be LOCKED! Only then you will see "updated firmware"This is not true on most (if not all ?) CHDK cameras. The card must be for autoboot. Firm update does not care.
This is not true on most (if not all ?) CHDK cameras. The card must be for autoboot. Firm update does not care.Have You test it with Ixus 120IS fw.1.03B? On my, only in this situation I can use firm update (Play mode). I spend some time looking for it.
I was momentarily hopeful when I found this thread for 1.03B, but unfortunately, my camera doesn't even give me the option to upgrade the firmware.You don't need to change or upgrade the firmware on your camera. If you have a camera with 1.03B firmware installed, use the 1.03B beta version of CHDK for the IXUS120-SD940
You won't be able to find the upgrade firmware option because the PS.FI2 file is not present in the zip archive for 1.03b beta port. You have to make your <4GB SD card bootable, and the easiest way is to use cardtricks.Actually, you cannot upgrade or change the firmware on your IXUS120-S940 at all. Canon does not provide support for this and CHDK does not change the firmware on the cameras it operates on.
it does boot, even if at times menus don't stay on screen and just disappear..Menus will disappear in shooting mode - this is apparently normal with CHDK. The menu is still there, but the real time image buffer has overwritten it. Pressing the up or down key will bring it back.
anything else i could check? trying to make myself as useful as possible...From a previous post :
Is the built-in bracketing supposed to work yet? How about zooming during video capture? They both don't work.
I downloaded the latest version for the 1.02 yesterday and gave it a brief try.@brakar : do you mean 1.02C ? Waldo had reported scripting working with that version. Did you try both LUA and BASIC scripts ? Some of the default ones actually don't do much - a simple script that take pictures in a loop with a time delay might be an interesting test - I'll post something like that if you can't find / write it yourself.
zebra is ok, but NDfilter,flash,ev,overrides are not changing camera's behavior..I've been comparing the stubs_entry_2.S files between the three firmware versions using a dissassembly utility that I've been working on. I have found some differences that need to be fixed but need a little more time to understand them. Should have another release ready later this week / weekend depending on what else I need to get done.
The other BASIC-scrips I have bin testing for remote control of the camera (input 5V into the cameras usb), are however still not working.
I think I've mentioned this before, but you can use your PC usb cable to test the remote code, just plug and unplug it... as long as remote is enabled, the camera won't got into ptp mode.The other BASIC-scrips I have bin testing for remote control of the camera (input 5V into the cameras usb), are however still not working.
Thanks brakar - always nice to have a clear problem description! I can look into it - its not something I have tested because I have not taken the time to build a remote switch. However, its something I have wanted to try out so I'll move it to the top of the priority list - right behind getting the 1.03b firmware working,.
My apologies to the 1.03B firmware owners. This is not a great way to debug software but its all I can do for you as I don't have a camera with that firmware.No problem, I'm thankful for your work.
The scripts doesn't work very well.What firmware version are you using ? This is one of the issues we are currently trying to fix with the 1.03B version of the firmware. Scripts work well with the other firmware versions.
If i start a intervall script, the camera just take one picture.User rulen reports this is now working using the beta 3 release !! :D
The "enable symbols" option still doesn't remain selected after you restart the camera.Curious - it seems to "stick" in whatever state I leave it with the 1.03C firmware version. Tried various combinations of changing state and powering off/on and can't fool it.
The "enable symbols" option still doesn't remain selected after you restart the camera. But CDHK starts very quickly!
Strangely, I wasn't able to reproduce this on d10. TestedThe "enable symbols" option still doesn't remain selected after you restart the camera. But CDHK starts very quickly!
Did you use 'Reset Files' under the 'Visual Settings' menu?
If so this sets the symbol font file to no file selected so the symbols are disabled each time you restart.
Go into visual settings and reselect the icon_10.rbf symbol file then re-enable the symbols under the OSD settings.
Phil.
Did you use 'Reset Files' under the 'Visual Settings' menu?Strangely, I wasn't able to reproduce this on d10. Tested
If so this sets the symbol font file to no file selected so the symbols are disabled each time you restart.
Go into visual settings and reselect the icon_10.rbf symbol file then re-enable the symbols under the OSD settings.
Phil.
- reset files
- leave alt menu
- reboot camera, symbols are off
- enable symbols, symbols appear
Strangely, I wasn't able to reproduce this on d10. Tested
- reset files
- leave alt menu
- reboot camera, symbols are off
- enable symbols, symbols appear
i solved it using cardtricks on a pc to ake my 4Gb card bootable.. thanks for the info!!EDIT: so are you using a single paritiion now ? if so - dual partiitions on the SD940 are still a TBD
However, pressing the 'play' button to turn on the camera in playback mode makes the canon startup screen to be displayed, then the camera shuts off (automatically as if it crashed). (Pressing the power button initially had this same effect,but I could not reproduce it after a couple of power on/off cycles, and the camera started normally).
EDIT: The behavior is sporadic; sometimes it starts in playback mode fine, other times it just shuts down.
hi guys, any new rumors bout a possible chdk for ixus 120 with 1.01A firmware?
I will confess here to not having looked at any of these functions. Its quite possible that the SD940 port has not set this up correctly and I'm not even sure where that is supposed to happen. I'm not even sure what they are supposed to do - is there a link where I could take a look ?
If I get_prop 0,x which is camera mode - it always reads 0 no matter where the switches are set. I switched to x=get_mode - and I always get 1 no matter how the switches are set.
You are probably the first person to try this out on this port. Frustrating as that might be, I thank you for looking at it and reporting your findings here.
My question is - should code like this run in this beta or do I have some problem specific to my setup?
How would you edit the user menu? The User Manual says to press the "+/- button or the equivalent button on the camera" when User Menu is set to edit. The half-shoot button doesn't do it either.Another good question about something I have not tried myself. Worked through the User Manual and discovered the same thing you did - the +/- button moves the cursor up and down the menu and apparently cannot be used to select a menu item to add to the User Menu. If nobody offers a clarification here, I'll wade through the code to figure out what it is trying to do.
If nobody offers a clarification here, I'll wade through the code to figure out what it is trying to do.
FYI the half-shoot button is used in some cameras, i think Maybe the SD400 used that when I had it. http://chdk.wikia.com/wiki/User_menu (http://chdk.wikia.com/wiki/User_menu) ...but it doesn't work on the SD940. does that have to be assigned or something?Most likely something else I missed. I'll look at it when I get a few moments in the next couple of days. Thanks for the "heads-up".
Another beta release for firmware 1.03B - but this time I think I might have it fixed !
http://www.box.net/shared/40ymdqx4og (http://www.box.net/shared/40ymdqx4og)
Looking for testing help and feedback as usual - I don't have a camera with this firmware version.
If I get_prop 0,x which is camera mode - it always reads 0 no matter where the switches are set.Did a little research and here's what I've found so far. There are four different versions of the camera properties you are trying to access - it changes with camera model. In the CHDK source code, these are defined as CAM_PROPSET 1, 2, 3 or 4. Your SD400 used propset 1 but the SD940 uses propset 3 (this may or may not be right). With propset 1, you use get_prop 0 x to read the camera mode dial - with propset 3 the correct value appears to be get_prop 49 x .
@title set mode test
@param a param
@default a 49
:TT
sleep 500
get_prop a x
print "param=",a, "value=",x
goto "TT"FYI the half-shoot button is used in some cameras, i think Maybe the SD400 used that when I had it.I tried it on my camera using the half-shoot button and can confirm that it does not add entries to the user menu. I took a look at the code in gui.c and confirmed that half-shoot is what the code is looking for. I'll wade through debugging when I have a little more time.
I tried it on my camera using the half-shoot button and can confirm that it does not add entries to the user menu. I took a look at the code in gui.c and confirmed that half-shoot is what the code is looking for. I'll wade through debugging when I have a little more time.
Another beta release for firmware 1.03B - but this time I think I might have it fixed !Turns out we do have it fixed!
I have version ixus120_sd940-103b-0.9.9-1114-full-rev3 successfully installed on my 103b. Now I am ready for tests. There seems to be quite a lot what I could test but maybe you're interested in some dedicated tests of certain things. Let me know!I would suggest just using the CHDK features that interest you the most and let us know how that goes? Bug reports are good - reports of success are good too. Right now it would be nice to know which scripts (BASIC and/or LUA) are working well with the SD940 if you want to search this forum and the wiki for things to try out ?
Did a little research and here's what I've found so far. There are four different versions of the camera properties you are trying to access - it changes with camera model. In the CHDK source code, these are defined as CAM_PROPSET 1, 2, 3 or 4. Your SD400 used propset 1 but the SD940 uses propset 3 (this may or may not be right). With propset 1, you use get_prop 0 x to read the camera mode dial - with propset 3 the correct value appears to be get_prop 49 x .Note that if you use lua, you can use the propcase module and refer to propcases by name, without worrying about which propset your camera has. Of course, the ports propset still has to be defined correctly in camera.h
Hello, are you planning port CHDK for firmware GM1.01A? Thank you!@zawin : As suggested in my earlier post on this forum, [http://chdk.setepontos.com/index.php?topic=5855.msg64039#msg64039 (http://chdk.setepontos.com/index.php?topic=5855.msg64039#msg64039)] I will port for the 1.01A if I can get at least two users who will give me a real email address and commit to testing early releases of the port. A port is a lot of work but part of my motivation is to test some porting utilities that I have been working on that should make it easier. However, as I do not have that camera firmware, I have no way to test the results and will not do that much work without a couple of committed "helpers".
whenever CHDK starts up on the 940, it is in playback mode. Is that a feature of this camera (I can put it in record mode by hitting shutter to stop script, Alt to drop chdk menu, half press to go to record, alt to bring chdk back and full shutter to restart script.)Normal behavior for a CHDK camera. The playback button gets you playback mode. A short press on the ON/OFF button gets you playback mode. Hold the ON/OFF button for more than one second and you are in shooting mode.
I've also found that holding the power button for a second when turning on, brings out the lens.
Perhaps newer cameras work that way. My sd400's power on in record mode. I can live with it.Understood, and CHDK source code is available at http://tools.assembla.com/svn/chdk/ (http://tools.assembla.com/svn/chdk/) for anytime you would like to change things to more closely suit your taste. The SD940 is my only CHDK camera so my frame of reference is limited by what I have been able to get working.
I ran setmode.lua and got...Cool - except that I have no idea what it means or what you want to know.
Looks like most stuff worked and some stuff didn't ? Would be nice to better understand how the whole mode thing works - I suspect its a question of mapping what the Digic IV cameras want / return rather than any bug in the SD940 port. If you can work through this and provide an updated cross reference for current cameras that would be really good.The script at http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/setmode.lua (http://tools.assembla.com/chdk/browser/trunk/CHDK/SCRIPTS/TEST/setmode.lua)
TRY P 2 | P 2 32772 STL 1110ms OK
TRY TV 3 | P 2 32772 STL 1010ms CHANGE FAIL req 3 got 2
TRY AV 4 | P 2 32772 STL 970ms CHANGE FAIL req 4 got 2
TRY M 5 | P 2 32772 STL 1100ms CHANGE FAIL req 5 got 2
TRY PORTRAIT 6 | P 2 32772 STL 890ms CHANGE FAIL req 6 got 2
TRY LANDSCAPE 8 | P 2 32772 STL 970ms CHANGE FAIL req 8 got 2
TRY VIDEO_STD 9 | P 2 32772 STL 970ms CHANGE FAIL req 9 got 2
TRY STITCH 15 | STITCH 15 33290 STL 990ms OK
So, P was OK. Tv through VIDEO_STD were not. Tv, Av and M wouldn't be expected to exist on a camera without a real aperture, so they shouldn't be in the modemap. The other failures might not exist, or have the wrong canon mode value in the modemap.are you planning port CHDK for firmware GM1.01A? Thank you!Try this :
in shoot mode the optic doesent come out.Hold down the On/Off button on the top of the camera (the shoot button) for 2 seconds and the camera should startup in shooting mode. Or half-press the shutter release button when in playback mode and the camera should switch to shooting mode.
New version of CHDK for IXUS120 SD940 1.01A firmware now available at :
http://www.box.net/shared/mpb4zru12e (http://www.box.net/shared/mpb4zru12e)
All code complete, everything should now work but this is completely untested (as I do not have a camera with this firmware version).
raw shoots but photoshop desent open it even if i rename file in rafI don't think I checked the raw buffer address - it might be using the address from the 1.03C. I'll look at it tonight.
ps, the chdk menu disappear sometimes from screen but when i press down or up in joypad it appear, seems have some problem when original canon firmware draw something on screen like focus point etcThis has been reported here before and my camera does the same thing as well. Apparently this is normal behavior for CHDK and a know limitation with no fix.
li still have problem with raw, now i can open in photoshop but the pic seems to be taken with a fish eye.If you search this forum for discussions about CHDK RAW format, you will discover that Canon cameras do a lot of optical correction to each image before storing the image as a JPG on the card. What you get with the CHDK RAW is the just that - the raw image before any processing. The fish eye you are seeing is worst when you have the zoom set for wide angle - you can obtain software that will let you correct that.
ps: the chdk battery level indicator is always at 0% the canon one works fineYou need to go into the setup menu and enter min & max values for the battery gage.
If you search this forum for discussions about CHDK RAW format, you will discover that Canon cameras do a lot of optical correction to each image before storing the image as a JPG on the card. What you get with the CHDK RAW is the just that - the raw image before any processing. The fish eye you are seeing is worst when you have the zoom set for wide angle - you can obtain software that will let you correct that.
Take a look at : http://chdk.setepontos.com/index.php?topic=6146 (http://chdk.setepontos.com/index.php?topic=6146)
What's the best way of dumping a 120IS?Hands down, this is what you need:
I'm a C# developer with some past assembler and C background. I don't have much spare time these days but when I do I would happily get involved.Well, here's something I just happen to be working on. The paint is still wet but you get the idea. If it seems interesting and you want a prerelease copy them PM me and we can go from there :
Another beta release for firmware 1.03B - but this time I think I might have it fixed !Turns out we do have it fixed!I have version ixus120_sd940-103b-0.9.9-1114-full-rev3 successfully installed on my 103b. Now I am ready for tests. There seems to be quite a lot what I could test but maybe you're interested in some dedicated tests of certain things. Let me know!I would suggest just using the CHDK features that interest you the most and let us know how that goes? Bug reports are good - reports of success are good too. Right now it would be nice to know which scripts (BASIC and/or LUA) are working well with the SD940 if you want to search this forum and the wiki for things to try out ?
Battery is always showing up as 0%, red, and empty.See if this works :
Using the latest release (downloaded today 0.9.9.1176).
Firmware is 1.01A.
is there a fix for this/are you planning on fixing it?
Battery is always showing up as 0%, red, and empty.Just FWIW, you can adjust the battery thresholds yourself in the menu. This also means that if the defaults are changed in code, you one see the change without resetting the CHDK configuration file.
Using the latest release (downloaded today 0.9.9.1176).
Firmware is 1.01A.
is there a fix for this/are you planning on fixing it?
The new build (1177) still doesnt fix it.Read the post from reyalp above .. I think the new build does fix it, but you already have the old default values in your CCHDK.CFG file.
I manually changed the values to 4250 max and 3500 min, and now it works, but how do i know that that is an acurate reading?
So from reading reyalp's post, i assume that i should charge my battery full, see what the voltage is then, set that as the max, and then let it drain all the way down, and get the value of the battery just before it dies, and then use that as the min value?That ensures that it uses the full scale, but as waterwingz says, it can vary between battery, on temperature etc. The whole thing is a crude approximation.
Another small issue, in video mode, the remaining time and space thingie only updates every 15-20 seconds, whereas on the older builds, it was updating live...I don't believe that anything has changed in the SD940 specific code that would cause this so it would have to be something in the core. I wonder if other cameras are seeing this.
Another small issue, in video mode, the remaining time and space thingie only updates every 15-20 seconds, whereas on the older builds, it was updating live...I don't believe that anything has changed in the SD940 specific code that would cause this so it would have to be something in the core. I wonder if other cameras are seeing this.
I realised it was because the refresh rate was set to 20 (seconds).Ah yes - PEBKAC. That happens sometimes.
Now i'm having a different problem: Vieo stops after 10 -20 seconds, with no script running, and an empty 4GB memory card!!Just tried this with builds 1176 and 1184 using an SD940 with firmware 1.03C. Shot a couple of boring 5 minute videos using the default Canon and CHDK settings. Everything worked fine on record and playback. So it seems that :
Im downgrading to an older build, because i need zoom in video for a trip tommorow, and i cant video if it cuts out every ten secs.
Recording may stop even if the maximum clip length has not been reached on
some memory cards. SD Speed Class 4 or higher memory cards are recommended.
Optical zoom and change quality in video were both selected.Tried changing the Video Mode to "Quality" per your comment. If I then set the Video Quality to anything higher than 80, the video times out as you have reported and the higher the setting, the faster the time out. But this is on a "no name" el-cheapo SD card so I'm pretty sure it does meet Class 4 specs as mentioned in whim's post.
I'm using a 4GB Class 2 Micros SD in an adapter.
Also, force manula flash does not work, both in Auto mode and P. All the other overrides work fine. I tried with power set to 0, 1 and 2, and even turned on the canon flash, but that just resutled in a normal flash firing. According to the users guide, the flash should still fire even if in the canon interface flash is turned off.I'll take a look at this. I remember testing this during the initial release test and confirming that it was working but that was quite a while ago so who knows ?
Regarding using a Class 2, i've never had a problem with it (till now), and its SanDisk, so it does work.Its not really a problem with the card - its just that class 2 cards are slow. When you try for higher quality video, there is more data to write to the card every second and a class 2 card runs out of speed at some point. The SD card class tells you how fast the camera can write data to the card. If the camera trys to record data faster than it can write it out to the card, then recording will stop. A class 2 card is half the speed of a class 4 card, a third the speed of a class 6 car and a fifth the speed of a class 10 card.
Just downloaded 1187. Any major fixes?Not sure how to answer that - it depends on which version you are using previously. Probably not though - lots of the trunk updates are for small changes or fixes to other cameras. Occasionally something important changes though so getting a new version from time to time is a good idea. Or you could register for to be notified with each update if you like receiving a lot of email.
Also, i was reading the users manual the other day, and i saw that some cameras let you take photos while videoing. Is it possible with the 120?Not that I know of, but I didn't realize it was possible with any of the cameras either. (manual ? read the user's manual ? :-[ )
My plan is to creat a 3d SDM rig with the two cameras so a 1.00e port would be awesome.Here you go - at least I think so as I don't have a 1.00e camera to test this with.
Also, force manula flash does not work, both in Auto mode and P. All the other overrides work fine. I tried with power set to 0, 1 and 2, and even turned on the canon flash, but that just resutled in a normal flash firing. According to the users guide, the flash should still fire even if in the canon interface flash is turned off.I'll take a look at this. I remember testing this during the initial release test and confirming that it was working but that was quite a while ago so who knows ?
Here you go - at least I think so as I don't have a 1.00e camera to test this with.Great stuff Waterwingz. I should be able to test monday evening. Many Thanks.
IXUS120SD940 Firmware 1.00e (http://www.box.net/shared/do8bncz7mg)
Not that I know of, but I didn't realize it was possible with any of the cameras either. (manual ? read the user's manual ? :-[ )
Manual flash works in 1.03b.
rem test usb
while 1
do
a = get_usb_power
until a > 0
print "take a picture"
shoot
sleep 500
wend
end
@title Simple Intervalometer
@param i Interval (Secs)
@default i 5
@param d Delay before start (Secs)
@default d 2
sleep 1000*d
while 1
shoot
sleep i*1000
wend
end
When it actuates, the camera acts as though the shutter release button has been pushed halfway down, causing the camera to focus rather than actually taking a picture. Is there any hope of making this device work so that it remotely triggers a shot rather than just the focusing mechanism?Take a look at the four postings in this thread starting at : http://chdk.setepontos.com/index.php?topic=5855.msg60212#msg60212 (http://chdk.setepontos.com/index.php?topic=5855.msg60212#msg60212). Should point you in the right direction..
So by plugging the USB cable in and out twice I can get the shutter to fire in non-scripted mode if I get the timing right. Good enough for me - I'm going to declare the remote feature working on this port.
The intervalometer works great, but unfortunately my setup appears to fail the click-pan test. I have the remote enabled, I load the script, and while in <Alt> mode I switch on the power to the click-pan, wait, and I don't see anything happening. Am I missing something? If it does not generate a double pulse, how does it take a picture ?The IXUS120 is not listed on the click-pan web site. But as far as I know, the code it uses for USB remote is identical to that used by all the supported cameras. Which makes me wonder how it works with something like the IXUS100 for example ?
Am i missing something, or is this the first time that someone has successfully loaded CHDK to a more-than-4gb-card-without-partitions...? (or was it always possible?)Its because you are using the "firmware update" method of loading rather then using a bootable SD card.
From http://www.gentles.ltd.uk/gentwire/chdk_sdm/index.htm (http://www.gentles.ltd.uk/gentwire/chdk_sdm/index.htm) it says "Note that the latest builds of CHDK and SDM have this functionality built in - i.e. You don't need a script to take a picture" There are also some sample scripts listed there - did you try any of them ?I hadn't seen that page with the sample scripts until you mentioned it, but I then did try the Remoteshutter.bas script with no luck. The camera doesn't appear to respond in any way to the click-pan's signal when running the script (i.e. not even initiate the half-press focusing behavior, which it does when only running CHDK with Remote enabled and no script).
The camera doesn't appear to respond in any way to the click-pan's signal when running the script (i.e. not even initiate the half-press focusing behavior, which it does when only running CHDK with Remote enabled and no script).Interesting. I'll take a look (or at least put it on my list of 3 or 4 things that don't seem quite right with the IXUS120). No promises but this is one of the things I want to see work with the camera so I should have an answer in the next week or two (other work permitting).
Yep, I had found earlier that the IXUS120 isn't listed on the click-pan website when I started troubleshooting. Rather than give up at that point I thought I'd try asking to see if anyone could point to a work-around, but looks like my best bet will be to use an intervalometer in place of remote shutter firing.
Here you go - at least I think so as I don't have a 1.00e camera to test this with.Great stuff Waterwingz. I should be able to test monday evening. Many Thanks.
IXUS120SD940 Firmware 1.00e (http://www.box.net/shared/do8bncz7mg)
Wow that works a treat! Nice one.
I Haven't used it in anger yet but it seems the same as my 1.03b. Did your porting app work smoothly?
During the integration of the firmware version 100.e in CHDK-DE I noticed the following difference:I wonder if this is related to the recent changes in the findsig.c tool ?
Your adress: NSTUB(SetFileTimeStamp, 0xff9257d0)
My adress: NSTUB(SetFileTimeStamp, 0xff835640)
Can you please check this difference.
During the integration of the firmware version 100.e in CHDK-DE I noticed the following difference:I wonder if this is related to the recent changes in the findsig.c tool ?
Your adress: NSTUB(SetFileTimeStamp, 0xff9257d0)
My adress: NSTUB(SetFileTimeStamp, 0xff835640)
Can you please check this difference.
The NSTUB values in stubs_entry.S are found automatically and your version automatically found a different value than my version. In fact, your version found the correct value - in my version I had to override the value of SetFileTImeStamp via an entry in stubs_entry_2.S with the correct 0xff835640 value.
The resulting executable code will be the same in both our versions. The reason for the difference probably needs some attention.
Any updates on the manual flash not working on 1.01A?If there were updates, they would have been posted here.
FWIW FlashParams is for parameters stored in onboard flash memory (see http://chdk.wikia.com/wiki/Params (http://chdk.wikia.com/wiki/Params) ) not the electronic strobe light.Okay - wondered about that.
So do you know if there is anything at all in stubs_entry.S, stubs_entry_2.S, stubs_min.S, lib.c, boot.c, capt_seq.c or capture_seq.c that might be worth looking at to explain why manual flash control does not seem to work on 1 out of 5 firmware versions for the SD940.Not offhand, I haven't played with the manual flash stuff. I'd start by looking through the functions is uses and looking for differences in the functions and variables it uses from stubs.
Before I obsess and spend way to much time on this, Can someone verify bracketing actually works on the the SD940 with 1.00E
(Extra Photo Operations / Bracketing in continuous mode / TV bracketing value [] )
the fact that you got CHDK loaded and mostly running is a big deal.Waterwingz,
Any updates on the manual flash not working on 1.01A?@Maron : Please post the exact steps you follow when setting this up in CHDK and I will take a look.
What I'm trying to do now is get it to use infinity focus mode (without CHDK, when the camera is in program mode, pressing 'right' will give you the option between macro, normal and infinity). But I can't seem to find any way of accessing this through script.I've wondered that myself but I have not found a way either. However, I did not look too hard.
--[[\
@title BalloonTimer - by Nathan White
@param k InitDelay --initial delay length
@default k 300
@param x InitVid -- launch video length (liftoff)
@default x 300
@param a LoopDelay -- Delay before moving into the loop
@default a 600
@param b Pduration --Duration of stills cycle
@default b 300
@param c Pinterval -- Time between stills
@default c 5
@param d Vduration -- Duration of video
@default d 120
@param e backlight: 0=Off 1=On
default e 0
@param p printf --toggle print to screen
@default p 0
@param l logf --toggle print to log file
@default l 1
@param n Pmode: 1=Auto 2=Program 8=Landscape
@default n 2
--]]
--This is a script designed for a near-space balloon launch using our SD940 IS
--It alternatives between video and stills, and turns the backlight off to conserver battery
--Would like to set it to infinity focus mode, but havent found a way yet
--Hopefully "landscape" mode will favour long focal distances.
capmode=require("capmode")
props = require("propcase")
logname = "A/BalloonTimer.log"
log = io.open(logname,"wb")
if not log then
error("Failed to Open Log\n")
end
function printf(...)
if (p == 1) then --if we're writing to the screen
print(string.format(...))
end
if (l == 1) then --if we're writing to the log
log:write(string.format(...))
log:close()
log = io.open(logname,"ab")
end
end
function log_rec_change(rec) --switch between shoot and playback mode
local status_str, sleep_count
if rec then
printf("Leaving Playback Mode\n")
else
printf("Entering Playback Mode\n")
end
set_record(rec)
sleep_count = 0
while sleep_count < 100 do -- wait up to 10 seconds for function change
if (rec and get_mode()) or not (rec or get_mode()) then
break
end
sleep(100)
sleep_count = sleep_count + 1
end
if (rec and get_mode()) or not (rec or get_mode()) then
printf("Left Playback Mode, Success!\n")
elseif not (rec or get_mode()) then
printf("Entered Playback Mode, Success!\n")
else
printf("Display Mode Not Set!\n")
end
end
function change_mode(mCode) --change shooting mode (auto/program/video/etc)
local status, sleep_count, id
if mCode == "Picture" then --translate mCode into id value
id = n --photo mode
else
id = 9 --video
end
if not get_mode() then
log_rec_change(true)
end
printf("Changing to " .. mCode .. " mode\n")
status = capmode.set(id)
if status then
sleep_count = 0
while sleep_count < 100 do --wait up to 10 seconds for mode to change
if (capmode.get() == id) then
printf("Changed to " .. mCode .. " mode\n")
break
end
sleep(100)
sleep_count = sleep_count + 1
end
if capmode.get() ~= id then
printf("Could not change to " .. mCode .. " mode\n")
end
else
printf("Error setting " .. mCode .. " mode\n")
end
end
function delay_cycle(duration) --delay
printf("Delaying for " .. duration .. " seconds\n")
if e == 0 then --if we're turning the backlight off
set_backlight(0)
end
sleep(duration*1000)
end
function pic_cycle(duration, interval) --take photos for a specified duration with a specified interval between each
local numShots = duration/interval
local i = 0
change_mode("Picture")
sleep(1000)
printf("Will now shoot " .. numShots .. " shots\n")
while i < numShots do
printf("Shot " .. i+1 .. " of " .. numShots .. " \n")
shoot()
i = i + 1
if e == 0 then --if we're turning the backlight off (after shoot, it automatically turns back on)
set_backlight(0)
end
sleep(interval*1000)
end
end
function vid_cycle(duration) --take video for a specified duration
local sleep_count, status
change_mode("Video")
printf("Will now shoot " .. duration .. " seconds of video\n")
if e == 0 then --if we're turning the backlight off
set_backlight(0)
end
press("shoot_full")
sleep(300)
release("shoot_full")
sleep(duration*1000)
press("shoot_full")
sleep(300)
release("shoot_full")
while (get_movie_status == 4) do --needed this because sometimes it wouldnt stop recording without pressing the button a few times (weird)
printf("Video Termination Required")
sleep(1000)
if (get_movie_status == 4) then
press("shoot_full")
sleep(300)
release("shoot_full")
end
end
printf("Video Done\n")
end
--program runs as follows:
-- delay initially (once we press the shutter button because we need a few more minutes to setup the launch)
-- take a video of the launch (lift-off!)
-- transition into a cycle of video and photos until the battery runs out.
printf("***\n")
printf("** BEGIN **\n")
log_rec_change(true)
printf("***\n")
printf("** INITIAL DELAY **\n")
delay_cycle(k)
printf("***\n")
printf("** INITIAL LAUNCH VIDEO **\n")
vid_cycle(x)
printf("***\n")
printf("** VID/STILL CYCLE **\n")
local t = 1
while 0 < 1 do --loop forever
printf("Cycle " .. t .. " and counting\n")
delay_cycle(a)
pic_cycle(b, c)
sleep(5000)
vid_cycle(d)
t = t + 1
printf(" \n")
end
You may be able to set the focus mode propcase.What I'm trying to do now is get it to use infinity focus mode (without CHDK, when the camera is in program mode, pressing 'right' will give you the option between macro, normal and infinity). But I can't seem to find any way of accessing this through script.I've wondered that myself but I have not found a way either. However, I did not look too hard.
Using build 1196.Any updates on the manual flash not working on 1.01A?@Maron : Please post the exact steps you follow when setting this up in CHDK and I will take a look.
<snip>Okay - using your sequence, the flash does not fire in manual mode for me either.
Turn off canon flash.
<snip>
Can someone verify bracketing actually works on the the SD940 with 1.00E
(Extra Photo Operations / Bracketing in continuous mode / TV bracketing value [] )
Hi there. I have a 1.00E and a 1.03B. I can confirm that bracketing does not work on the 1.00E and does work on the 1.03B in I think it's something more fundamental because I can't get interval timers working either.Three questions :
Three questions :
1) Do you have the latest builds from the autobuild server on both cameras ?
2) Does the script you tried work on the 1.03B but not the 1.00E ? Or not work on both cameras ?
3) Tell me more about interval timers ? Do you mean the custom timer in the Canon menu or something in CHDK ?
TIA
Basically the script will bomb out after a shoot is issued.hmmm ... tried the script on my 1.03c. The second shoot never happens but the script does terminate.
rem Test Shooting2
@title Shoot Test
print "started - sleeping 2 seconds"
sleep 2000
print "sleep over, about to shoot..."
shoot
print "shot once, gonna sleep 2 seconds again"
sleep 2000
print "slept again, about to shoot again..."
shoot
print "shot again, gonna sleep 2 seconds again"
sleep 2000If you have any pointers I could look at tweaking the port.Not even sure where to begin. I'll play a bit and get back to you here.
hmmm ... tried the script on my 1.03c. The second shoot never happens but the script does terminate.Interesting. Both yours and mine work fine on the 1.03b but bomb out on the 1.00e. I wonder if the 1.03c has a similar problem with shoot? did your script execute both shoots on 1.03c? Have you tried ultraintervalometer by the way? a handy script to have.
I wonder if the 1.03c has a similar problem with shoot? did your script execute both shoots on 1.03c?I got both shoots on the 1.03c with my script. With your script I only got the first shoot.
I wonder if the 1.03c has a similar problem with shoot? did your script execute both shoots on 1.03c?I got both shoots on the 1.03c with my script. With your script I only got the first shoot.
Gives me some things to look into anyway.
Interesting. Both yours and mine work fine on the 1.03b but bomb out on the 1.00e.Using the new sigfinder code from philmoz, I've updated all versions of the IXUS120-SD940. Then now have new sig values for write & rename - basically "wrapper" functions higher up in the call sequence that seem to do a litttle more checking before acting. The 100e has several fixes to its stubs_min.S file so let's see if that fixed the uBasic script issues.
PARAM_FILE_COUNTER is used in generic/shooting.c - remember this is *included* from the platform shooting.c. Same for EXPOSURE_COUNTER. I highly recommend http://tools.tortoisesvn.net/grepWin.html (http://tools.tortoisesvn.net/grepWin.html) for finding stuff like this.That's what I was using. I didn't notice the shooting.c in the generic directory though - I did a scan of the grepWin output and missed it while ignored all the files named shooting.c in the camera specific directories. I'll refrain from comments about the naming conventions ....
I've done the same thing ....PARAM_FILE_COUNTER is used in generic/shooting.c - remember this is *included* from the platform shooting.c. Same for EXPOSURE_COUNTER. I highly recommend http://tools.tortoisesvn.net/grepWin.html (http://tools.tortoisesvn.net/grepWin.html) for finding stuff like this.That's what I was using. I didn't notice the shooting.c in the generic directory though - I did a scan of the grepWin output and missed it while ignored all the files named shooting.c in the camera specific directories. I'll refrain from comments about the naming conventions ....
fl_tbl[]
CF_EFL
Just installed on my new SD940 IS and loads up beautifully. One question, I don't see Time Lapse in the build. Am I missing something or is there a script I can download somewhere? And help would be greatly appreciated.Its done with scripts. Search this forum and the wiki for Intervalometer. You should get lots of ideas like this http://chdk.wikia.com/wiki/UBASIC/Scripts:_Ultra_Intervalometer (http://chdk.wikia.com/wiki/UBASIC/Scripts:_Ultra_Intervalometer)
Last Question, I promise. Got the Intervalometer working real nicely. Now, is there a script I can run to get the screen on the back to turn off immediately after it shoots? The default power saver only goes as low as 10 seconds, I'm hoping for a 3-5. What might I search under?Questions are good. I'd start by searching the forum for "backlight". Lots of posts - not sure if there is a magic answer, or at least a magic answer that works for the SD940. Report back here if you work it out ?
The 100e has several fixes to its stubs_min.S file so let's see if that fixed the uBasic script issues.
UPDATE : these changes now available through the autobuild server.
Just tried 100e-0.9.9-1218 from the build server but no luck. I've tried script with P mode, Auto mode, single shot and continuous drive.So does the script I posted here work ? http://chdk.setepontos.com/index.php?topic=5855.msg69243#msg69243 (http://chdk.setepontos.com/index.php?topic=5855.msg69243#msg69243)
Where does it stop ? After the first shoot ? What is the last thing printed on the display ?
Does it actually capture an image and save that to the SD card? Also, it probably doesn't matter but do you have RAW disabled?Where does it stop ? After the first shoot ? What is the last thing printed on the display ?
After the first shot. So "sleep over, about to shoot..." is the last message you see.
Does it actually capture an image and save that to the SD card? Also, it probably doesn't matter but do you have RAW disabled?Hi Waterwingz.
I think I may give my 1.00e to my brother in law as he needs a quality pocket camera. If I do i'll be getting another CHDKable sd940 in the future and finally getting that stereo rig working.I just rebuilt the 1.00e with the newest sigfinder2 and checked its output. Unfortunately, it didn't find anything suspicious. So whatever is causing this is going to be a lot of work to fix.
Thanks for all your work on this. My 1.03b works like a charm.You're welcome. Although, the 1.03b version is the only one that I did not actually port myself :)
You have to actually start the camera in "Play" mode. This means you start the camera by pressing the "Play" [>] button on the back of the camera - not the On/Off button on the top of the camera.
Here's what I have on my SD940 1.02C port:This link ist to old and the dump on http://www.box.net/chdk (http://www.box.net/chdk) is to small for finsig2.
Binaries (1.02C):
http://www.zshare.net/download/8383614653354d3f/ (http://www.zshare.net/download/8383614653354d3f/)
I think a wrong stubs_entry.S is the bug on CHDK-DE trunk for version 102c.
rudi : what bug are you seeing ? and what stubs_entry.S is possibly wrong ? does it match what's in the international versions - I thought that I checked all of them using the new sigfinder ...At first, thanks a lot for dump. The new sigfinder works fine.
NSTUB(GetZoomLensCurrentPoint ,0xffa3a7a8) //old
NSTUB(GetZoomLensCurrentPoint ,0xff93a7a8) //new
or
DEF(task_MovieRecord ,0xffa3d648) //old
DEF(task_MovieRecord ,0xff93d648) //newremark:
I generated with finsig2 new stubs_entry.S files for all DryOS Cams on chdkde-trunk and cleaned-up all related stubs_entry_2.S files (Changeset 763 (http://my-trac.assembla.com/chdkde/changeset/763)).
rudi
When I start the CHDK script from VP-systems (http://vp-systems.eu/download/cr1sdm.bas (http://vp-systems.eu/download/cr1sdm.bas)) The camera freezes a while and crashes a few seconds later (black screen).Okay, here's the main problem - this script is written for SDM (http://stereo.jpn.org/eng/sdm/index.htm) not CHDK. SDM forked away from CHDK several years ago and created its own version, adding special commands to uBasic (amongst other differences).
@title set zoom test
s=0
p=0
print "started ..."
sleep 2000
s=get_zoom_steps
print "zoom steps = ", s
sleep 2000
p=get_zoom
print "zoom position = ", p
sleep 2000
set_zoom_speed 10
print "zoom speed set to 10"
sleep 2000
set_zoom 5
print "zoom to 5"
sleep 2000
end
Thanks a lot, this seemed to fix it!Unfortunately, not really. I've started another thread to deal with it :
How do i know if the ixus120 supports bootable card?Good question. First of all - it does. Although as a camera release prior to 2011, it will only boot from a FAT16 partition (i.e one 4G or less). So you will need to use the dual partition scheme if you want to autoboot from a larger card. More details here : http://chdk.wikia.com/wiki/Prepare_your_SD_card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
Hi waterwingz, thanks for the quick reply, I have found this page on the Wiki explaining about a program that I can use to create the partitions.That page should work for you - those are the instructions I used when I was porting the IXUS120 (check out the page history to see who created it)
http://chdk.wikia.com/wiki/Using_SDMinste_to_Create_Dual_Partition_SD_cards (http://chdk.wikia.com/wiki/Using_SDMinste_to_Create_Dual_Partition_SD_cards)
I will follow all 31 steps tonight and hopeully get it working!I'd still recommend using STICK instead.
On the forum, this has been written and it applies to me.... looks like the 30 steps are going to be needed!! If the below has been fixed please let me know!To save me some searching, can you please a link to where you got the quote?
I proceeded with the SDMinste program and successfully navigated through the steps to the end, and have successfully made it so the camera boots on then loads the firmware. However it says the memory card is full.If you've done things correctly, you should end up with a primary partition formatted as FAT16 of about 2MB. You should also have a second partition formatted as FAT32 that uses up the rest of the card (7.999 GB). If CHDK does not see a correctly partitioned SD Card, it will just boot from the first small partition and not switch to the larger partition after booting. Which is what the "Card Full" error is telling you - its running from the first partition and thus has no space to save pictures.
What I don't understand, is that the final state of the partitions is that the main partition (FAT16) is only 2mb. It seems like I am half way there. The partitions have been created correctly. But the camera for some reason doesn't want to write to the main FAT32 partition.
I have succesfully managed to install CHDK on the IXUS 120 IS. But there is a problem. All RAW-photos comes out with pretty bad distortion, is there a way to fix this in Camera or will I have to resort to Photoshop? :(There are probably a few things you need to review :