SX60HS Porting - page 51 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 46 47 48 49 50 [51] 52 53 54 55 56 ... 92   Go Down

SX60HS Porting

  • 915 Replies
  • 377606 Views
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #500 on: 12 / September / 2016, 16:16:07 »
Advertisements
I'll make some effort to see what are likely buffers on the sx60.   To speed testing things up, it might be useful to have the ability to change the address returned by vid_get_viewport_fb_d while viewing live view.  Suggestions?
Logged
*

Offline reyalp

  • ******
  • 14125
Re: SX60HS Porting
« Reply #501 on: 12 / September / 2016, 22:28:15 »
Quote from: 62ndidiot on 12 / September / 2016, 16:16:07
I'll make some effort to see what are likely buffers on the sx60.   To speed testing things up, it might be useful to have the ability to change the address returned by vid_get_viewport_fb_d while viewing live view.  Suggestions?
It's pretty easy to set up a lua function to change some state. E.g if you had a C function in core code called core_set_foo, you would add function in modules/luascript.c like
Code: [Select]
static int luaCB_set_foo( lua_State* L )
{
  core_set_foo(luaL_checknumber( L, 1 ));
  return 0;
}
Export it to lua by adding to chdk_funcs (also in luascript.c) like
Code: [Select]
    FUNC(set_foo)
And add core_set_foo to modules/module_export_list.c

Or you can just declare a global variable in C code somewhere, look up the address in main.bin.dump use poke to change it.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #502 on: 13 / September / 2016, 12:27:07 »
Quote
The possible playback display buffers I have found are
0x5e208000
0x5e608000
0x5ea08000
0x5ee08000
On SX60HS these appear to be:
Code: [Select]
0xfccf4050: 0x5f078000 0x00000001 0x00000000 0x5ec78000
0xfccf4060: 0x00000001 0x00000000 0x5e878000 0x00000001
0xfccf4070: 0x00000000 0x5e478000 0x00000001 0x00000000
0xfccf4080: 0x5cc78000 0x00000001 0x00000000 0x00000000There are five (not four) of them so I suspect g7x has one more:
0x5f078000
0x5ec78000
0x5e878000
0x5e478000
0x5cc78000
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #503 on: 13 / September / 2016, 13:31:59 »
Please someone refresh my memory,  if I find an image at say 0x1441000 using binview on a memdump, how does that translate to a memory address?

uh...I think i know, prepend 0x4 so its
0x41441000 ...that's all over my disassembly.
« Last Edit: 13 / September / 2016, 14:20:45 by 62ndidiot »
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #504 on: 13 / September / 2016, 15:05:34 »
Found the current address for this:
Code: [Select]
void *vid_get_viewport_fb_d()    {
  extern void *current_fb_d;
  return current_fb_d;
 }
0xfa9c on 100f
Code: [Select]
0x0000fa60: 0x41441000 0x00000000 0x00e600b2 0x003e4818
0x0000fa70: 0xfc0f8661 0x00e800b4 0x00000000 0x00000001
0x0000fa80: 0x00000001 0x00000000 0x00000000 0x00000001
0x0000fa90: 0x00000000 0xffffffff 0x1f078000 0x5f078000
0x0000faa0: 0x00000000 0x00000000 0x00000000 0x00e400b0
0x0000fab0: 0xfc1b00af 0x00000000 0xfc1b00af 0x00000000
0x0000fac0: 0x00e000ac 0x00e200ae 0x00000000 0x00000000
0x0000fad0: 0x5f078000 0x00000001 0x00000001 0x5ec78000

Found by searching for small addresses near occurences of 5e878000 in the disassembly, this gave 0xfa78 as a likely pointer to the region of interest.
I suspect the g7x address is near 0x1101c. 0x1011c . Live view works nicely now even if a movie clip is displayed.


« Last Edit: 14 / September / 2016, 18:44:19 by 62ndidiot »
Logged
*

Offline reyalp

  • ******
  • 14125
Re: SX60HS Porting
« Reply #505 on: 13 / September / 2016, 16:37:39 »
Quote from: 62ndidiot on 13 / September / 2016, 13:31:59
Please someone refresh my memory,  if I find an image at say 0x1441000 using binview on a memdump, how does that translate to a memory address?

uh...I think i know, prepend 0x4 so its
0x41441000 ...that's all over my disassembly.
You should bitwise OR 0x40000000 (the "uncached bit" from platform_camera.h). Which would give you 0x51441000 0x41441000 in this case.
« Last Edit: 13 / September / 2016, 21:43:26 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #506 on: 13 / September / 2016, 20:45:45 »
0x40000000 or
0x01441000
=
0x41441000
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #507 on: 14 / September / 2016, 19:03:15 »
I also see using rmem, the bitmap-buffer address 0x41441000 and its alternate 0x4153e200 (I think these are the same as g7x), appearing at 0xfa60 (see post above).
 
Code: [Select]
con> !r=con:execwait[[t0=get_tick_count() r={} for i=1,14 do table.insert(r,{get_tick_count()-t0,peek(0xfa60)}) sleep(10) end return r]] for i,v in ipairs(r) do printf("%04d 0x%08x\n",v[1],v[2]) end
0000 0x41441000
0010 0x41441000
0020 0x41441000
0030 0x41441000
0040 0x41441000
0050 0x41441000
0060 0x4153e200
0070 0x4153e200
0080 0x4153e200
0090 0x4153e200
0100 0x4153e200
0110 0x4153e200
0120 0x4153e200
0130 0x4153e200
Logged
*

Offline reyalp

  • ******
  • 14125
Re: SX60HS Porting
« Reply #508 on: 15 / September / 2016, 00:36:50 »
Thanks for digging into this. G7X current_fb_d seems to be 0x10140, as you say it works even when a video is selected, and it also shows the swipe animations.

I noticed that it doesn't show the zoomed out thumbnail display, but it turns out that is done on the bitmap, not the viewport buffer :blink:

Quote from: 62ndidiot on 14 / September / 2016, 19:03:15
I also see using rmem, the bitmap-buffer address 0x41441000 and its alternate 0x4153e200 (I think these are the same as g7x), appearing at 0xfa60 (see post above).
Yes, these seem to be bitmap buffers. On g7x I see them at 0x10108. I'm not sure if this has any advantage over the current get_active_bitmap_buffer implementation. Remember gui_draw.c currently references the variable and index directly https://chdk.setepontos.com/index.php?topic=12788.msg129861#msg129861

Using a canon variable with the current buffer would solve this, but only if every port does it the same way. Abstracting it into a function different ports can implement differently is more maintainable. The opacity buffer also still needs to be handled (though probably there is a variable for that too)

Quote from: 62ndidiot on 13 / September / 2016, 20:45:45
0x40000000 or
0x01441000
=
0x41441000
:-[ That'll teach me to post quickly on break  :haha
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #509 on: 15 / September / 2016, 12:26:54 »
Quote
:-[ That'll teach me to post quickly on break  :haha
worse using your phone.

I did some searching about opacity buffer.  It really looks like (from the disassembly) that there is a hard correspondence between each opacity buffer and its corresponding bitmap buffer.

The correspondence is:

Opacity     <-> bitmap
0x4163b400 <-> 0x41441000
0x416b9d00 <-> 0x4153e200

That being said, the current opacity buffer can be found in
0xcb8c (on 100f) see below:

Code: [Select]
con 12> rmem -i32 0xcb8c
0x0000cb8c 4
0x0000cb8c: 0x416b9d00 <---opacity
con 12> rmem -i32 0xfa60
0x0000fa60 4
0x0000fa60: 0x4153e200 <---bitmap
con 12> rmem -i32 0xfa60
0x0000fa60 4
0x0000fa60: 0x41441000   <---bitmap
con 12> rmem -i32 0xcb8c
0x0000cb8c 4
0x0000cb8c: 0x4163b400 <----opacity
con 12>
Logged
Pages: 1 ... 46 47 48 49 50 [51] 52 53 54 55 56 ... 92   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal