the sx20 porting thread

Anibal Marquex

Sorry Fe50 if I press on my sx20 the SET button holding down and press Display it appears
FIRMWARE Ver. 1.0.2.0
How you say that is not the firmware version , I get your url and the explanation there is a combination of those two buttons , where I was wrong?
Anibal

Anibal Marquex

Sorry Fe50 I didnt read well. Thank you for your attention in fact after I created the file ver.req on the root of my card , I get all the information regarding my firmware version that is GM 1.02B
Tell me there is any possibility with this version to get any chdk firmware now?
Tks in advance
Anibal

saidimu

Another user with GM 1.02B firmware, waiting to help with the testing.

Mad props to neszt, reyalp, RaduP and everyone for the incredible results and effort. If there is a heaven for hackers, you guys are definitely citizens.

Much appreciated.

saidimu

JMD

Please pardon my ignorance, but how do you enable "Superfine" mode in CHDK for the SX20? I have firmware versioin 1.00F.

😳

saidimu

JMD
Please pardon my ignorance, but how do you enable "Superfine" mode in CHDK for the SX20? I have firmware versioin 1.00F.

😳

You can't yet, at least not until you install the beta CHDK version created by neszt.

JMD

Thanks,

Also, has anyone tried making the mods to the PTP interface

https://chdk.setepontos.com/d/4338

I have a working version with my SX1 and it is SO cool. Has anyone built a version of CHDK for the SX20 that can utilizes these special features in the PTP mod?

Icarus3000

Any progress on a version for firmware 1.02b? Happy to be an alpha/beta tester!

gigioz79

Everybody are waiting for THE release!😀
I'm trying CHDK with my old a620... fantastic!
Achieving raw and superfine abilities will make sx20 a perfect camera!
Can I make something to help work progress?

Thank you!

subwoffer

i cant wait for the final version!

can you please tell us about your progress? remaining of your project?

doblemazo

Hi to all, my name is Cristian, I'm electronic engineer from Argentina. It's very cool what you do here whit CHDK. I recently bought a canon sx20is, and I'd like to help with porting. I've experience on C programming, microcontrollers, pics, x86 assembler, linux, and I've an oscilloscope, but no idea of how to get a good quick start with CHDK. Can I provide some help in any way with the porting for the sx20, or it's too late?

Best regards!

Cristian

Anibal Marquex

That´s more then good it seams that soon we will be available to test CHDK for SX20IS that is a good news.

reyalp

doblemazo
Hi to all, my name is Cristian, I'm electronic engineer from Argentina. It's very cool what you do here whit CHDK. I recently bought a canon sx20is, and I'd like to help with porting. I've experience on C programming, microcontrollers, pics, x86 assembler, linux, and I've an oscilloscope, but no idea of how to get a good quick start with CHDK. Can I provide some help in any way with the porting for the sx20, or it's too late?

Best regards!

Cristian

Welcome!
See http://chdk.wikia.com/wiki/For_Developers for what you need to get started.

AK49BWL

Icarus3000
Any progress on a version for firmware 1.02b? Happy to be an alpha/beta tester!

I second this, I'm anxiously awaiting being able to use CHDK on my GM 1.02B SX20 😀

viulian

First, let me say hello to the community!

I own a Canon Sx20 1.00F firmware, which, after 5 months, developed 1 stuck pixel.

Will the beta version of the firmware offer the possibility to use badpixel file to map out bad pixels while using JPEG compression (not raw) ? I read various posts on the forum, but I'm still not clear.

I found a stuck pixel and I wouldn't care about it, however JPEG encoding 'smears' the single white pixel to neighboring pixels, making a grayish gradient patch of 5x5 px almost in the center of each photo. If the background is really dark, I also get some purple fringing correction (some horizontal purple / blue) on the location of the bad pixel. I assume it may be the purple fringing correction algorithm of the camera which believes that there's really a white spot there and tries to correct for expected color aberration, which, in fact, is missing.

Anyway, instead of waiting 1 month and 1 week to have the camera fixed by Canon (estimated time by the shop where I bought it), I want to try chdk and map that bad pixel which, I hope, will be replaced with the color of the neighboring pixels before JPEG compression is applied.

Thank you,

Later edit (to avoid double posting), I got it working!! Yey.

No dead pixel anymore even in standard JPEG encoding. I had to find a suitable show_bad.exe (which included SX20 resolution), generated the badpixel file with threshold 1024. All perfect now - no more white patch. I'm glad that with 2 hours of work (for me) I was able to save 1 and a half month of waiting for Canon to do similar action.

One thing, the camera flashes the AF lamp for a bit when chdk boots up.

viulian

Two days after playing with the firmware, and I have to give a big thank you to neszt and the people that made chdk possible.

My main issues with chdk for sx20 (1.00f firmware):
a) menu, osd, grid and games were not displayed properly, fonts were too small. Grids and games also displayed only on the left hand side of the LCD.
b) AF lamp doesn't work anymore even if in the Canon menu it is enabled. As I see AF Lamp working when chdk is 'busy' (when starting up the camera, or when running some scripts, etc); I suspect is because is used as a status indicator and possibly not available for the camera.

Anyway, I came up with fix for a which I doubt it is perfect (it modifies the gui.c file also) - but was the only quick way I could figure out how to do it.

In file [tt]camera.h[/tt]:
a) locate the defines for Sx20 (search for the string "[tt]#elif defined (CAMERA_sx20)[/tt]") and append, just before the defines for sx1:

    #undef  CAM_USES_ASPECT_CORRECTION
    #define CAM_USES_ASPECT_CORRECTION  1
    #undef  ASPECT_VIEWPORT_XCORRECTION
    #define ASPECT_VIEWPORT_XCORRECTION(x) ( ((x)<<1) )
    #undef  ASPECT_GRID_XCORRECTION
    #define ASPECT_GRID_XCORRECTION(x) ( (x) )
    #undef  ASPECT_GRID_YCORRECTION
    #define ASPECT_GRID_YCORRECTION(y) ( (y) )
    #undef  GAMES_SCREEN_WIDTH
    #define GAMES_SCREEN_WIDTH 360
    #undef  GAMES_SCREEN_HEIGHT
    #define GAMES_SCREEN_HEIGHT 240
    #undef  ASPECT_GAMES_XCORRECTION
    #define ASPECT_GAMES_XCORRECTION(x)   ( ((x)<<1) )
    #undef  ASPECT_GAMES_YCORRECTION
    #define ASPECT_GAMES_YCORRECTION(y)   ( (y) )
    #undef  ASPECT_XCORRECTION
    #define ASPECT_XCORRECTION(x)  ( ((x)<<1) )
    #undef  ASPECT_YCORRECTION
    #define ASPECT_YCORRECTION(y)  ( (y) )

b) modify file [tt]gui.c[/tt] (the one in the Sx20 git repository, not the one on chdk SVN repository):

The code below:

    #if CAM_USES_ASPECT_CORRECTION //nandoide sept-2009 
    //the different modes arises because games are designed on a 360x240 basis and are difficult to downscale to 320x240
    if (gui_mode == GUI_MODE_REVERSI || gui_mode == GUI_MODE_SOKOBAN || gui_mode == GUI_MODE_4WINS || gui_mode == GUI_MODE_MASTERMIND) {
      draw_set_environment(aspect_xcorrection_games_360, aspect_ycorrection_games_360, GAMES_SCREEN_WIDTH, GAMES_SCREEN_HEIGHT);
   } else { //default
//      draw_set_environment(NULL, NULL, SCREENX, SCREENY);
      draw_set_environment(NULL, NULL, vid_get_bitmap_screen_width(), vid_get_bitmap_screen_height());
   }
    #endif

becomes:

    #if CAM_USES_ASPECT_CORRECTION //nandoide sept-2009 
    //the different modes arises because games are designed on a 360x240 basis and are difficult to downscale to 320x240
    if (gui_mode == GUI_MODE_REVERSI || gui_mode == GUI_MODE_SOKOBAN || gui_mode == GUI_MODE_4WINS || gui_mode == GUI_MODE_MASTERMIND) {
      draw_set_environment(aspect_xcorrection_games_360, aspect_ycorrection_games_360, GAMES_SCREEN_WIDTH, GAMES_SCREEN_HEIGHT);
   } else { //default
//      draw_set_environment(NULL, NULL, SCREENX, SCREENY);
//      draw_set_environment(NULL, NULL, vid_get_bitmap_screen_width(), vid_get_bitmap_screen_height());
        draw_set_environment(aspect_xcorrection_games_360, aspect_ycorrection_games_360, GAMES_SCREEN_WIDTH, GAMES_SCREEN_HEIGHT);
   }
    #endif

(basically, on the else clause: the line with draw_set_environment is commented and the one used for the games is added).
I could have replaced the whole ifdef with that single line, but this way the changes are more visible for the community.

I've tested and main menu, grids, menu and osd look correct now:

Now everything feels much more comfortable 😀

reyalp

Nice work.

viulian
b) AF lamp doesn't work anymore even if in the Canon menu it is enabled. As I see AF Lamp working when chdk is 'busy' (when starting up the camera, or when running some scripts, etc); I suspect is because is used as a status indicator and possibly not available for the camera.

You should find another LED to use as the CHDK debug LED. Usually we use the blue "direct print" one. Not sure if SX20 has an this or something similar. Using the AF led is very bad, probably better to not use an LED at all for builds that you actually plan to use for shooting.

viulian

Wow, thanks 😀 I didn't know there is a notion of a debug led - thanks for clearing that up! It makes sense now.

I will read more around to see how to proceed. Basically, I didn't see any blue led (but on the other hand I never printed anything from the camera). There is one RED led that blinks fast when camera usually writes to the card (or reads), and a 2 color led (GREEN / ORANGE) on the Power on button - which is green when the camera starts and then becomes orange. And then there's the AF led.

I will update the post when I have more info ..

reyalp

If you look for started() and finished() in the code, that should be most of the places the debug LED is used. There may be a few places early in the boot code where the address is hard coded. You can make these noop if you want (probably with an ifdef for when you genuinely do need to debug)

The difference between the "debug" led and the normal script interface to LEDs is that the debug one writes to the MMIO address directly. This means the LED should always work (for debugging), but the rest of the canon firmware isn't aware it is being used.

viulian

Hey, thank you for the support 😀

Observations:
a) I've found the debug_led method:

void debug_led(int state)
{
    *(int*)LED_PR=state ? 0x46 : 0x44;
}

If I comment the assignment, the AF led comes back to life 😀.
I don't know if the assignment above represents writing directly to the MIMO address, but if I comment out the line, AF works again when taking photos!

b) About the menus and resize code from few posts above - I just noticed that the logo is drawn twice. Once is drawn with the resolution 720px on X axis (but because of the scaling that I activated it now appears elongated), and once is drawn again scaled correctly in the center of the screen. They appear super imposed at the same time. I hope to be able to find why is loaded twice and remove one call (or maybe is rescaling without cleaning up the former image?)

c) about he jog dial ... in play mode (when you check the photos), both the menu and the camera receive the events. A bit annoying. I noticed that in boot.c:

void taskCreateHook(int *p) {
	int i;
	p-=17;
	if (p[0]==0xFF87CD40)	p[0]=(int)capt_seq_task;
	if (p[0]==0xFF83308😎	p[0]=(int)mykbd_task;
	if (p[0]==0xFF89A8CC)	p[0]=(int)init_file_modules_task;
	// if (p[0]==0xFF85AFB0)	p[0]=(int)JogDial_task_my;
	if (p[0]==0xFF879034)	p[0]=(int)movie_record_task;
	if (p[0]==0xFF8C1440)	p[0]=(int)exp_drv_task;
}

the jog dial line appears commented out. However, it makes no difference if I uncomment it - camera software also gets the results. I assume it is commented out due to some non obvious reason. 😳

I'm off now, will continue tomorrow.

JMD

Nice work Viulian. Can you post a link to your diskboot.bin file for us that are developmental impaired?

Thanks

« Previous Page Next Page »