kosy's build questions - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2   Go Down

kosy's build questions

  • 13 Replies
  • 5242 Views
*

Offline reyalp

  • ******
  • 14118
kosy's build questions
« on: 23 / May / 2012, 00:52:32 »
Advertisements
New thread to stop cluttering up the sticky CHDKShell thread, continued from http://chdk.setepontos.com/index.php?topic=845.msg85652#msg85652

Quote from: kosy on 22 / May / 2012, 02:16:18
I am getting many more differences than that. I haven't actually counted how many bytes differ, but when looking at the binary files with vbindiff I see at least several bytes per windowfull, and sometimes a whole block of differences. Much more than I would expect if I were using the same source, compiler, and options.
The fact that DISKBOOT.BIN is encoded may be relevant. Or there is some other difference in your setup you haven't identified.
Quote
My intention was to demonstrate that the source I have works, and then submit the patch to update the svn server. But there's no point in submitting a patch until I/we are confident that it it works at least as well as what is already on the server.
Your patch will be judged by whether the code makes sense, and whether owners of the affected camera confirm that it works. The patch should also be against the latest trunk or release branch, not some random source dump found on the forum.

Quote
2. I have read that some compiler (especially optimization) options  create code that doesn't really work. I'm sorry, but I don't know all the options and how to select the ones that produce the best code. Again, his selection seems to generate results that work, all the more reason to follow his choices unless and until I can make rational choices.
Anything that goes in SVN should work with the default settings, since this is what the autobuild uses. If there are problems with the defaults, these need to be identified and fixed.
Logged
Don't forget what the H stands for.
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #1 on: 23 / May / 2012, 01:47:25 »
reyalp, thank you for moving this thread. You're right, it doesn't belong in a sticky.

In trying to get a strict replication of the build I've learned a lot, but you're right, I didn't ever succeed.

And you are also right that the encryption of DISKBOOT.BIN spreads any differences around -- a single byte difference in the unencrypted file becomes many bytes difference in the encrypted file. I did learn that much of the difference is in the string area near the end of DISKBOOT.BIN -- I saved main.bin so I could see the unencrypted form to get an idea of where the bodies were buried. I looked at decode.c but didn't succeed in getting it to unencrypt the posted DISKBOOT.BIN. It would have ben nice to do so because then I could identify exactly what the differences were and determine whether they were significant.

Of course any patch has to make sense, and should be thoroughly tested. That's why I was trying to make sure the source I have is an exact match for code I and others are already happily using -- I am not sure that it is.

The two things I see in the source I have from MK11174 that differs from the svn server is
1. It uses the "face" button to switch into and out of ALT mode -- much nicer
2. It seems to have more code to support USB.

I don't know if the USB remote shutter function works -- I've never tested it because I've been doing other things, like spending way too much time trying to make sure the source matches what people are currently using (you and waterwingz DID warn me).

Oh, one of the things I learned is that "OPT_DEBUGGING=0" is not the same thing as "OPT_DEBUGGING=" -- DISKBOOT.BIN is about 4000 bytes larger when "OPT_DEBUGGING=0" is used. I had never thought to try setting it to zero, but that's what I found in one of the stable releases at the beginning of the year.



Logged
*

Offline reyalp

  • ******
  • 14118
Re: kosy's build questions
« Reply #2 on: 24 / May / 2012, 00:54:31 »
Quote from: kosy on 23 / May / 2012, 01:47:25
The two things I see in the source I have from MK11174 that differs from the svn server is
1. It uses the "face" button to switch into and out of ALT mode -- much nicer
Ideally, this should be made user selectable between "play" and "face" buttons, defaulting to "play" for consistency with other ports http://chdk.setepontos.com/index.php?topic=6787.0

Look at cameras with CAM_ADJUSTABLE_ALT_BUTTON defined for examples. If you can work out the physw_status bit for the play button, someone else can probably help with the rest.
Quote
2. It seems to have more code to support USB.
More details would be helpful.

Quote
Oh, one of the things I learned is that "OPT_DEBUGGING=0" is not the same thing as "OPT_DEBUGGING=" -- DISKBOOT.BIN is about 4000 bytes larger when "OPT_DEBUGGING=0" is used. I had never thought to try setting it to zero, but that's what I found in one of the stable releases at the beginning of the year.
The OPT_* settings in the makefiles are used with ifdef/ifndef, so undefined or empty value means off, and any other value (including 0) means on. Suggesting OPT_DEBUGGING=1 if that's what you want. It's on by default. This just enables some debugging related features, it's not like enabling debug symbols or extra error checking as you might expect in a PC program. The only reason to turn it off would be to save a small amount of memory.
Logged
Don't forget what the H stands for.
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #3 on: 24 / May / 2012, 02:36:09 »
Quote from: reyalp on 24 / May / 2012, 00:54:31
Ideally, this should be made user selectable between "play" and "face" buttons, defaulting to "play" for consistency with other ports http://chdk.setepontos.com/index.php?topic=6787.0
Cool! I'll definitely do that before I submit the patch.

Quote
The OPT_* settings in the makefiles are used with ifdef/ifndef, so undefined or empty value means off, and any other value (including 0) means on.
Thank you for the clear explanation. I suggest that builds submitted to the autobuild servers be scanned for this error -- that's where I encountered it. Of course I can't find it now because I fixed it on my local copy.
Logged
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #4 on: 25 / May / 2012, 00:22:00 »
Quote
Quote
2. It seems to have more code to support USB.
More details would be helpful.

I was wrong about there being any change in the USB code -- I just now retrieved the a3300 source from release 1860 and discovered that there are minimal changes between what MK11174 sent me and what is on the svn server.

The only substantive changes I have found so far are:
1. The new source uses the Face button to switch to/from ALT mode
2. The new source fixed lib.c as waterwingz suggested here: http://chdk.setepontos.com/index.php?topic=6972.msg79810#msg79810

I will try to make the ALT mode button user selectable between "play" and "face" buttons, as you requested.

I had to give up using CHDK-Shell for finding file differences -- I kept getting inundated with differences in non-germain files. I didn't take the time to find how I could rein in Shell's diff engine to look only at the files that mattered.
Logged
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #5 on: 02 / June / 2012, 02:32:24 »
Quote from: reyalp on 24 / May / 2012, 00:54:31
Ideally, this should be made user selectable between "play" and "face" buttons, defaulting to "play" for consistency with other ports http://chdk.setepontos.com/index.php?topic=6787.0
I succeeded days ago in making the Play button the default ALT key, and letting the user choose among the Play, Face, and Disp keys for the ALT key.

What has me completely tied up in knots is trying to properly set up the color palette. I am using colors defined by load_chdk_palette() in platform/a3300/lib.c, but the menu and other colors still change when I switch between PLAY and RECORD mode. I suspect the line
   if ((active_palette_buffer == 0) || (active_palette_buffer == 4))
in lib.c is in error -- that is, the correct value of active_palette_buffer for PLAY and RECORD is something different than 0 and 4.

But how do I determine the proper value of active_palette_buffer in PLAY mode? And in RECORD mode?

I've tried searching but I haven't been successful in finding this information.

Thanks!
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: kosy's build questions
« Reply #6 on: 02 / June / 2012, 02:41:20 »
Quote from: kosy on 02 / June / 2012, 02:32:24
What has me completely tied up in knots is trying to properly set up the color palette. I am using colors defined by load_chdk_palette() in platform/a3300/lib.c, but the menu and other colors still change when I switch between PLAY and RECORD mode.
This is a known problem.  Canon changes the currrently used palette on the fly depending on what mode the camera is in ( playback,  shooting,  playback menu,  shooting menu ...)

But CHDK assumes there is only one palette - typically the one used in either shooting or playback mode.  When the camera changes the underlying menu,  the CHDK stuff look to be just wrong.

philmoz worked on fixing this for his cameras but it turned out to be a huge effort for each individual camera so the work got no farther.

For now,  try to pick palette colors at the low end of the range that tend to be common between modes.  Probably the best you can do.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #7 on: 02 / June / 2012, 02:58:12 »
I thought the purpose of load_chdk_palette() was to avoid the problem of Canon's palette changing depending on the current mode.

I have learned that the A3300 even has different palettes in the same mode, depending on what else is happening.

The only part of the palette that stays constant is values 00 through 1C, which is either transparent (00) or white (01) through black (1C). All the pretty colors move around or sometimes disappear entirely.

load_chdk_palette() seems to be working fine when I am in RECORD mode, but doesn't seem to be there when in PLAY. That's why I think the branch statement is not testing for the correct condition.

Does anyone know how to determine the proper value of active_palette_buffer in PLAY mode? And in RECORD mode?
Logged
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #8 on: 02 / June / 2012, 03:15:03 »
Nevermind, I think I figured out an approach.

I won't be able to work on it for a few days, but I'll keep you posted on what, if any, progress is made.

  --Kosy
Logged
*

Offline kosy

  • *
  • 28
Re: kosy's build questions
« Reply #9 on: 06 / June / 2012, 01:17:29 »
Well that was an interesting diversion.

I learned several things about the A3300:
  • It has at least 9 color palettes
  • the values of active_palette_buffer are 0 for "camera" mode, and 4 for "play" mode, so the line
             if ((active_palette_buffer == 0) || (active_palette_buffer == 4))
        is correct.
  • I wrote a little palette editor and discovered something else -- the camera caches the palette somewhere else! I think what's happening is the palette is loaded, the conversion from TYUV to TRGB is made, and the TRGB results are cached and used for actually writing to the screen. That would be a lot faster than repeatedly doing the conversion for each pixel drawn. The result is that the palette editor is cute but useless.

Here's a summary of the info:

APB   Addr       Mode
 0   001a 1cc0   camera mode
 1
 2
 3
 4   001a c8c0   playback mode
 5
 6   001b 57b8   Menu/Start-up Image
 7   001b 3fc0   Menu
 8   001b 6330   Menu/Format|Language|Set Date/Time|Reset All

Where
  APB:  active_palette_buffer value
  Addr: base address of color palette

Palettes 6 and 8 are invoked when you get into some submenus of the main menu -- that's why I show them as Menu/whatever.
The vertical bar denotes OR, as in Format OR Language, etc.

I haven't actually logged palettes 1-3 and 5, but I suspect they are out there somewhere.

I DID find a spot that seems to be safe for the CHDK colors in both palettes 0 and 4. I'm much happier with the visual experience now.
« Last Edit: 06 / June / 2012, 01:22:21 by kosy »
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal