SD940 (IXUS120) porting thread - page 19 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 14 15 16 17 18 [19] 20 21 22 23 24 ... 55   Go Down

SD940 (IXUS120) porting thread

  • 542 Replies
  • 201293 Views
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: SD940 (IXUS120) porting thread
« Reply #180 on: 02 / January / 2011, 19:17:53 »
Advertisements
Quote from: waldo on 02 / January / 2011, 17:37:10
While you're at it, you can make it refocus in video mode:

Got it.  Had to also add to stubs_min.S for the 103C :
    DEF(some_flag_for_af_scan, 0x673C)          // @FF940EDC

You don't like the flashing orange LED ? But that's my favorite part of the whole hack.  When I'm testing, it gives me some indication that the spytask is still running.   However,  I concede that others will find it confusing and, as its hacked into trunk/core/main.c I guess it really does have to go. 
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: SD940 (IXUS120) porting thread
« Reply #181 on: 02 / January / 2011, 22:51:22 »
Posted BETA 3 release tonight.

Source :  http://www.zshare.net/download/84686420220f9dab/
102c : http://www.zshare.net/download/8468650332642eb9/
103c : http://www.zshare.net/download/846864602fe7d2b7/

Major Changes :

1) Grids and edge overlay scaled correctly for SD940 screen ( were slightly compressed to the left )
2) Memory leak in 1.02c fixed - no longer runs out of memory and crashes.
3) Memory fence posts in 1.03c fixed - resulting in more free memory.
4) Will now refocus in video mode
5) Debug blinking orange LED removed.


Still Badly Broken :

1) Invalid RAW images stored
2) LUA still crashes in 1.03c (calling subroutines and possibly other issues).
 
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waldo

  • ***
  • 238
Re: SD940 (IXUS120) porting thread
« Reply #182 on: 03 / January / 2011, 13:53:52 »
Quote from: waterwingz on 02 / January / 2011, 22:51:22

Still Badly Broken :

1) Invalid RAW images stored
 

Try this:

Code: [Select]
char *hook_raw_image_addr()
{
return 0x4219D120; // @FF874840 for 102C / FF87489C for 103C
}
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: SD940 (IXUS120) porting thread
« Reply #183 on: 03 / January / 2011, 17:31:27 »
Quote from: waldo on 03 / January / 2011, 13:53:52
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 ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waldo

  • ***
  • 238
Re: SD940 (IXUS120) porting thread
« Reply #184 on: 03 / January / 2011, 17:42:44 »
Quote from: waterwingz on 03 / January / 2011, 17:31:27
Quote from: waldo on 03 / January / 2011, 13:53:52
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.
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: SD940 (IXUS120) porting thread
« Reply #185 on: 03 / January / 2011, 21:06:48 »
Quote from: waldo on 03 / January / 2011, 17:42:44
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.


@waldo :  Can you run any of the LUA test scripts in the default script folder ( badpixel.lua, llibtst.lua, tstcallf.lua ) ?
« Last Edit: 03 / January / 2011, 21:11:26 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waldo

  • ***
  • 238
Re: SD940 (IXUS120) porting thread
« Reply #186 on: 03 / January / 2011, 21:32:54 »
Quote from: waterwingz on 03 / January / 2011, 21:06:48
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.

Code: [Select]
#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

Quote
@waldo :  Can you run any of the LUA test scripts in the default script folder ( badpixel.lua, llibtst.lua, tstcallf.lua ) ?

I've tried badpixel and libtst and they both work.  libtst does not properly remove one directory, but that happens on some other cameras, too.  badpixel will not run properly until the raw buffer address is correct.
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
RAW not working on SD940 1.03c
« Reply #187 on: 03 / January / 2011, 23:11:34 »
So when you dig into raw.c,  it all comes down to this one line :

            write(fd, get_raw_image_addr(), hook_raw_size());

What confuses me is that (as explained in the wiki and forum) this simply dumps the raw pixel buffer from the camera to file. I recently tested an SD1200 camera with CHDK and its raw dump and both FSviewer and Picassa viewer could display the file.   Yet when I try to look at the raw image from my SD940 its blank.  I would have understood seeing colored snow if I had the buffer address wrong.  And when I do a hex dump of the file, its got lots of random data in every byte.  So why do the image viewers think its a blank file ?

UPDATE :  Found this in another thread, posted by reyalp :

The CHDK "raw" is a byte for byte copy of the sensor frame buffer. There is no appropriate place to put other data. The tools that do understand non-format use file size as a hint for what camera it came from.

So maybe I've got tools that understand the SD1200 dump and not the SD940 ?

@waldo :  what are you using to look at raw dumps ?
« Last Edit: 03 / January / 2011, 23:40:14 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waldo

  • ***
  • 238
Re: SD940 (IXUS120) porting thread
« Reply #188 on: 03 / January / 2011, 23:42:33 »
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.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: SD940 (IXUS120) porting thread
« Reply #189 on: 03 / January / 2011, 23:45:10 »
Quote from: waterwingz on 03 / January / 2011, 23:11:34
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'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.
Logged
Don't forget what the H stands for.
Pages: 1 ... 14 15 16 17 18 [19] 20 21 22 23 24 ... 55   Go Up
« previous next »
 

Related Topics