supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10   Go Down

Windows GUI for CHDK porting

  • 94 Replies
  • 62875 Views
*

Offline waterwingz

  • ******
  • 11187
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #50 on: 31 / March / 2012, 14:21:33 »
Advertisements
Released CHDK-PT v2.02 today.

Changes include :
  • Fixed : converting tasks using address.txt was broken due to changes made when disassembly editing was added.
  • Added : a default ini file is now included.
  • Added :  made the Setup value for Indent persistent via an ini file entry.
  • Cleanup :  new example files provided and they are now set as the default entries in the ini file
The fourth change will allow me to update the instructions in the wikia so that a newbie using the default values will be able to exercise all of CHKD-PT's functions.
Logged
Ported : A1200  SD940  G10  Powershot N  G16*
*

Offline c10ud

  • ***
  • 245
Re: Windows GUI for CHDK porting
« Reply #51 on: 02 / April / 2012, 06:00:10 »
works like a charm, thanks!
Logged
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: Windows GUI for CHDK porting
« Reply #52 on: 15 / April / 2012, 11:02:27 »
@waterwingz

Great Work!!

One litle bug, Tested in sx260 finally :D,
and the functions copied in ram for the new cams, indentified by chdk-pt as FC.....  hangs the camera,  It should name them 00..... instead of FC


Logged
*

Offline waterwingz

  • ******
  • 11187
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #53 on: 15 / April / 2012, 11:24:07 »
Quote from: asm1989 on 15 / April / 2012, 11:02:27
One litle bug, Tested in sx260 finally :D,
and the functions copied in ram for the new cams, indentified by chdk-pt as FC.....  hangs the camera,  It should name them 00..... instead of FC
The need to handle memory relocation will take a bit of work.   I'll probably need to add some manual user setup function where you can specify which block of memory gets relocated and where it goes to.   Right now,  the dissassembler assumes all code is in the ROM memory area - that has to change too.

As far as you can tell,  is there only one block of memory that needs to get relocated (at least on the cameras examined so far) ?

Logged
Ported : A1200  SD940  G10  Powershot N  G16*
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: Windows GUI for CHDK porting
« Reply #54 on: 15 / April / 2012, 11:38:29 »
yes only one block at the beginning, and all the subs starting at 0x006.......
for example like irqenable , irqdisable....

Logged
*

Offline waterwingz

  • ******
  • 11187
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #55 on: 15 / April / 2012, 11:42:25 »
Quote from: asm1989 on 15 / April / 2012, 11:38:29
yes only one block at the beginning, and all the subs starting at 0x006.......
for example like irqenable , irqdisable....
So does the CHDK-PT dissassembly of the code in the ROM block try to branch to ROM addresses when it should be branching to the relocated RAM addresses ?
Logged
Ported : A1200  SD940  G10  Powershot N  G16*
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: Windows GUI for CHDK porting
« Reply #56 on: 15 / April / 2012, 11:59:58 »
yes CHDK-PT branches to 0xFC6....   when it should branch to 0x006....
Logged
*

Offline waterwingz

  • ******
  • 11187
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #57 on: 16 / July / 2012, 23:19:23 »
Quote from: asm1989 on 15 / April / 2012, 11:59:58
yes CHDK-PT branches to 0xFC6....   when it should branch to 0x006....
similar observation posted here : http://chdk.setepontos.com/index.php?topic=8318.msg88012#msg88012

I need to look into this.  I've made some cosmetic changes that I have not posted yet as well so maybe its time to crank up my Win7 partition and dive back into the auto-it code.


Logged
Ported : A1200  SD940  G10  Powershot N  G16*
*

Offline srsa_4c

  • ******
  • 3459
Re: Windows GUI for CHDK porting
« Reply #58 on: 20 / July / 2012, 00:23:16 »
Hi,

while working with the S1IS ROM I stumbled into some weirdness in the disassemblies. Not sure what the cause is, may be related to the "unusual" function prologue/epilogue this GCC compiled ROM uses. CHDK-PT 2.02
An example: in the function starting at 0xFF1CDE9C, you get the following

ROM:FF1CDF04 0xE3A01640    MOV     R1, #40,0xC

while it should be (GPL disasm)

ff1cdf04:    e3a01640    mov   r1, #67108864   ; 0x4000000

I think only MOVs are affected, but not sure.
The ROM is here: https://www.assembla.com/code/chdk-s1/subversion/nodes/misc , starts at 0xff000000.
This is only meant as a notice, maybe one more thing to look at when you find time  :)

I also find your utility useful, I can get nicely formatted ASM functions with it.
Thanks.
Logged
*

Offline waterwingz

  • ******
  • 11187
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #59 on: 20 / July / 2012, 00:38:01 »
Quote from: srsa_4c on 20 / July / 2012, 00:23:16
Hi,

while working with the S1IS ROM I stumbled into some weirdness in the disassemblies. Not sure what the cause is, may be related to the "unusual" function prologue/epilogue this GCC compiled ROM uses. CHDK-PT 2.02
An example: in the function starting at 0xFF1CDE9C, you get the following

ROM:FF1CDF04 0xE3A01640    MOV     R1, #40,0xC

while it should be (GPL disasm)

ff1cdf04:    e3a01640    mov   r1, #67108864   ; 0x4000000

I think only MOVs are affected, but not sure.
The ROM is here: https://www.assembla.com/code/chdk-s1/subversion/nodes/misc , starts at 0xff000000.
This is only meant as a notice, maybe one more thing to look at when you find time  :)

I also find your utility useful, I can get nicely formatted ASM functions with it.
Thanks.
I think you will find that those are both correct - although the GPL one is confusing if you don't know what its doing.

Take a look at this : http://www.davespace.co.uk/arm/introduction-to-arm/immediates.html

Basically,  you can only have an 8-bit value as an immediate operand.  But there are an additional 4 bit for a multiplier (ring shift right where the number of bits shifted is the 4-bit value *2)

So in this case,  #40,0xC  means 40 ring shifted right 12 bits or 0x4000000 - although I guess maybe the #40 should be #0x40 ?  Or is hex assumed ?  Need to look at that .



« Last Edit: 20 / July / 2012, 01:32:15 by waterwingz »
Logged
Ported : A1200  SD940  G10  Powershot N  G16*
Pages: 1 2 3 4 5 [6] 7 8 9 10   Go Up
« previous next »
 

Related Topics