A470 Porting

[Thorwak]

New build again (seems I can't keep my fingers away ).

Most importantly, all recent development done by MrSpoon (present in his patch in first msg in this thread) was manually added in by me to the current svn trunk source (769 right now). Ths includes a new colour matrix which you might find worth checking out (affects the DNG output). After a very quick test it seemed to me to be a lot better (closer to the JPG colours).

I also dusted off my reversing gear and I finally have the encryption keys necessary to build also .FI2 files, so there is no need to use a bootable card anymore - firmware update start method now also works.

The "rawfix" is of course applied as well.

Other stuff MrSpoon has mentioned in the thread should be in there too.

Since it seems svn updating is very slow (for the a470 tree) I decided to host alpha builds for the time being at a fixed URL:
http://nostalgia.suroot.com/chdk-a470-unofficial

I'll try put new builds there whenever something interesting happens.


As usual, bug reports will help development, and we still haven't heard anything from 101b users AFAIK 

Cheers,

Thorwak

[Tahkcalb]

A470-101a using 101b-769unofficial Test results
(using boot method)

OSD 
Grids, zebra, histogram and other data displays all work correctly now

RAW
Imagesize now reports and converts as 3096 x 2324 out of 3152 x 2340
Red and green seem to have a little bit of high clipping vs JPG and 768
Tried various conversion settings with DCRAW best results with "-a -W"

MISC NOTES
Autofocus assist LED flashing at startup is now green one on the back YAY!
LCD on-off results seem different (might be correct now for all I know)

I've not found any new issues or errors I'll try some more things later this
eve and follow up if there is anything odd.

Thanks for your efforts Thorwak and of course to Mr. Spoon for starting us off.

[reyalp]

Since it seems svn updating is very slow (for the a470 tree) I decided to host alpha builds for the time being at a fixed URL:
http://nostalgia.suroot.com/chdk-a470-unofficial

I haven't been following this thread closely, but if you can post a complete patch against the current trunk, I'll look into committing it.

[Thorwak]

I haven't been following this thread closely, but if you can post a complete patch against the current trunk, I'll look into committing it.

Great! I'll post it tonight since I don't have access to my dev environment right now.

Red and green seem to have a little bit of high clipping vs JPG and 768

I'm still very new to CHDK, and I don't know too much about photography neither unfortunately. Would you say it's better (colour-wise) than the 768 all-in-all? How would we go about finding the "correct" colour matrix? (See MrSpoon's patch in first msg in this thread to see how it was changed in this unofficial build vs. the last 768-rawfix)

I would be happy to build and host various test versions if someone is good at calculating those.

EDIT: Thanks for reporting btw Tahkcalb, I can't test the 101b myself There were some updates to LED addresses in MrSpoons patch so the differences you see makes perfect sense.
Also: I just noticed you mentioned you have a 101A camera - did we know already 101b version of CHDK works for this fw? Seems like great news to me Maybe the build should be renamed 101a_b or something like that then?

[reyalp]

Also: I just noticed you mentioned you have a 101A camera - did we know already 101b version of CHDK works for this fw? Seems like great news to me Maybe the build should be renamed 101a_b or something like that then?

Normal practice is to just copy the compatible version to both names in the batch builds. So for example only ixus800_sd700-101b is built, and then it is copied to ixus800_sd700-101a. You can see this in the top level Makefile.

[Thorwak]

Normal practice is to just copy the compatible version to both names in the batch builds. So for example only ixus800_sd700-101b is built, and then it is copied to ixus800_sd700-101a. You can see this in the top level Makefile.

Noted, I'll fix this too tonight then. Thanks!

[Tahkcalb]

I'm still very new to CHDK, and I don't know too much about photography neither unfortunately. Would you say it's better (colour-wise) than the 768 all-in-all? How would we go about finding the "correct" colour matrix? (See MrSpoon's patch in first msg in this thread to see how it was changed in this unofficial build vs. the last 768-rawfix)

I would be happy to build and host various test versions if someone is good at calculating those.

I think it is much better. I tried some shots with full sun, shade and tungsten over the day. I don't have a
calibrated target or anything to provide numbers. But the results when converted with Rawker(internal)
and DCRAW (from source build) are all higher in red and green channels than 768 when I output as 16bitTiff.
Using "-a" average option with DCRAW is now almost the same as the JPG output. So I'd assume that is what
the in-camera software is doing for the JPGs and I'd not worry about it too much. The work in other threads
on the color issue will likely spill over to us soon enough.

EDIT: Thanks for reporting btw Tahkcalb, I can't test the 101b myself There were some updates to LED addresses in MrSpoons patch so the differences you see makes perfect sense.
Also: I just noticed you mentioned you have a 101A camera - did we know already 101b version of CHDK works for this fw? Seems like great news to me Maybe the build should be renamed 101a_b or something like that then?

I mentioned 101B on 101A as working earlier in the thread.  I've not seen anything that is different from any of the other
101B reports so far. But I will if something does prove to be different. I usually check this thread every day, so mention
if you need any checking of specific items. Or feel free to gmail me at same username as here if you need instant reply.

Again, thanks for the efforts.

[Thorwak]

I haven't been following this thread closely, but if you can post a complete patch against the current trunk, I'll look into committing it.

Here's the full diff taken against the 769 trunk. I also fixed the Makefile to "build" a470-101a as discussed earlier. I can't see a way to attach files(?) so I'll have to link to it instead since I got an error about maximum msg length (I feel really stupid - how do I attach files anyway?).

http://nostalgia.suroot.com/chdk-a470-unofficial/a470-769-patch.txt

I tested it against a clean 769 trunk with "patch -p0 < patch.txt" and it builds and works fine (tested in camera again).

Thanks for your help!

[reyalp]

Here's the full diff taken against the 769 trunk. I also fixed the Makefile to "build" a470-101a as discussed earlier. I can't see a way to attach files(?) so I'll have to link to it instead since I got an error about maximum msg length (I feel really stupid - how do I attach files anyway?).

attachments are temporarily disabled due to forum issues.

edit:
patch committed, svn 770

Is this the first CHDK camera without a DISP button ? If so, there may be some interface issues.

Also, I'd appreciate confirmation that the 101b build actually works on 101a.

It looks like the fat32 support code is in, is there a reason CAM_MULTIPART is not enabled ?

[Tahkcalb]

Also, I'd appreciate confirmation that the 101b build actually works on 101a.

Just snagged 770 and it loads fine with no immediate issues on a GM101A Jan 24 2008.
Tried bracketing(continuous) , couple lua and ubasic scripts, DNG, and the OSD options.
If there is a general test sequence/suite for check offs, mention it and I'll run through it.


Thanks all.

[fe50]

If there is a general test sequence/suite for check offs, mention it and I'll run through it.

You can run the LUA library test and add the A470 to the list there if the test is effective...

[Thorwak]

You can run the LUA library test and add the A470 to the list there if the test is effective...

I tested the 1.02c and everything passed according to logfile, wiki updated. Would be nice with others testing on 1.01a/b.

Is this the first CHDK camera without a DISP button ? If so, there may be some interface issues.

No idea wether it's the first, but there is no DISP button on a470 at least. What are we missing out on when it comes to CHDK? :/

It looks like the fat32 support code is in, is there a reason CAM_MULTIPART is not enabled ?

Could be that it's just untested, I guess only MrSpoon could answer this. He mentioned he was moving earlier this week so I don't know when he might be back online. I only have a 2 GB card, but I guess I could try partioning it and test the functionality. Would that be meaningful or do we need someone with a big card?

Thanks for updating the svn, I'm sure a lot of ppl enjoy having an improved a470 in the autobuild!


Also, a big Thank You to those testing and reporting back on my early test builds!

[reyalp]

CAM_MULTIPART would enable "swap partitions" and "make card with 2 partitions"

The boot time stuff isn't ifdef'd so it should detect and swap partitions already, if it works. AFAIK It should work if you have a fat16 and fat32 partition regardless of the sizes.

[Thorwak]

I actually bought a fast SDHC card yesterday right before going home, 8 GB, since I realized they weren't that expensive anymore (and I could sure use the extra speed for .DNG). Then I spent hours trying to get Windows to accept the SDHC card, applying a hotfix I had to request by mail etc etc until I booted the computer with the card in the reader and the PC wouldn't even post.. I didn't know older card readers aren't compatible with SDHC So, will probably wait 'til after the weekend before I test so I can do it for real. Frustrating though, I had planned it all so well

[MrSpoon]

Hey, I never knew it took so long to get the net hooked up in a new flat!

Anywho, I've tested multipart booting and that seems to work fine. When I enabled CAM_MULTIPART the new options didnt work.

To try it you'll need to define WriteSDCard (I have this as 0xFFCF9440 for the 102c, if its wrong that'd explain a few things).

Swap partitions tells me I only have one partition, and make two partitions crashes the cam. That's as far as I've looked into it for now, so I left CAM_MULTIPART disabled.