SX280 / 275 / 270 porting - page 33 - DryOS Development - CHDK Forum  

SX280 / 275 / 270 porting

  • 325 Replies
  • 145936 Views
*

Offline reyalp

  • ******
  • 11900
Re: SX280 / 275 / 270 porting
« Reply #320 on: 04 / August / 2018, 17:11:28 »
Advertisements
I figured out that the "i-contrast" in the standard menu cause the overexposures with bright light!!! "i-contrast" turned off and "custom auto ISO" works as expected!!!
Thanks for that, I added this info to the camera notes.
It's probably a safe bet that i-contrast interferes with quite a few CHDK functions. It is known to cause problems with raw raw develop at least: https://chdk.setepontos.com/index.php?topic=9601.0
« Last Edit: 04 / August / 2018, 17:13:52 by reyalp »
Don't forget what the H stands for.

Re: SX280 / 275 / 270 porting
« Reply #321 on: 06 / August / 2018, 05:14:38 »
It's probably a safe bet that i-contrast interferes with quite a few CHDK functions. It is known to cause problems with raw raw develop at least:


So far I've always thought that i-contrast has no effect on the RAW's and that only the dark areas in the JPG development are pushed up.
M100 100a, M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), 2*S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline reyalp

  • ******
  • 11900
Re: SX280 / 275 / 270 porting
« Reply #322 on: 06 / August / 2018, 13:32:57 »
So far I've always thought that i-contrast has no effect on the RAW's and that only the dark areas in the JPG development are pushed up.
You're right, the strike-out above is because I mis-remembered the case in the linked thread, which only applies to "raw develop".

I wouldn't be surprised if i-contrast interacts badly in other situations where ISO overrides are involved.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3906
Re: SX280 / 275 / 270 porting
« Reply #323 on: 12 / February / 2019, 13:54:55 »
Just an interesting technical observation I made recently.
The DIGIC 6 has 16kB ATCM and 64kB BTCM.
ATCM is always mapped to address zero. In earlier D6 PowerShots (such as this cam), BTCM is mapped to 0x80000000. On newer D6 models, BTCM is at 0xbfe10000.
I just noticed that one of the MPU regions on this cam does cover 0xbfe10000, so I went ahead testing it. I found that there is at least 64kB RAM mapped there which seems unused (filled completely with random bytes).
I filled it with a magic word and looked whether it becomes visible in main RAM or elsewhere. I could not find that content elsewhere - not in RAM and not in the TCMs. So, it looks like this cam has an extra 64kB of memory.
I could not find anything in ROM that would reference 0xbfe1xxxx ...


*

Offline reyalp

  • ******
  • 11900
Re: SX280 / 275 / 270 porting
« Reply #324 on: 13 / February / 2019, 00:36:28 »
Just an interesting technical observation I made recently.
The DIGIC 6 has 16kB ATCM and 64kB BTCM.
ATCM is always mapped to address zero. In earlier D6 PowerShots (such as this cam), BTCM is mapped to 0x80000000. On newer D6 models, BTCM is at 0xbfe10000.
I just noticed that one of the MPU regions on this cam does cover 0xbfe10000, so I went ahead testing it. I found that there is at least 64kB RAM mapped there which seems unused (filled completely with random bytes).
I filled it with a magic word and looked whether it becomes visible in main RAM or elsewhere. I could not find that content elsewhere - not in RAM and not in the TCMs. So, it looks like this cam has an extra 64kB of memory.
I could not find anything in ROM that would reference 0xbfe1xxxx ...
That's pretty strange. You could try to find out if it's as fast as normal RAM (or TCM, but that seems unlikely)

One thing I've wondered but never got around to experimenting with is how much (if any) of the BTCM is used on cams that don't copy dryos code there. Even on the ones that do copy, there might be a fair bit available (sx710 copies ~30kb)
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3906
Re: SX280 / 275 / 270 porting
« Reply #325 on: 15 / February / 2019, 18:36:29 »
That's pretty strange. You could try to find out if it's as fast as normal RAM (or TCM, but that seems unlikely)
I have to correct myself. With a bit more careful testing, it turned out that this memory area is actually 0x2000 bytes long and repeating between 0xbfe00000...0xbfefffff. That makes me think it might be a TCM of the other core.
Using the same test loop, I got the following results for regular memory, btcm and this area:
MEM c(1)      28320 R,   38085 W Kb/s
MEM uc(1)      1953 R,   38085 W Kb/s
MEM c(4)      64453 R,  151367 W Kb/s
MEM uc(4)     10742 R,   41992 W Kb/s
MEM c(16)     88867 R,  214843 W Kb/s
MEM uc(16)    42968 R,  191406 W Kb/s
BTCM (1)      37109 R,       0 W Kb/s
BTCM (4)     153320 R,       0 W Kb/s
BTCM (16)    615234 R,       0 W Kb/s
BFE1 (1)      12695 R,   38085 W Kb/s
BFE1 (4)      50781 R,  153320 W Kb/s
BFE1 (16)    180664 R,  611328 W Kb/s

(Some or all of these results can be buggy. 1, 4, 16 are the access units - byte, word, 4 word)

Quote
One thing I've wondered but never got around to experimenting with is how much (if any) of the BTCM is used on cams that don't copy dryos code there. Even on the ones that do copy, there might be a fair bit available (sx710 copies ~30kb)
The sx280 appears to use some at its start and some less at its end, but most of it is just noise. I just dumped this area several times (while doing something on the cam and also after off/on cycles), and compared parts of the dumps visually.

edit:
The m10 also has this 0x2000 byte area repeating between 0xbfe00000...0xbfe0ffff and 0xbfe20000...0xbfefffff
« Last Edit: 16 / February / 2019, 12:28:00 by srsa_4c »

 

Related Topics