IXUS160/ELPH160 Porting attempt - page 2 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 50   Go Down

IXUS160/ELPH160 Porting attempt

  • 497 Replies
  • 206456 Views
*

Offline markvandenborre

  • *
  • 12
Re: IXUS160/ELPH160 Porting attempt
« Reply #10 on: 22 / April / 2015, 05:53:35 »
Advertisements
Hey adongy!

Thank you for the work, and once again sorry about the late reply.

I looked at both firmware versions, but I am not sure how/what to test.

In any case, I still see the same debugging parameters in four quadrants of the screen, and I tried to switch to record mode without any luck. Most other stuff (rmem, ls, upload, ...) in play mode seems to work.

Please let me know if there is anything I can do to help you further.

Mark
Logged
*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #11 on: 22 / April / 2015, 08:34:41 »
Thanks for testing Mark!


I will try to build some more firmwares to see if I can fix the viewport buffers, but if anyone has ideas on how to do it I'm eager to hear your input!
« Last Edit: 03 / August / 2015, 03:28:30 by adong »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: IXUS160/ELPH160 Porting attempt
« Reply #12 on: 22 / April / 2015, 14:06:06 »
Quote from: adong on 22 / April / 2015, 08:34:41
I will try to build some more firmwares to see if I can fix the viewport buffers, but if anyone has ideas on how to do it I'm eager to hear your input!
Try reading the related posts of the ixus145 porting thread (page 4). It probably won't help much though because the bitmap buffer issue hasn't been resolved and porting halted eventually.

I would still recommend dumping a bit of RAM and verifying the buffer dimensions from it.
Since your posts seem to indicate that you're doing this without the camera, make a debug build that dumps the first 8MB RAM automatically after a few seconds delay and ask a tester to upload the dump.

edit:
There is a RAM dumper facility in the CHDK core. Place the following code right before the main while loop in core/main.c (at the end of core_spytask()):
Code: [Select]
memdmp_delay = 5; // 5 sec delay before dumping
conf.memdmp_size = 8*1024*1024; // 8MB
conf.memdmp_start = 0;
schedule_memdump();
« Last Edit: 23 / April / 2015, 12:48:21 by srsa_4c »
Logged
*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #13 on: 24 / April / 2015, 08:12:06 »
Thanks for telling me! I found a lua script, and got it dumped. (Fwrite_Fut)
Logged
*

Offline markvandenborre

  • *
  • 12
Re: IXUS160/ELPH160 Porting attempt
« Reply #14 on: 25 / April / 2015, 11:04:19 »
Who can help adongy and me with a strange display issue with the ixus 160?

http://glasno.st/MVI_5653.AVI

The chdk stuff jumps between the correct place on the screen and half off the bottom of the screen. It seems to get triggered by different things:
* Canon firmware "auto mode" (permanent autofocus?) on makes it jump really fast between the two positions.
* the left rotary dial button, apart from doing what it is supposed to do, currently also triggers the jumping (see video).

Any ideas what could cause this, and how to avoid it? Feel free to ask for further information if the above was not clear!

(I'm trying to help adongy as best as I can with the port, using my *nix experience and camera. The ixus 160 currently boots, CHDK has correct screen resolution, and at least rotary dial and play keys are bound correctly. And we have basic chdkptp access to it. That's how I dumped the RAM.)
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: IXUS160/ELPH160 Porting attempt
« Reply #15 on: 25 / April / 2015, 12:18:57 »
Quote from: markvandenborre on 25 / April / 2015, 11:04:19
Who can help adongy and me with a strange display issue with the ixus 160?
There are two ways:
1) CAM_BITMAP_HEIGHT needs to be redefined in platform_camera.h (see other recent ports, it's usually 270, but I can't say for sure)
2) define DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY and implement the underlying routines in the platform lib.c (this one is preferred on the long run as it gets rid of writing both bitmap buffers)

Quote
The chdk stuff jumps between the correct place on the screen and half off the bottom of the screen. It seems to get triggered by different things:
* Canon firmware "auto mode" (permanent autofocus?) on makes it jump really fast between the two positions.
* the left rotary dial button, apart from doing what it is supposed to do, currently also triggers the jumping (see video).
You see the jumping CHDK display because:
The Canon bitmap overlay uses two buffers. One of them is visible on the screen. Certain actions which redraw the Canon overlay swap the active buffer (to avoid tearing/snow). CHDK doesn't currently use the correct bitmap buffer height, so whenever the second buffer is on screen, a mispositioned CHDK overlay is shown.

Quote
Any ideas what could cause this, and how to avoid it? Feel free to ask for further information if the above was not clear!

(I'm trying to help adongy as best as I can with the port, using my *nix experience and camera. The ixus 160 currently boots, CHDK has correct screen resolution, and at least rotary dial and play keys are bound correctly. And we have basic chdkptp access to it. That's how I dumped the RAM.)
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
Logged
*

Offline markvandenborre

  • *
  • 12
Re: IXUS160/ELPH160 Porting attempt
« Reply #16 on: 25 / April / 2015, 14:29:19 »
Quote from: srsa_4c on 25 / April / 2015, 12:18:57
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
http://glasno.st/LIVE_8MB.BIN
Note that this was (I think) without any JPEGs on the card or Canon overlay prior to dumping.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: IXUS160/ELPH160 Porting attempt
« Reply #17 on: 25 / April / 2015, 15:30:25 »
Quote from: markvandenborre on 25 / April / 2015, 14:29:19
Quote from: srsa_4c on 25 / April / 2015, 12:18:57
Can you upload an above mentioned RAM dump? For best results, keep a few JPEGs on the card and enable some Canon overlay prior to dumping.
http://glasno.st/LIVE_8MB.BIN
Thanks.
Quote
Note that this was (I think) without any JPEGs on the card or Canon overlay prior to dumping.
Confirmed, no Canon overlay is visible.
The following goes in platform_camera.h
Code: [Select]
    #undef  CAM_USES_ASPECT_CORRECTION
    #define CAM_USES_ASPECT_CORRECTION      1
    #undef CAM_BITMAP_WIDTH
    #undef CAM_BITMAP_HEIGHT
    #define CAM_BITMAP_WIDTH                720 // Actual width of bitmap screen in bytes
    #define CAM_BITMAP_HEIGHT               360 // Actual height of bitmap screen in rows... and it looks like akira's numbers were correct.
Logged
*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #18 on: 25 / April / 2015, 15:33:46 »
Thanks for this!

Can I ask you how did you find it ?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: IXUS160/ELPH160 Porting attempt
« Reply #19 on: 25 / April / 2015, 16:08:33 »
Quote from: adong on 25 / April / 2015, 15:33:46
Can I ask you how did you find it ?
I'm using a program named Hexplorer and its 'Pixel view' window (usage: set the width you expect - 720 in this case, 8 bit mode, use the main window for navigation (either go directly to the address you're suspecting or browse through the file until you find something that looks like a framebuffer). You can jump around by using the 'View' -> 'Go to address' window. Note that framebuffer addresses always appear with the 'uncached' bit set, so go to 0x711000 to find the 2 consecutive bitmap buffers. The buffers are often surrounded by uninitialized RAM content.
Hexplorer is a Win32 executable, works well under Wine. Its user interface is not very user friendly, but it's usable.
Logged
Pages: 1 [2] 3 4 5 6 7 ... 50   Go Up
« previous next »
 

Related Topics