CHDK Forum
CHDK Development => General Discussion and Assistance => DryOS Development => Topic started by: mattkime on 24 / December / 2009, 14:13:42
-
thinking about starting the effort. do we have a firmware dump yet?
-
No (http://chdk.wikia.com/wiki/G11). This is almost certainly one of the newer cameras that needs differently encoded diskboot, and will need to be blinked or used a modified udumper.
-
-
http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera (http://chdk.wikia.com/wiki/Adding_support_of_a_new_camera)
kingcang - any experience with this sort of endeavor?
-
-
Which way does the udumper have to be modified?
It needs to be modified in the way that makes it work :)
- you need the correct encoding of diskboot. This is probably one of the new dryos encodings. See tools/dancingbits.c in the CHDK source. You can determine if your encoding is correct with an LED, which you need to find first, by poking likely MMIO addresses. You can either try every diskboot encoding, or use and FI2 file.
- you need to find the WriteSDCard function. Looking at the WriteSDCard function of other "new" (Dryos 2.3R39 = ixus200, sx20 ...) cameras should allow you to do this. Note that I'm just guessing that the G11 falls in this group, it might be one of the earlier ones that just has a different diskboot encoding but doesn't use the newest dryos.
- you may need to particular bits of memory zeroed / not zeroed for WriteSDCard to work.
Note that Radup reported that he couldn't get WriteSDCard to work at all on ixus200/sd980. This may mean it is impossible to make it work, or he had the wrong function or there's something else that needs to be adjusted.
-
- You can either try every diskboot encoding, or use and FI2 file.
Sure. How many diskboot encodings are out there and where to download them all at once? Please tell me what you mean by "FI2 file".
- you need to find the WriteSDCard function...
HOW exactly? Boy, do I have to pull everything out of your nose? :P
-kingcang
-
Sure. How many diskboot encodings are out there and where to download them all at once? Please tell me what you mean by "FI2 file".
As I said, the known diskboot encodings are listed in tools/dancingbits.c
An FI2 file is a firmware update file. This is actually just another executable which is encoded yet another style of encoding. See http://chdk.setepontos.com/index.php/topic,2995.0.html (http://chdk.setepontos.com/index.php/topic,2995.0.html) which is the 3rd result if you search the forum for FI2.
The G11 *probably* uses the digic 4 encoding.
You should find useful hints in the sx20 and ixus200/sd980 porting threads.
- you need to find the WriteSDCard function...
HOW exactly?
Using code, like udumper currently does. The code needs to do something that works on new style cameras. If this doesn't make sense, you need to study udumper until it does. See http://chdk.wikia.com/wiki/Udumper (http://chdk.wikia.com/wiki/Udumper) for some useful links. Refer to the Ixus200 and sx20 dumps for examples of new style (but as I said, we don't even know for sure G11 is this style)
Boy, do I have to pull everything out of your nose? :P
I was going to stop at "make it work", but in the spirit of the season, I thought I'd be nice and give you a few hints. :xmas
You need to have a realistic understanding of what this task requires: You need to know C (more than just "hello world"!) and assembler, and you need to be able to figure things out yourself. If someone could just tell you what needs to be done, they would have done themself already.
-
-
-
The FI2 you need to build first is one that searches for LEDs. This is done by poking a bunch of MMIO addresses. I'm not aware of anyone bricking a camera doing this, but the risk is likely to be greater than 0. There's probably some code for this floating around on the forum.
Good. This sounds like a specific task to me. So first step in order to build a working FI2 would be to find the LED adresses.
And that is done by poking address by address until the correct ones are found...
Would someone please actually link the code of the program for finding the LEDs here? Thanks ahaed!
-kingcang
-
Would someone please actually link the code of the program for finding the LEDs here? Thanks ahaed!
You should find useful hints in the sx20 and ixus200/sd980 porting threads.
http://chdk.setepontos.com/index.php/topic,4188.msg39620.html#msg39620 (http://chdk.setepontos.com/index.php/topic,4188.msg39620.html#msg39620) starting here, perhaps.
edit:
Note there isn't a "program" to find LEDs. You have to modify it repeatedly to narrow down the range, because you have no other output available to tell you *where* it was found, and the program doesn't know when it has found one. Binary search is your friend.
-
So to quote RaduP here, this would be the code to be compiled [each time] for finding the correct LED addresses:
void find_led()
{
volatile long *p;
int i;
p=(void*)0xc0220000;
for(i=0;i<0xffff;i++)
{
*p=0x46;
p++;
}
}
As far as I read from the thread you mentioned, reyalp, the red marked addresses is considered to be the range searched within.
Which range should be used for the Canon G11? After compiling the code, how and where should it be executed?
If my conclusions so far are lacking something, feel free to correct me.
-kingcang
-
Which would be the range for the Canon G11
AFAIK, all known cameras have their all their MMIO in a 16 MB range from 0xC0000000 to 0xC1000000.
The code quoted above searches from 0xC0220000 through 0xC025FFFC, since it does 0xFFFF iterations which each cover 4 bytes (http://chdk.setepontos.com/index.php/topic,4188.msg39629.html#msg39629).
To avoid this kind of confusion I would write this as:
#define START ((long *)0xc0220000)
#define END ((long *)0xc0224000) // or whatever
void find_led()
{
volatile long *p;
for(p=START;p<END;p++)
{
*p=0x46;
}
}
As to where the G11 LEDs are, that's for you to find. It's probably similar to either the G10 (http://chdk.wikia.com/wiki/G10), or one of the recent cameras. The LED addresses for a camera are frequently listed on it's wiki page.
Starting near 0xC0220000 seems to be common, and 0xC0223030 has been the AF led on several recent models.
-
-
-
-
Please give me a nudge.
Fair comment.
I have never ported a camera completely from scratch so cannot help there.
Getting started will be the most difficult bit.
I hope people who know how to do this can give you enough detailed information in order to start.
It should get easier as you progress.
The main thing is that you have the camera, will be able to port it with some guidance and are keen to try.
Porting is regarded as a 'black art', more detailed information is needed.
Good luck !
-
-
-
i'm glad there is so much back and forth in this discussion. may be helpful for others in the future.
-
-
-
What do you mean ?
The camera needs to generate a signal, you do that by blinking an led and detecting the light with a phototransistor or photodiode.
Updated the scheme to clarify my thoughts. Meaning: The earphones act as a transmitter of the signals catched by the photodiode, which in turn are "forwarded" as sounds from the earphones to the recording application on the computer. Feel free to correct me on this one.
-kingcang
-
The earphones act as a transmitter of the signals catched by the photodiode
No.
The phototransistor generates a tiny voltage that is fed directly to the sound card microphone input.
Just connect a phototransistor or photodiode to a 3.5mm jack plug.
-
-
-
The phototransistor or photodiode is connected to a 3.5mm jack plug, which is connected to what? If the jack plug is supposed to be connected to the computer, how exactly?
Ehhhh ... you plug it in.
You actually use a 3.5mm stereo jack, see here :-
http://chdk.wikia.com/wiki/Firmware_Dumping (http://chdk.wikia.com/wiki/Firmware_Dumping)
The first diagram simply switches the microphone input to ground.
That will work if there is a voltage on that pin of the microphone socket, measure it.
The other two circuits get a source of voltage either from the soundcard or an external battery.
A variable resistor allows you to alter the size of the signal.
Try the simplest circuit first.
Of course, the first thing is to find where the LED's are.
-
Hello,
i also own an G11 and try to make a firmware dump. But actually i am not able to find the LED adresses.
I installed the GCC/CHDK Stuff and i was able to compile the CHDK CVS code, so development enviroment works. ;)
Then i compiled one of the LED Blinking sourcecodes, which trys the adress range 0xC0220000 .. 0xC0223000, and put the diskboot.bin on an 2GB SDHC Cards (card was previously made bootable with Cardtricks), then i put the write protected SDHC-Card into the G11 and started the camera via push of the PLAY button. The camera does not start, display&led stays dark. Usually this is a good sign, because it looks looks like the camera trys to boot the diskboot.bin, right? I wait 3 Minutes, but none of the LEDs goes on.
I then tried to use the dancingbits tool on the diskboot.bin with option 1..3, but also with the modified diskboot.bin, i cant see any LEDs lightning.
So at this point i simply don't know if the G11 executes my created diskboot.bin, or crashes. Or have i to wait longer until the LEDs shows any lightning? How long "normaly" takes the boot process and how long i have to wait until i know alle LEDs adresses are probeded ( e.g. in the range from 0xC0220000 .. 0xC0223000). Is there a trick to know, that my code is even executed?
-
So at this point i simply don't know if the G11 executes my created diskboot.bin, or crashes. Or have i to wait longer until the LEDs shows any lightning? How long "normaly" takes the boot process and how long i have to wait until i know alle LEDs adresses are probeded ( e.g. in the range from 0xC0220000 .. 0xC0223000). Is there a trick to know, that my code is even executed?
Sounds like you are doing the right thing. I would to take several minutes, but it would be helpful if you link or post the exact blinking code you are using and the steps you are using to compile it. If you have another CHDK compatible camera, try building for that so you can be sure your toolchain is set up correctly.
The camera not starting means that
- the SD card is set correctly to be bootable, camera recognized and tried to run it.
Problems could be
- wrong encoding. You can try the same code as an FI2. To make an FI2, you must start with an unencoded diskboot, and you must use the correct keys and PID for your camera
- something wrong in build process. One easy way to get a correct build process is to modify a CHDK loader. Pick a camera and put your blinker code in loader/<camera>/entry.S or main.c my_restart(). Change the PID, diskboot and FI2 options in platform/camera/makefile/sub/<ver>/makefile.inc
- toolchain not set up correctly.
- something wrong with the code.
-
-
Okay, i was able to get a chdk supported camera into my hands (A590IS), so i modified the blinker code to the led adresses for this model (found in the wiki) and tried my custom diskboot.bin build on this camera.
Result: Display stays dark, and all LEDs are set to ON after 1-2 Seconds. :)
So my build toolchain seems to work. I tried this build also on the G11, but nothing happens, camera looks "dead".
I then did a build, which covers the known led adress range for the G10, but again nothing happens. Also increasing the range does not show any success, LEDs are allways off.
So i think, i have to take a look on the encoding/FI2 stuff. ;)
-
what to do with the other end of the jack plug
Those diagrams show schematically how you connect the components to the jack plug.
In practice, you connect to the wires in the cable that are already connected to those parts of the plug.
Use a testmeter on the resistance range to determine where each wire connects to on the plug.
(I am now going out until this evening).
-
@kingcang
http://chdk.wikia.com/wiki/Porting_the_CHDK (http://chdk.wikia.com/wiki/Porting_the_CHDK) ;)
-
-
Problems could be
- wrong encoding. You can try the same code as an FI2. To make an FI2, you must start with an unencoded diskboot, and you must use the correct keys and PID for your camera
Okay, i made some tests and i was able to create a FI2 file that the G11 recognizes as a valid firmware.
I simply used the same keys as in G10 (extracted from G10 FW-Dump) and compiled with that keys a fi2encdec.exe. Then i tested this tool by downloading a original G10 FW from the canon site and decompressed the FW. It works without errors. Then i changed the HDR to 0x000031DF and placed my diskboot.bin (with the led blinker code) into the map file. The created FI2 file was accepted from the camera (camere shows the message: "Update firmware version? 1.0.0.0 -> 1.0.0.0") and when i press the "OK" button display goes off, ON/OFF Led stays on, and the G11 looks up until i remove the battery. So i think this means, that the G11 has accepted the FI2 file and tries to start my "fake" Firmware Update / diskboot.bin file, right?
-
Success! With the FI2 methode i got finally the led blinker code running. With my current (pretty wide) adress range i got the AF-Led and the display illumination switched on. :)
Now i have to do some binary search i think...
-
-
Okay, if find the AF-LED address, it is the same as for the SD1100IS:
LED AF: 0xC0223030
So this adress is allready the default LED-AF adress in the FW-Dumper tool (e.g. found in Blinker_Java_Version_by_Syrius.zip).
So i will try to create a FW-Dumper FI2 file for FW-Dumping based on this dumper. :xmas
-
-
-
Hmm, now i have to build the hw to receive the data and calibratethe DELAY_COUNT in the blink_rom routine.
What exactly are you actually building, ERR99? A UART receiver like intendet to do?
-kingcang
-
Currently i try the phototransistor way, i found a old mouse and connected one of the phototransistors to the mic-input on my computer. But the signal is very weak, i will see if its still enough for a successfull firmware dump.
At now is was also able to find the adresses of two more LEDs and i think if found also the adress to switch off the camera (the dumper uses the switch off at end of work, so you know it is finished ;) ).
LED exposure compensation dial: 0xC0220128
LED ISO dial: 0xC022012C
There is still a lot of work to do. ;)
-
-
-
I cannot tell you the wiring because I do not have the Ipod lead, you have to tell me.
Do you have a test meter ?
If not, is the jack-plug sealed or can you unscrew the outside to see how the wires are connected ?
Soon be my bedtime .....
David
-
-
My receiver hw is not working, the soundcard of my laptop is so noise that i cant see any difference between the received signal and the base noise. Also my try to build a com-port receiver does not work, maybe i need a "real" comport and not a usb-serial adapter? (My Laptop does not have any comports).
Maybe someone else has more sucess dumping the firmware, for the comport dumping i added two G11 FI2 files
(for the two flash areas as descriped in the wik, 0xFF800000..0xFFA00000 and 0xFFA00000..0xFFC00000) based on the dumper from "Blinker_Java_Version_by_Syrius\by_grand_blink_g7".
Simply put one of the files on the SD-Card, start camera with PLAY button, press MENU,press UP and the "Func Set" to select the "Firm Update..." Menu and select "OK" to start the dumper. After a few seconds the AF-Light will go on, and a few seconds later the blinking/dumping process starts.
-
My receiver hw is not working
You need to get that working.
What circuit are you using ?
-
there should be a decription online somwhere...
I do not understand what you are saying.
You do not need a description.
Cut the cable near the earphone end so that you have a jack plug with a reasonable length of wire attached.
Using a testmeter, determine which part of the plug each wire connects to.
Post your results.
-
I have a G11 and want to support this project but have nno coding skills.
Will help anyway I can though.
On the Apple headphones, the tip of the plug connects to the Left earphone +, the next ring is for the right channel, next ring is the mic and the base of the plug is common ground. Hope that helps!
-
Hope that helps!
Thanks Steven.
We really need to know how the wires are connected to whatever plug is being used.
We also need to know if the sound-card is providing a bias voltage on the ring.
If not, an external voltage may be needed.
When the led is blinked the input to the sound card microphone input needs to be tens of millivolts.
-
On the Apple headphones, the tip of the plug connects to the Left earphone +, the next ring is for the right channel, next ring is the mic and the base of the plug is common ground. Hope that helps!
Thank you for your contribution, Stephen! :)
We also need to know if the sound-card is providing a bias voltage on the ring. If not, an external voltage may be needed.
How exactly to find out? With the testmeter?
-kingcang
-
My receiver hw is not working
You need to get that working.
What circuit are you using ?
I tried the simple phototransistor->soundcard cable. But i can only see something sampled in the audiosoftware if i use my 430EX Flash on the phototransistor, nohting happens with "normal" led light. Then i tried the com port interface (phototransistor, 10KOhm resistor) but i cant receive anything with load.exe or realterm.
I am not sure if the phototransistor from the mice is a good choise, i orderd now some photodiodes and other stuff to build the rs232 blinking interface (http://chdk.wikia.com/wiki/Blinking_the_firmware_to_the_RS232_interface (http://chdk.wikia.com/wiki/Blinking_the_firmware_to_the_RS232_interface)). Lets hope this will better work, but now i have to wait until my order is delivered.
-
I am not sure if the phototransistor from the mice is a good choise, i orderd now some photodiodes and other stuff to build the rs232 blinking interface..
Why would the phototransistor work any different than the ones bought in a store? Today I bought the last ingredients for my own receiver hardware, except for the phototransistor. If it really would be a better choice to buy one instead of using the ones from a ball-driven mouse, please tell me.
Also it would be important for me to know exactly which one would be best to built.
It might be possible for me to buy a phototransistor today and finish the receiver somewhere during this week...
-kingcang
-
How exactly to find out? With the testmeter?
Yes.
If you are going to use the Ipod lead cut it as I told you.
If not, buy a jack plug and solder some wires to it.
Once you have done one of the above I can tell you what to do next.
Does your sound card microphone input use a stereo jack ?
-
I tried the simple phototransistor->soundcard cable.
Before you try the more complicated circuit tell me the colour of each wire and which part of the jack-plug it connects to.
Is there a voltage between ring and shield when it is plugged into the sound card ?
-
-
You can use a photransistor or photodiode as long as they can detect visible light.
The ones in a mouse mainly detect infra-red but some may also detect visible light.
You do not know until you try it.
I cannot give you any further help until you answer my question, does your sound-card use a mono jack plug or a stereo jack plug ?
If you are not sure, find out from the sound-card manual or online.
-
I cannot give you any further help until you answer my question, does your sound-card use a mono jack plug or a stereo jack plug ?
Using stereo jack plugs is pretty much standard in todays technology - all of my sound cards support stereo jack plugs. Keep going, Microfunguy...
-kingcang
-
These are custom connectors made especially for the Ipod.
You need to obtain a 3.5mm stereo jack plug.
-
-
The link you posted is not relevant to your plug and cable.
It is impossible to tell from the photo in reply #34 which wire is connected to second ring.
Is it the yellow wire or the other wire (not sure what colour it is) ?
The image in above reply is not clear enough to tell.
Can you post a better image ?
The microphone input is connected to ground.
-
-
I assume that both the yellow and red/green wire are connected to shield (ground) ?
Do you have a testmeter ?
If not, no futher progress can be made.
-
I assume that both the yellow and red/green wire are connected to shield (ground) ?
Do you have a testmeter ?
If not, no futher progress can be made.
You can also improvise. E.g. by using a battery and small light bulb or LED.
-
-
You can also improvise. E.g. by using a battery and small light bulb or LED.
Yes, for determining how the wires are connected.
But we also need to see if there is a voltage on either of the microphone inputs on the sound card.
If there is, the phototransistor can simply connect that input to ground.
If not, we need to use an external battery.
-
So, do you have a test meter ?
If not, connect the jack plug to your sound card and run a free 'sound card oscilloscope' programme that will display the voltage.
Connect the red or green wire to the ground wires (make sure the insulation is removed from the wires).
Does the displayed signal voltage change ?
(It is easier to buy a very inexpensive Chinese-made testmeter).
Are you sure the microphone input of your sound card uses a stereo plug ?
It is more likely to be a mono jack plug.
-
-
Connect the red or green wire to the ground wires
You replied :-
connecting the red with the green wire
which is not the same thing !
-
-
-
I tried the simple phototransistor->soundcard cable.
Before you try the more complicated circuit tell me the colour of each wire and which part of the jack-plug it connects to.
Is there a voltage between ring and shield when it is plugged into the sound card ?
I finally find out, why the phototransistor method is not working for me.
It is (like i expected) the used photodiode/transistor from the old computer mouse, which makes trouble here. The mouse uses infrared light (>780nm) led, an so the photodiode in my mouse is only sensitive to infrared light. If i use a led-lamp or the af-light of the G11, i got no peak on the mic-input of my soundcard. But if i use are "real" lamp, or use one of my infra-red tv-remotes, i got huge impules on the mic-input, which can be perfectly recorded.
So, bottom line is: Use only photodiodes which are sensitive to "visible" light, like the SFH 300 (420...1130nm) , because the G11 LEDs does not emit light in the infrared spectrum. So i am grounded now and have to wait until my photodiode order arrives... damned! :haha
-
i am grounded now and have to wait until my photodiode order arrives
Sometimes. the photodiode from a mouse can work, especially with the very bright autofocus led.
kingcang may succeed in downloading it.
But, we at least know that the firmware CAN be dumped.
Once that is done, the 'big boys' can tell you what to do next.
Is the microphone input on your sound card a mono or stereo jack ?
-
-
Umpf. Just found that the Lenovo T61 uses a "Monaural Microphone Jack"
That is OK, we are making progress ... slowly.
So, you need a 3.5mm mono jack.
Do you have a phototransistor or maybe a photodiode ?
If not, you need to get one.
(that is an expensive-looking laptop !)
We can test your 'scope software as soon as you get the plug.
You will also need a resistor of a few kilohms and another one of a few hundred kilohms.
-
-
I am going to bed, but first ......
Connect the lower-value resistor between the two wires of the jack plug.
Connect the other resistor to the wire that connects to the jack plug tip.
i.e. not to the ground end,
|Connect the ground wire to the -ve of a 1.2V or 1.5V battery.
Connect a wire to the larger value resistor (the end that is not connected to anything).
Plug into sound card and start 'scope programme.
Touch that last wire to battery +ve.
If everything is setup correctly you should see the scope display change.
-
-
Hello you Canon enthusiasts out there, hello ERR99! :)
I tried the simple phototransistor->soundcard cable.
My first thought was: if the signals are to weak, you probably have to amplify them, just like the comparator LM311 does in the RS232 blinking receiver (http://chdk.wikia.com/wiki/Blinking_the_firmware_to_the_RS232_interface).
The mouse uses infrared light (>780nm) led, an so the photodiode in my mouse is only sensitive to infrared light.
Well, I have several pieces old Typhoon mini LED mice operating in the visual red range. If you were living in Germany, I'd sent you one quickly. ;)
So, bottom line is: Use only photodiodes which are sensitive to "visible" light, like the SFH 300 (420...1130nm) , because the G11 LEDs does not emit light in the infrared spectrum. So i am grounded now and have to wait until my photodiode order arrives... damned! :haha
Surely is the blinking receiver a better way. So I'm exciting to wait for your next try! Good job, ERR99! :)
Nice greetings!
:)
-
Does something "more recommendable" than the BPW 96 C phototransistor exist for building?
It depends what you can easily obtain.
Even if a photransistor has peak response in the infra-red as long as it has some response in the visible range (above 400nm generally and above 600nm for the autofocus led) it will be OK.
Here is a typical phototransistor : http://www.maplin.co.uk/module.aspx?moduleno=17936 (http://www.maplin.co.uk/module.aspx?moduleno=17936)
In the circuit I described above, the transistor would be connected across the lower-value resistor.
Whenever the AF led blinks, the transistor conducts and pulls the input voltage to the sound card down to zero.
test circuit and 'scope software by pointing TV remote at the phototransistor.
-
Great work guys, I wish I could help! I have lots of phono plugs and cabbles etc and can solder. If you need any parts to help let me know and I'll buy and have sent to you or donate if there is a paypal address, and if I can help with my G11 in any way, just let me know!
-
test circuit and 'scope software by pointing TV remote at the phototransistor.
Good, just returned and have all necessary stuff togetether now (as well as a raw 3.5 mm mono jack plug).
Hitting off to solder the jack plug soon - but more importantly, which circuit to build?
The one you discribed in Reply #78 (http://chdk.setepontos.com/index.php/topic,4647.msg45199.html#msg45199), Microfunguy? Hm...
-kingcang
-
which circuit to build?
The one you discribed in Reply #78 (http://chdk.setepontos.com/index.php/topic,4647.msg45199.html#msg45199),
Yes.
-
-
I am sorry, I have no idea what you are talking about.
Not to worry, some photos will help.
I do not know what these references to twisted wires mean.
Unscrew the cover of the jack plug.
Solder a black or green wire to the metal part that also clamps the cable.
Solder a red wire to the other terminal.
Solder a resistor of a few kilohms across both wires.
Please take a photo (with jack plug cover unscrewed) and post here.
It does not matter if you have to use different coloured wires as long as I can see where they are connected to.
I go to bed at 00:45 GMT.
-
Please tell me the reference number of the phototransistor you are using.
-
I think it will be easier if tomorrow I wire-up a plug and post a photo.
It will give me the opportunity of testing scope software on my own PC.
-
-
-
-
-
-
My soundcard microphone input uses a 3.5mm stereo jack plug.
The tip is a red wire, the ring a white wire and shield is bare copper.
The tip and ring both have 2V bias on them so I can use the ring bias instead of a battery.
Before we go any further, open the sound-control icon in your system tray and set input to microphone.
Start your scope programme.
Adjust settings until you see a rough sine wave.
(make sure the microphone volume control is not set to zero !)
Touch the red/blue wires and the amplitude of the wave should increase .. right off the screen.
Get that working first.
(because you already have one resistor fitted, your circuit will be less sensitive than mine at picking-up 'noise' for this test).
-
-
Your post did not reveal if another type of resistor is needed for completion though.
I said that you should do the test I mentioned first to make sure your scope programme works properly.
Then, try the simplest circuit shown in reply #21.
Connect longer lead of phototransistor to the bare copper wire and other lead to red/blue.
It may not be necessary to obtain any more parts.
Do you have an external power supply for your camera ?
It may be on for a long time while you are dumping.
-
-
I have no idea if the battery will last long enough or not.
I guess you will just have to try.
-
-
If it helps, I am using this programme : http://www.zeitnitz.de/Christian/scope_en (http://www.zeitnitz.de/Christian/scope_en)
-
If it helps, I am using this programme : http://www.zeitnitz.de/Christian/scope_en (http://www.zeitnitz.de/Christian/scope_en)
Oh boy, how I love WINE (http://www.winehq.org)!! Test completed. Status: My hardware works perfectly, signals are strong. Ready to rumble now... :xmas
This evening I got some 100k resistors, just want a confirmation if the simple circuit in reply #21 is the best for dumping in that case.
-kingcang
-
My hardware works perfectly
Are you telling the truth ? :)
Just so we are both talking about the same thing, are you using the scope programme that I gave you the link for ?
just want a confirmation if the simple circuit in reply #21 is the best for dumping in that case.
Connect the photo transistor as indicated in reply #21.
Point the TV remote at it.
If necessary, adjust the microphone volume control and/or the scope amplification control.
If you have problems, unsolder one end of the resistor in the jack plug.
If possible, post a screenshot of the scope display.
-
-
i assume the above screenshot is from the noise pick-up test and you have not tested the phototransistor yet ?
-
-
-
-
I took allready a look into the code, to check if the G11 uses a new "dancingbits" code, which prevents the execution of diskboot.bin. But it has the same dancingbits code as one of the previous models { 5,3,6,1,2,7,0,4 }.
Can you test a diskboot encoded with this that just turns on an LED ?
This NEED_ENCODED_DISKBOOT=2 btw, like sx200.
-
Looks like dumping has been done already... Congratulations, ERR99!
That is OK, the effort was not wasted.
Now, at least two people are interested in taking this further.
Incidentally, you could still try pointing the TV remote at the phototransistor to see what happens.
I don't seem to have any phototransistors right now.
-
-
For the benefits of those who will be browsing this thread in the future, can you explain your hardware setup and exact code used in some detail ?
Sure, i used this setup:
1. Hardware: The "serial port download solution" from the wiki. http://chdk.wikia.com/wiki/File:UART_receiver.jpeg# (http://chdk.wikia.com/wiki/File:UART_receiver.jpeg#)
This is the simple build with only a 10 kOhm resistor and a SFH 300-3/4 photodiode.
I placed the photodiode direct in front of the G11 AF-Light (ca. 2 cm distance or so..).
Then i tested if the photodiode works as it should be, in the readme of the COM-Port software (Blinker_Java_Version_by_Syrius\by_grand_blink_g7) is described how to do that.
(Measure the voltage between comport GND(Pin 5) and RX(Pin 2)).
2. Software: If modified the dumper software from grand_blink, so that this software permant sends infinity the same string with 9600 baud. So i could use a terminal programm to check if i can receive the text string or not and find the best distance between G11 and the photodiode. First i received only garbage, but than i doubled the delay value in the dumper software and i got a errorfree transmission. Then is switched back to the normal dumper code and started the firmware dump session with load.exe.
Bottomline: For the grand_blink dumper code, only the change of the LED address and of the delay value was necessary, and than it works. :)
For the java dumping tool (with crc-check and so), there was only the change of the LED adress necessary. I used here the default value define for 9600 Baud, and it fits also to the G11.
I also tested the Photodiode on the Mic-input of the soundcard. I got here also fine peaks with the G11-AF Light, so i think this readout methode should also work fine. The SFH 300-3/4 photodiode is now my favourite for firmware dumping via LED. ;)
-
Okay, and here is my full 8MB Flash dump of the Canon G11 GM1.00J Firmware:
G11_GM100J_8MB.zip - 2.59MB (http://www.zshare.net/download/70595027e5bb4b30/)
-
So, it ends at 0x007eb9af ?
-
Looks like a complete dump to me.
DRYOS version 2.3, release #0039 <- this means it's probably like ixus200, sx20, with many functions different from earlier cameras.
-
@ERR99: congratulations !
Added the G11 1.00j dump from this post (http://chdk.setepontos.com/index.php/topic,4647.msg45319.html#msg45319) (8MB dump, blinked out by ERR99) to the drop.io - chdkdumps2 (http://drop.io/chdkdumps2) backup archive.
http://drop.io/chdkdumps2/asset/g11-100j-7z
Thx to the 'dumpers' & uploaders !
-
Hmmm .. it is causing IDA to hang.
I will try again 'tomorrow'.
-
I took allready a look into the code, to check if the G11 uses a new "dancingbits" code, which prevents the execution of diskboot.bin. But it has the same dancingbits code as one of the previous models { 5,3,6,1,2,7,0,4 }.
Can you test a diskboot encoded with this that just turns on an LED ?
This NEED_ENCODED_DISKBOOT=2 btw, like sx200.
Before if try to dump via LED, i allready used the dancingbit exe with all encoding variants (1,2,3) on my blinker software,but is did not start. But anyway, i will try it again now. ;)
BTW: In my previous post, i copy&pasted the wrong dancing bit code. In the G11 Firmware this one is used: { 2,5,0,4,6,1,3,7 }
(You can find it at 0xFFBBA698 in G11 firmware). So the correct dancingbits encoding number should be three, as used for ixus200_sd980, sx20.
-
So, it ends at 0x007eb9af ?
I loaded the firmware into IDA with this values, and it works:
Startaddress: 0xFF810000
Length: 0x7EFFFC
-
I took allready a look into the code, to check if the G11 uses a new "dancingbits" code, which prevents the execution of diskboot.bin. But it has the same dancingbits code as one of the previous models { 5,3,6,1,2,7,0,4 }.
Can you test a diskboot encoded with this that just turns on an LED ?
This NEED_ENCODED_DISKBOOT=2 btw, like sx200.
Before if try to dump via LED, i allready used the dancingbit exe with all encoding variants (1,2,3) on my blinker software,but is did not start. But anyway, i will try it again now. ;)
BTW: In my previous post, i copy&pasted the wrong dancing bit code. In the G11 Firmware this one is used: { 2,5,0,4,6,1,3,7 }
(You can find it at 0xFFBBA698 in G11 firmware). So the correct dancingbits encoding number should be three, as used for ixus200_sd980, sx20.
reyalp, you are right! With dancingbits encoding 3, i can start my LED flashing program direkt via the diskboot.bin boot methode! Hmm, strange, i allready tried this before, but maybe i messed up something in my previous run.
Anyway, this is good and means we have a got chance to startup CHDK as usual. :)
-
Wow you guys rock! Great work!
Let me know if I can donate anywhere.
-
I have made a custom build of the udumper, to check why it is not working to dump directly so SD card.
So i encoded my build with dancingbits encoding 3 and used some of the G11 LEDs, to see how far the
code is executed.
As far i can see, the search for the write function signature fails, and thats the reason for the not working udumper.
The if clause does not find a hit:
for (i=0x1900;i<0xF0000;i+=4)
if ((*(unsigned int*)(i+0x34)==0) &&
(*(unsigned int*)(i+0x38)==0) &&
(*(unsigned int*)(i+0x3C)==3) &&
(*(unsigned int*)(i+0x4C)>MIN_ADDRESS) &&
(*(unsigned int*)(i+0x50)>MIN_ADDRESS) ) an so the program execution ends in the endless while(1); loop of the udumper main.c.
-
I loaded the firmware into IDA with this values, and it works:
Startaddress: 0xFF810000
Length: 0x7EFFFC
Well, I have now tried with the drop.io version and that does at least load.
The DRYOS signatures do not work, the whole process completes in about 30 seconds.
-
I loaded the firmware into IDA with this values, and it works:
Startaddress: 0xFF810000
Length: 0x7EFFFC
Well, I have now tried with the drop.io version and that does at least load.
The DRYOS signatures do not work, the whole process completes in about 30 seconds.
Which script do you use? If i start the dryos script, it finds roundabout 600 Signatures in the G11 firmware.
-
How long did it take ?
The DRYOS CHDK.idc script :-
#include <idc.idc>
#include "scan-code.idc"
#include "scan-tasks.idc"
#include "scan-events.idc"
#include "scan-strings.idc"
#include "scan-refs.idc"
static main()
{
auto sb, se, b;
Message("*** START OF ANALYSIS ***\n");
// b = Batch(1);
sb = MinEA();
se = MaxEA();
Message("Searching for code...\n");
MakeCode(sb);
findCode2(sb, se);
Message("Please wait...\n");
Wait();
Message("Searching for tasks...\n");
findTasks(sb, se);
Message("Please wait...\n");
Wait();
Message("Searching for events...\n");
findEvents(sb, se);
Message("Please wait...\n");
Wait();
Message("Searching for strings...\n");
MakeStr(sb+4, BADADDR);
findStrings(sb, se);
Message("Please wait...\n");
Wait();
Message("Searching for references...\n");
findRefs(sb, se);
Message("Please wait...\n");
Wait();
// Batch(b);
Message("*** END OF ANALYSIS ***\n");
}
-
The DRYOS script take a few minutes to finish. But did you load before the DryOs Signature File (CanonFW_DryOS_A-Series.sig) as described in the Wiki?
-
@Microfunguy
The signatures and also the idc scripts are working fine on this dump, the same way as on the others...
- load the dump in IDA pro, as binary file, ARM processor, macros disabled
- start address & loading address: 0xFF810000, ROM size: 0x003FFFFF
- edit the segment offset: ALT+S in IDA, set End address to 0xFFFFFFFE <-- !
- apply the dryos signatures
- run the main CHDK idc script, use the package from here (http://drop.io/chdkdevelopment/asset/ida-chdk-idc-dryos-singlerun-7z-7z)
(read more about IDA macros & the single-run script here (http://chdk.wikia.com/wiki/Sx10#For_Developers))
-
Yes, I have already done all that.
I will download the script again and try later.
EDIT:
- edit the segment offset: ALT+S in IDA, set End address to 0xFFFFFFFE <-- !
Forgot that !
-
-
I think the next steps to do are described here: http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera (http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera)
I started to follow the steps, and checked out the current CHDK cvs and added the G11 platform (based on the G9) and started to adapt the led adresses, MEMIOSET and this stuff. So far, i can compile a G11 CHDK DISKBOOT.BIN dummy project and i am currently reached the "Implementing the CHDK boot process" step in the Wiki. This means currently i reached the step, that my "platform/g11/main.c" code gets called if i start my DISKBOOT.BIN CHDK build on the G11. :)
To get CHDK compiled for the G11 platform, i had to add this stubs to stubs_entry2.s, because the automatic
signature finder in the build process was not able to find them:
NHSTUB(EnterToCompensationEVF, 0x12345678)
NHSTUB(ExitFromCompensationEVF, 0x12345678)
NHSTUB(Lseek, 0x12345678)
NHSTUB(PT_PlaySound, 0x12345678)
NHSTUB(RefreshPhysicalScreen, 0x12345678)
NHSTUB(Remove, 0x12345678)
NHSTUB(TurnOffBackLight, 0x12345678)
NHSTUB(TurnOnBackLight, 0x12345678)
NHSTUB(UIFS_WriteFirmInfoToFile, 0x12345678)
NHSTUB(kbd_pwr_on, 0x12345678)
NHSTUB(openfastdir, 0x12345678)
NHSTUB(readfastdir, 0x12345678)
NHSTUB(rename, 0x12345678)
NHSTUB(SetScriptMode, 0x12345678)
NHSTUB(apex2us, 0x12345678)
NHSTUB(MakeAFScan, 0x12345678)
NHSTUB(ExpCtrlTool_StartContiAE, 0x12345678)
NHSTUB(WriteSDCard, 0x12345678)
NHSTUB(UnlockAF, 0x12345678)
NHSTUB(DoAFLock, 0x12345678)
NHSTUB(rewinddir, 0x12345678)
NHSTUB(SetZoomActuatorSpeedPercent, 0x12345678)
NHSTUB(Unmount_FileSystem, 0x12345678)
NHSTUB(Mount_FileSystem, 0x12345678)
NHSTUB(GetKbdState, 0x12345678)
NHSTUB(UnsetZoomForMovie, 0x12345678)
NHSTUB(PutInNdFilter, 0x12345678)
NHSTUB(PutOutNdFilter, 0x12345678)
NHSTUB(GiveSemaphore, 0x12345678)
So it would ne nice if someone with CHDK development skills can help to find the addresses of this function in the firmware dump.
But okay, thats enough G11 development for this year.
:PHappy new year CHDK community! :P
-
Many of these are not needed right away (for example apex2us is only needed when you implement extra long exposure support, and the address will be found as part of this process). However, I suggest using an address that points to a BX LR rather than 0x123...
You also need to verify functions that are found, but without a 100% match (or with a 100% match but multiple alternatives).
Great work so far :)
-
for example apex2us is only needed when you implement extra long exposure support,
Why is the branch to an address in the Canon code replaced by the same address as the value of apex2us ?
For some reason, with my various builds the compiler always complains it cannot find apex2us so I just leave the original branch to an address.
@ERR99
The compiler will only complain if certain stub values are missing.
If you provide a list (or a number of lists) of what addresses you want to find I will certainly try by comparing with the G11.
I may need guidance on how to find certain values.
If you have a number of lists maybe people can volunteer to work on each one.
It is very useful that you describe your progress step-by-step, it will help other porters in the future.
-
Why is the branch to an address in the Canon code replaced by the same address as the value of apex2us ?
In CHDK, the call in expdrvtask goes to the CHDK version (apex2us in wrappers.c, no _), which in turn either sets the override value, or simply calls on to the original canon _apex2us that was found in the original expdrvtask.
-
(accessing the forum is becoming a bit of a pain, it is unavailable for long periods).
@ERR99
Here are some stubs for you :-
NHSTUB(rewinddir, 0xFF849478) // null_sub, not needed
NHSTUB(Unmount_FileSystem,0xFF849478) // null_sub, not needed
NHSTUB(WriteSDCard, 0xFF94B750) // below "SdDrv.c"
NHSTUB(UnlockAF, 0xFF837190) // 'AFUL'
NHSTUB(DoAFLock, 0xFF837158) // 'AFL'
NHSTUB(SetZoomActuatorSpeedPercent, 0xFF849478) // nullsub
NHSTUB(GetKbdState, 0xFF860430)
NHSTUB(UnsetZoomForMovie,0xFF99CE28)
NHSTUB(PutInNdFilter, 0xFFB00F1C)
NHSTUB(PutOutNdFilter, 0xFFB00F54)
NHSTUB(GiveSemaphore, 0xFF838E38)
Can I suggest that you post packages (A,B, C etc) each containing four of five stubs that you would like found.
Volunteers can then confirm they will work with a particular package.
This will save duplication of effort.
If any stub cannot be found in a reasonable amount of time, it can be transferred to a special package that people will know requires a bit more effort.
So, name your next packages !
-
Hello,
thanks for the stubs, i added them to my g11 implementation.
So, status is: I followed the steps in "Implementing the CHDK boot process" wiki and reimplement the first couple of functions for the G11 boot loader (boot.c and resetcode/main.c) and i think it was sucessfull. With CHDK spy task disabled, the camera reacts now as in the wiki decribed: " Once you have got the boot code ready, the camera should boot normally again. (Only difference is probably that a short press on the power-button gives you the review mode now. ) ".
Then i added the spytask hooks in boot.c (CreateTask_spytask();). But then i got trouble, the core_spytask() function
seems to crash and the camera switches off automaticaly. If i make end endless loop with a little led blinker code in this function before the call of conf_restore(); the camera stays on an blinks. But at execution of conf_restore() the system chrashes. If find out that if have something to do with conf_info.func() in conf.c. Some one of this callbacks must lead to a exception, because when i comment the function call out, conf_restore() does not crash. But even then the core_spytask() crashes in one of the next function calls behind of conf_restore().
So the good think is, the CHDK Task starts to run on the G11 (at least a little bit ;) ), but there must be a error in the configuration or somethin like that.
Something seems to be wrong, but currently i have no clue what it is. Maybe a wrong function signature?
reyalp said: "You also need to verify functions that are found, but without a 100% match (or with a 100% match but multiple alternatives)."
So task A could be to check the stubs_entry.S functions which does not have a 100% match:
// !!! THIS FILE IS GENERATED. DO NOT EDIT. !!!
#include "stubs_asm.h"
NSTUB(AllocateMemory, 0xffaa353c)
NSTUB(AllocateUncacheableMemory, 0xff83941c)
NSTUB(Close, 0xff8359b0)
NSTUB(CreateTask, 0xff81e5b4)
NSTUB(DeleteFile_Fut, 0xff83533c)
// ERROR: EnterToCompensationEVF is not found!
NSTUB(ExecuteEventProcedure, 0xff88997c)
// ERROR: ExitFromCompensationEVF is not found!
// Best match: 57%
NSTUB(ExitTask, 0xff81e844)
NSTUB(Fclose_Fut, 0xff8354b8)
NSTUB(Feof_Fut, 0xff8356a4)
NSTUB(Fflush_Fut, 0xff8356e0)
NSTUB(Fgets_Fut, 0xff83560c)
NSTUB(Fopen_Fut, 0xff835478)
NSTUB(Fread_Fut, 0xff835564)
NSTUB(FreeMemory, 0xffaa3534)
// Best match: 91%
NSTUB(FreeUncacheableMemory, 0xff83945c)
NSTUB(Fseek_Fut, 0xff835658)
NSTUB(Fwrite_Fut, 0xff8355b8)
// Best match: 52%
NSTUB(GetBatteryTemperature, 0xff8635d8)
// Best match: 52%
NSTUB(GetCCDTemperature, 0xff863564)
// Best match: 85%
NSTUB(GetCurrentAvValue, 0xff95c230)
NSTUB(GetDrive_ClusterSize, 0xff86fc80)
NSTUB(GetDrive_FreeClusters, 0xff86fce0)
NSTUB(GetDrive_TotalClusters, 0xff86fcb4)
// Best match: 64%
NSTUB(GetFocusLensSubjectDistance, 0xff95a804)
NSTUB(GetFocusLensSubjectDistanceFromLens, 0xff95ac4c)
// Best match: 96%
NSTUB(GetOpticalTemperature, 0xff86364c)
// Best match: 66%
NSTUB(GetParameterData, 0xff99687c)
// Best match: 72%
NSTUB(GetPropertyCase, 0xff88d6b0)
// Best match: 96%
NSTUB(GetSystemTime, 0xffaa3594)
// Best match: 74%
NSTUB(GetZoomLensCurrentPoint, 0xff95ee0c)
NSTUB(GetZoomLensCurrentPosition, 0xffa967a0)
// Best match: 64%
NSTUB(IsStrobeChargeCompleted, 0xff8db3f0)
NSTUB(LocalTime, 0xff887278)
// Best match: 93%
NSTUB(LockMainPower, 0xff895344)
// ERROR: Lseek is not found!
// Best match: 92%
NSTUB(MakeDirectory_Fut, 0xff8353b0)
// Best match: 57%
NSTUB(MoveFocusLensToDistance, 0xffb031cc)
// Best match: 58%
NSTUB(MoveZoomLensWithPoint, 0xffaa0b60)
// Best match: 62%
NSTUB(NewTaskShell, 0xff88d15c)
NSTUB(Open, 0xff835958)
// ERROR: PT_PlaySound is not found!
// Best match: 86%
NSTUB(PostLogicalEventForNotPowerType, 0xff893170)
// Best match: 92%
NSTUB(PostLogicalEventToUI, 0xff8931bc)
NSTUB(Read, 0xff81ab78)
NSTUB(ReadFastDir, 0xffa84270)
// ERROR: RefreshPhysicalScreen is not found!
// ERROR: Remove is not found!
// Best match: 53%
NSTUB(RenameFile_Fut, 0xff835474)
// ALT: NSTUB(RenameFile_Fut, 0xffa7057c) // 8/7
// ALT: NSTUB(RenameFile_Fut, 0xffa705cc) // 8/7
// Best match: 93%
NSTUB(SetAutoShutdownTime, 0xff8953b8)
// Best match: 81%
NSTUB(SetCurrentCaptureModeType, 0xff89cb1c)
// Best match: 55%
NSTUB(SetFileTimeStamp, 0xff94a8dc)
// Best match: 64%
NSTUB(SetLogicalEventActive, 0xff895094)
// Best match: 68%
NSTUB(SetParameterData, 0xff996758)
// Best match: 89%
NSTUB(SetPropertyCase, 0xff88d5ac)
// Best match: 92%
NSTUB(SleepTask, 0xff8390a0)
// Best match: 60%
NSTUB(TakeSemaphore, 0xff838d68)
// ERROR: TurnOffBackLight is not found!
// ERROR: TurnOnBackLight is not found!
// ERROR: UIFS_WriteFirmInfoToFile is not found!
// Best match: 93%
NSTUB(UnlockMainPower, 0xff895298)
NSTUB(UpdateMBROnFlash, 0xff813f74)
NSTUB(VbattGet, 0xff831e08)
NSTUB(Write, 0xff835a40)
NSTUB(_log, 0xffb3de8c)
NSTUB(_log10, 0xffb3cdd0)
NSTUB(_pow, 0xffb3cf40)
NSTUB(_sqrt, 0xffb3f1f4)
NSTUB(close, 0xff81a990)
NSTUB(closedir, 0xffa840f8)
// Best match: 71%
NSTUB(closefastdir, 0xffa8440c)
// Best match: 95%
NSTUB(free, 0xff814138)
// Best match: 86%
NSTUB(kbd_p1_f, 0xff833600)
// Best match: 86%
NSTUB(kbd_p1_f_cont, 0xff83360c)
// Best match: 86%
NSTUB(kbd_p2_f, 0xff832ec0)
// Best match: 51%
NSTUB(kbd_pwr_off, 0xff86043c)
// ERROR: kbd_pwr_on is not found!
// Best match: 84%
NSTUB(kbd_read_keys, 0xff833584)
// Best match: 78%
NSTUB(kbd_read_keys_r2, 0xff85fbb8)
// ALT: NSTUB(kbd_read_keys_r2, 0xff85fb9c) // 17/5
NSTUB(lseek, 0xff835acc)
NSTUB(malloc, 0xff8140dc)
NSTUB(memcmp, 0xff8203ec)
NSTUB(memcpy, 0xff83ea1c)
NSTUB(memset, 0xffa13910)
NSTUB(mkdir, 0xff835e24)
NSTUB(mktime_ext, 0xff8ab050)
NSTUB(open, 0xff81a8e0)
NSTUB(opendir, 0xffa8413c)
// ERROR: openfastdir is not found!
NSTUB(qsort, 0xffaf38dc)
// Best match: 95%
NSTUB(rand, 0xff8204f4)
NSTUB(read, 0xff81ab78)
// ERROR: readfastdir is not found!
// ERROR: rename is not found!
// Best match: 95%
NSTUB(srand, 0xff8204e8)
NSTUB(stat, 0xff835b08)
// ALT: NSTUB(stat, 0xff86d0c4) // 30/0
// Best match: 61%
NSTUB(strcat, 0xff813f38)
// Best match: 56%
NSTUB(strchr, 0xff813fc0)
NSTUB(strcmp, 0xff8203a8)
NSTUB(strcpy, 0xff820390)
NSTUB(strftime, 0xff8aaa58)
NSTUB(strlen, 0xff81400c)
NSTUB(strncmp, 0xff813f74)
// Best match: 73%
NSTUB(strncpy, 0xff813f38)
// Best match: 71%
NSTUB(strrchr, 0xff83e9f4)
// ALT: NSTUB(strrchr, 0xff8aa820) // 18/8
// Best match: 96%
NSTUB(strtol, 0xff83ecfc)
NSTUB(strtolx, 0xff83eb00)
// Best match: 86%
NSTUB(time, 0xff8877f0)
NSTUB(vsprintf, 0xff820354)
NSTUB(write, 0xff81abd8)
-
Can you comment-out nearly all of the body of spytask ?
I vaguely remember doing this recently when I had problems with a camera that crashed on startup.
In fact, in a call to some gui refresh code the address of a single firmware function was incorrect in the CHDK build but not used by it.
SDM did use that function.
-
I tracked down the crash to this position:
static void gui_handle_splash(void) {
static char *logo = NULL;
static int logo_size;
if (gui_splash) {
static int need_logo=1; // don't use logo ptr, since we don't want to keep re-trying
if(need_logo) {
const char *logo_name="A/CHDK/DATA/logo.dat";
FILE *fd;
struct stat st;
need_logo=0;
if (stat(logo_name,&st) == 0) {
logo_size=st.st_size;
logo=malloc(logo_size);
if(logo) {
fd = fopen(logo_name, "rb");
It looks like that the first file access try: fopen(logo_name, "rb") crashes this funktion.
One question: Is it important for the CHDK boot on a 2GB FAT card that a comleted modified "init_file_modules_task".
is hooked in taskCreateHook()? I am currently dissambled this function only to the point where ""BL core_spytask_can_start\n" has to be added. But i leaved out DataGhost's FAT32 autodection code, because i think it is not necessary now.
But obviously, the filesystem access is not working properly.
-
Is it important for the CHDK boot on a 2GB FAT card that a comleted modified "init_file_modules_task".
is hooked in taskCreateHook()?
Don't know.
Others will know.
filesystem access is not working properly.
I would comment-out the splashscreen and load configs for now.
Are any folders created on startup (assuming you start with no folders on the card) ?
-
Good hint.
I commented out the splash_screen and config loading stuff and the G11 stays now ON and does not crash.
The G11 behaves now so after press of the ON/OFF button:
- Boot takes a little more time as started without CHDK and some LEDs are blinking during boot. :)
- Camera starts in Play/Review mode (shows "No Image" screen) and shows for a few seconds "card locked" message.
- I cant take any pictures, because card is locked in record mode.
Do you know in which part of the CHDK is the write to SD card re-enabled, so i can get rif of the "card lock" message?
Also, no other sign of a running CHDK is visible on the display, camera display shows only the "srtandard" controls.
I also started my build without a CHDK folder and after startup, there a no folders created. So the mkdir("A/CHDK");
calls in main.c are not working now. But at least, they doesnt crash. ;)
(I think this is caused by the "locked" read-only state of the sd-card and so write access for mkdir is disabled)
-
Do you know in which part of the CHDK is the write to SD card re-enabled
It is in platform\g11\kbd.c.
For the G9 :-
#define SD_READONLY_FLAG (0x20000)
if (conf.remote_enable) {
physw_status[2] = physw_status[2] & ~(SD_READONLY_FLAG | USB_MASK);
}
else
physw_status[2] = physw_status[2] & ~SD_READONLY_FLAG;
You need to know the physw_status bit position for the SD card, or just guess.
I am not familiar with CHDK (as opposed to SDM) but somewhere you can uncomment some code to display the Misc values.
These show physw_status[0], physw_status[1] and physw_status[2].
You will need to display it anyway to map the keys.
the mkdir("A/CHDK");
calls in main.c are not working now. But at least, they doesnt crash.
(I think this is caused by the "locked" read-only state of the sd-card and so write access for mkdir is disabled)
Yes, that is likely.
If the keyboard task is not hooked you cannot enter the menus .....
Hmm , you cannot anyway because the keys are not mapped yet.
-
Okay, i will take a look on the kbd files. Currently i commented out the hooks for this functionality.
BTW: If i have some JPEGs on the camera, and i start the camera with CHDK running, the camera is not longer able
to show this pictures in review mode. Instead the message "Unidentified Image" is shown. So it looks like that the file access is also for the "normal" dryos/firmware not longer working when my diskboot.bin is started. :blink:
-
Okay, i will take a look on the kbd files. Currently i commented out the hooks for this functionality.
Aaaahh .. so maybe the card-lock override will work .. or crash the camera.
If it crashes, you just have to guess the bit position based on other cameras.
EDIT:
I have looked at a dozen recent cameras and all use 0x20000 mask for SD card.
In IXUS100 kbd.c is the comment :-
#define SD_READONLY_FLAG (0x20000) // 1 << 0x11
Not sure what that refers to.
EDIT2:
As you do not know the mask for the USB it may crash.
May be better to just apply the SD card mask on its own for now.
-
One question: Is it important for the CHDK boot on a 2GB FAT card that a comleted modified "init_file_modules_task".
is hooked in taskCreateHook()? I am currently dissambled this function only to the point where ""BL core_spytask_can_start\n" has to be added. But i leaved out DataGhost's FAT32 autodection code, because i think it is not necessary now.
In fact you don't even need that much, because CHDK will start after a timeout anyway. ISTR that you can leave the init_file_modules_task out entirely, but I may be misremembering.
-
I have looked at a dozen recent cameras and all use 0x20000 mask for SD card.
In IXUS100 kbd.c is the comment :-
#define SD_READONLY_FLAG (0x20000) // 1 << 0x11
Not sure what that refers to.
Okay, i found a event procedure in the FW, named "GetSDProtect". I was so able to find the base
address for physw_status[] and also the mask for SDProtect switch. It is also 0x20000.
The "1 << 0x11" refers to this shift&mask command in GetSDProtect() i think:
"AND R0, R0, R3,LSL R1"
Because in the G11 code this results to "R0 = R0&(R3<<R1)" with R1=0x11 and R3=0x1.
I also managed to replace the original KbdTask with mykbd_task() and hooked in my own my_kbd_read_keys() function. To keeps things simple, i modfied this function to only call _GetKbdState(kbd_new_state), then i copied kbd_new_state[] to physw_status[] and exit the function.
Camera keys works normaly. For testing i then removed the physw_status[] copy, and the G11 are not responding to any keypress anymore. So hooking in here looks successfull.
Then i added here "physw_status[2] = physw_status[2] & ~SD_READONLY_FLAG;", but this have not any effect. I still got the "Card locked" message.
-
It would be useful if debugging information could be displayed on the screen and also Misc values (the physw_status[] values).
For that, the bitmap buffer address (in \platform\sub\..\lib.c) has to be correct.
I don't know if these apply to the G11, but other have noted :-
For SX200 :
void *vid_get_bitmap_fb()
{
return (void*)0x403F1000; // found at FF842AC4 and FFA2BED4
For IXUS100:
//SD780 - - Search for ; LOCATION: BmpDDev.c:138 - First LDR
void *vid_get_bitmap_fb()
{
return (void*)0x403F1000;
}
-
Then i added here "physw_status[2] = physw_status[2] & ~SD_READONLY_FLAG;", but this have not any effect. I still got the "Card locked" message.
Probably best to post the full my_kbd code.
In loader\entry.s the SD card power is turned off.
Is that relevant ?
-
I don't know if these apply to the G11, but other have noted :-
Nope, that adresses does not match for the G11. But i think if found the correct address for the G11:
void *vid_get_bitmap_fb()
{
return (void*)0x40471000;
}
Because fileaccess is not working, i compiled the CHDK logo.dat directed into the code as a static array and i am calling direct this function now:
gui_draw_splash(err99_logo,err99_logo_size);Result is: I can see some funny colored lines on the screen. ;) But the logo looks scrambled, i think the screen height/width values in lib.c are not correct (what i expected, because the G11 has a higher resolution display then the G9). But until now i dont found the correct values for this.
-
I did not mean the buffer address would be the same, I was just suggesting a way of finding correct address.
In the early days, bitmap buffers were simple, they were 360x240, the same as the physical screen.
Now, there are a number of different arrangements.
One camera is 720x240, every pixel is drawn twice in the 'x' direction.
In other cameras, the buffer is far bigger than the area that is rendered to the screen.
The screen area is top left part of the buffer.
One camera has a 320 wide physical screen and 720 wide buffer and each pixel is drawn 9/4 times in the 'x' direction.
I have some simple test code, I will look for it.
-
For what it is worth here is some code that may suggest further tests :-
// -- -----------------------------------------------------------------
// Test writing rectangle to BMP buffer
//--------------------------------------------------------------------
int offset=80*screen_buffer_width;
scr_buf = vid_get_bitmap_fb();
if (!imgbuf) allocate_imgbuf();
if(imgbuf)
{
// img_buf = vid_get_viewport_live_fb();
// if( !img_buf )
// {
// img_buf = vid_get_viewport_fb();
// }
memset(imgbuf,COLOR_TRANSPARENT,ss); // clear screen
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss, imgbuf, ss); // update second buffer
for(x=0;x<120;x++)
{
for(y=0;y<80;y++) // for each row
{
imgbuf[(120*2)+2*x+(y*screen_buffer_width)+offset]=COLOR_RED; // from x=120 to x=240
imgbuf[(120*2)+2*x+(y*screen_buffer_width)+offset+1]=COLOR_RED;
}
}
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss,imgbuf,ss);// update second buffer
return 1;
}
return 0;
There are two possible bitmap buffers and as we do not know which is being used at any instant you have to write to both.
-
Then i added here "physw_status[2] = physw_status[2] & ~SD_READONLY_FLAG;", but this have not any effect. I still got the "Card locked" message.
Probably best to post the full my_kbd code.
In loader\entry.s the SD card power is turned off.
Is that relevant ?
This is my function:
void my_kbd_read_keys()
{
kbd_new_state[0] = physw_status[0];
kbd_new_state[1] = physw_status[1];
kbd_new_state[2] = physw_status[2] & ~SD_READONLY_FLAG;
_GetKbdState(kbd_new_state);
physw_status[2] = kbd_new_state[2] & ~SD_READONLY_FLAG;
_GetKbdState2(kbd_new_state);
physw_status[0] = kbd_new_state[0];
physw_status[1] = kbd_new_state[1];
physw_status[2] = kbd_new_state[2] & ~SD_READONLY_FLAG;
}
One difference to the G9 Code is, that it is not enough to simply call _GetKbdState(), i also have to call the second function
that is called in the G11 Code, here, because not all keys are working if i only call _GetKbdState():
ROM:FF833584 sub_FF833584 ; CODE XREF: phy_func+2Cp
ROM:FF833584 ; kbd_p1_f+8p
ROM:FF833584 78 21 1F E5 LDR R2, =0x32578 ; Load from Memory
ROM:FF833588 10 40 2D E9 STMFD SP!, {R4,LR} ; Store Block to Memory
ROM:FF83358C 02 00 A0 E3 MOV R0, #2 ; Rd = Op2
ROM:FF833590 00 10 A0 E3 MOV R1, #0 ; Rd = Op2
ROM:FF833594
ROM:FF833594 loc_FF833594 ; CODE XREF: sub_FF833584+18j
ROM:FF833594 00 11 82 E7 STR R1, [R2,R0,LSL#2] ; Store to Memory
ROM:FF833598 01 00 50 E2 SUBS R0, R0, #1 ; Rd = Op1 - Op2
ROM:FF83359C FC FF FF 5A BPL loc_FF833594 ; Branch
ROM:FF8335A0 94 01 1F E5 LDR R0, =0x32578 ; Load from Memory
ROM:FF8335A4 9E B3 00 EB BL GetKbdState ; Branch with Link
ROM:FF8335A8 9C 01 1F E5 LDR R0, =0x32578 ; Load from Memory
ROM:FF8335AC 10 40 BD E8 LDMFD SP!, {R4,LR} ; Load Block from Memory
ROM:FF8335B0 77 B1 00 EA B sub_FF85FB94 ; Branch <------------------- _GetKbdState2()
It looks like, that canon has reduced the functionality of the _GetKbdState() function. Because if i compare this function from the G11 with the code of the G9, the functions is very reduced:
G11 Code:
ROM:FF860424
ROM:FF860424 GetKbdState ; CODE XREF: sub_FF833584+20p
ROM:FF860424 9C 10 9F E5 LDR R1, =0xC0220000 ; Load from Memory
ROM:FF860428 00 22 91 E5 LDR R2, [R1,#0x200] ; Load from Memory
ROM:FF86042C 00 20 80 E5 STR R2, [R0] ; Store to Memory
ROM:FF860430 04 22 91 E5 LDR R2, [R1,#0x204] ; Load from Memory
ROM:FF860434 04 20 80 E5 STR R2, [R0,#4] ; Store to Memory
ROM:FF860438 08 12 91 E5 LDR R1, [R1,#0x208] ; Load from Memory
ROM:FF86043C 01 18 A0 E1 MOV R1, R1,LSL#16 ; Rd = Op2
ROM:FF860440 21 18 A0 E1 MOV R1, R1,LSR#16 ; Rd = Op2
ROM:FF860444 08 10 80 E5 STR R1, [R0,#8] ; Store to Memory
ROM:FF860448 1E FF 2F E1 BX LR ; Branch to/from Thumb mode
ROM:FF860448 ; End of function GetKbdState
-
I would not spend any time on the splashscreen, you need to know how the bitmap buffer relates to the physical screen first.
You do that by drawing a permanent simple geometric shape, such as a square.
Do you know the bitmap buffer dimensions and also the size of the physical screen ?
-
Do you know the bitmap buffer dimensions and also the size of the physical screen ?
No exactly. But i think that the physical screen size is two times the size of the G9 display (because subpixel value is doubled between G9 & G11). So i assume that the physical display resolution is now 640x480.
I replaced the splash screen now with your draw rectangle code, but your code snippet was not complete. So is my "interpretation" of the code correct?:
void DrawRectangle(void)
{
int offset=80*screen_buffer_width;
static unsigned char* imgbuf = 0;
long ss = vid_get_bitmap_screen_width()* vid_get_bitmap_screen_height();
unsigned char* scr_buf = vid_get_bitmap_fb();
int x,y;
if (!imgbuf)
{
imgbuf = malloc(ss);
}
if(imgbuf)
{
memset(imgbuf,COLOR_TRANSPARENT,ss); // clear screen
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss, imgbuf, ss); // update second buffer
for(x=0;x<120;x++)
{
for(y=0;y<80;y++) // for each row
{
imgbuf[(120*2)+2*x+(y*screen_buffer_width)+offset]=COLOR_RED; // from x=120 to x=240
imgbuf[(120*2)+2*x+(y*screen_buffer_width)+offset+1]=COLOR_RED;
}
}
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss,imgbuf,ss);// update second buffer
return 1;
}
return 0;
}
With this code, and the values 640 and 480 for width and height, i get the attached picture on the G11 display.
-
I will look at that shortly.
For a pixel at x,y the location in the bitmap buffer is y*buffer_width + x or maybe y*buffer_width + 2*x.
In the latter case, you normally have to draw each pixel twice.
The buffer-width may or may not be greater than the width of the buffer that the Canon firmware renders to the screen.
In other words, just a top-left area of the buffer may be rendered to the screen.
-
So, 80*screen_buffer_width should get us 1/3rd the way down a 240 high screen area .. if the height is 240 and if the buffer width is correct.
That is the 'offset' value.
The start of the first screen buffer must be correct.
If not already allocated, you allocate an amount of memory equal in size to the screen buffer.
If that is allocated OK, you first clear both bitmap buffers by writing 'transparent' pixels to them.
For the next 80 rows, we draw pixels from x = 120 to x = 240.
That will be 1/3rd the screen if it is 360 wide.
The above code draws each pixel twice, normally for a 720 wide buffer or a wider buffer that uses 720 wide for the screen size.
Anyway, it is not correct for the G11 ;)
Try 360x240 screen and draw each pixel once in the 'x' direction.
-
There again, it really could be 640x480.
In which case, set intial offset to 160* screen_buffer_width and draw pixels from 160 to 320.
Pixel x,y at position 640*y + x.
Something like :-
void DrawRectangle(void)
{
int offset=160*screen_buffer_width;
static unsigned char* imgbuf = 0;
long ss = vid_get_bitmap_screen_width()* vid_get_bitmap_screen_height();
unsigned char* scr_buf = vid_get_bitmap_fb();
int x,y;
if (!imgbuf)
{
imgbuf = malloc(ss);
}
if(imgbuf)
{
memset(imgbuf,COLOR_TRANSPARENT,ss); // clear screen
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss, imgbuf, ss); // update second buffer
for(x=0;x<213;x++)
{
for(y=0;y<160;y++) // for each row
{
imgbuf[213+x+(y*screen_buffer_width)+offset]=COLOR_RED; // from x=213 to x=426
}
}
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss,imgbuf,ss);// update second buffer
return 1;
}
return 0;
}
-
Okay, with display&buffer dimensions 640x480 and your modified DrawRectangle function, i get this picture:
-
You may find it useful dump the entire bitmap buffer (or actually some arbitrary amount of memory starting at the bitmap address, since you don't know the actual resolution) to a file, and then examine it on the PC.
I wouldn't expect it to be 640x480, or necessarily the same as the G9 or any other particular camera. Note that in the G9, both the bitmap buffer and bitmap screen are 360x240 (edit: at least according to lib.c, I assume someone would have complained by now if it were wrong). The bitmap dimensions don't appear have any particular relationship to canons specs for LCD resolution, and the *buffer* dimensions are not necessarily the same as the bitmap resolution.
You might want to look at some of the other cameras with odd layouts, such as the sx200, sd990, tx1 to get some ideas about the different things canon does.
-
OK, to make it less confusing just draw a few pixels (enough to be easily visible) at various co-ordinates that could be the centre of the screen, starting with 320,240.
EDIT:
Draw a small group of pixels at various positions on the first row until they are in the middle of the screen area.
Then repeat with an offset of buffer width.
If the buffer width is correct the pixels will be directly underneath the first ones.
-
I think i made a little progress now. With a screen buffer dimension of 960x240, the pixels are underneath.
I used this function to draw 10 pixels (with one pixel space for better visibility):
void DrawLine(void)
{
int offset=0*screen_buffer_width;
static unsigned char* imgbuf = 0;
long ss = vid_get_bitmap_screen_width()* vid_get_bitmap_screen_height();
unsigned char* scr_buf = vid_get_bitmap_fb();
int x,y;
if (!imgbuf)
{
imgbuf = malloc(ss);
}
if(imgbuf)
{
memset(imgbuf,COLOR_TRANSPARENT,ss); // clear screen
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss, imgbuf, ss); // update second buffer
x = screen_buffer_width/2;
for (y=(240/2); y<(240/2)+20;y+=2)
{
imgbuf[x+(y*screen_buffer_width)]=COLOR_BLUE;
}
memcpy(scr_buf,imgbuf,ss);
memcpy(scr_buf+ss,imgbuf,ss);// update second buffer
return 1;
}
return 0;
}
So i think i have got the screen_buffer_width now. But something is strange:
The y position looks ok, it is one the middle of the display as expected. But the x position is not centred, i start drawing at 960/2, but the line is drawn in the right 1/3rd of the screen.
-
Am I missing something, the 'x' position looks centred ?
EDIT:
My CRT monitor is faulty and too dark.
I drag it onto the TFT and I can see what you mean.
EDIT:
So, the bitmap area used by the Canon firmware is the 720x240 left-side of the 960x240 buffer.
Note that in draw_init() in gui_draw.c :-
screen_width = vid_get_bitmap_width();
screen_height = vid_get_bitmap_height();
which is not the same as bitmap buffer width (apparently) for the G11.
-
For the book, here is the complete display screenshot. ::)
-
Just to confirm, put an absolute value for the 'x' position rather than half buffer width.
EDIT:
The screen width is 720.
Maybe you also have to draw each pixel twice.
I wonder if the bitmap height is 270 ?
This would then be the same as the IXUS100 that also uses a 720x240 area.
In SDM draw_pixel_std() :-
#if defined (CAMERA_ixus980) || defined(CAMERA_ixus100)
frame_buffer[0][y * screen_buffer_width + (x<<1)] = frame_buffer[1][y * screen_buffer_width + (x<<1)] = cl & 0xff; // draw two pixels side-by-side
frame_buffer[0][y * screen_buffer_width + (x<<1)+1] = frame_buffer[1][y * screen_buffer_width + (x<<1)+1] = cl & 0xff;
EDIT:
Try running the code you posted in reply #151 again now that you know the correct buffer width.
-
Okay, i will try this tomorrow. But here is something other:
CHDK Logo on the G11 (okay, it a little bit stretched, but anyway... :D )
-
Okay, i will try this tomorrow. But here is something other:
CHDK Logo on the G11 (okay, it a little bit stretched, but anyway... :D )
That's progress !
Another tedious task is to define record and playback colour palettes.
Hopefully the G11 has a reasonable range of colours, unlike the IXUS100.
You will soon be able to permanently display Misc values to inspect physw_status[].
-
It looks like it is similar to the SX200IS.
In \include\camera.h you need :
#define CAM_USES_ASPECT_CORRECTION 1
The default aspect-correction in the 'x' direction draws each pixel twice :-
#define ASPECT_XCORRECTION(x) ( ((x)<<1) )
That assumes the bitmap screen width is defined as 360 in g11\sub\.\lib.c
If the bitmap screen width is 320 you need to stretch by 9/4 :-
#define ASPECT_XCORRECTION(x) ( ( ((x)<<3) + (x) ) >>2 )
The pixel drawing function in gui_draw.c should then display all CHDK info correctly.
Also in camera.h, you can try try changing the palette number to see if any existing palettes are suitable.
If not, you will have to create a new one.
-
Good idea Microfungy!
I am using now the ASPECT_CORRECTION and BITMAP palette 3 and it looks not so bad now.
And another good thing has happend, the SD-Card write protect message is now also gone!
The mkdir() calls are now working and they creates the CHDK folders on the SD-Card.
I dont know if this is caused as a sideeffect of the framebuffer changes, or by the complette "gmake clean", i have done also before i started my new build. But anyway, its working. :lol
Anyway, the file read is still not working, so i dont have any fonts loaded now and cant print text to the screen.
-
And another good thing has happend, the SD-Card write protect message is now also gone!
Was that by magic ? :)
Anyway, the file read is still not working, so i dont have any fonts loaded now and cant print text to the screen.
I cannot remember, do you need file-reading for the built-in fonts ?
Maybe the file FUT function addresses are incorrect ?
To summarrise :
The G11 bitmap buffer is probably 960x270.
It uses the top-left 720x240 area for screen display.
The bitmap buffer screen with is 360, the height 240.
The pixel-drawing routine draws every pixel twice in the 'x' direction.
EDIT:
Just having a quick look at gui.c, the CHDK icon is loaded from a file :-
fd = fopen(logo_name, "rb");
So, that seems to work.
-
Ah, okay. I only seen the fonts folder in the CHDK subdirectory and guessed that the fonts come from here only.
But know if found the build-in font_8x16 files. But the draw_text functions are still not working. I think, this is maybe
caused by the disabled callback functions in conf_load_defaults() (i have to remove the conf_info.func() call, because system crashes here). So maybe the font_init() functions are not called and this could be the reason for the not working text draw functions.
I have to figure out whats crashing here, or at least which font functions i have to call/init to get working draw_text support.
The "fd = fopen(logo_name, "rb");" ist still not working, to show the CHDK Logo, i converted the logo.dat file into a char* array and compiled it staticly into the diskboot.bin.
-
Success, i added the call of this function:
void font_init() {
font_init_data(cp_common, 0, 128);
font_init_data(codepages[FONT_CP_WIN_1251], 128, 128);
}
and now draw_text is working! :)
-
Excellent !
Now you can print messages and examine values and work-out the key mapping.
-
Yes, this will be my next task.
But now, with prinft() support for debugging, i found something regarding the file load function.
The splashcreen loading does not fail because fread is now working, it is failing because stat() returns a filesize of zero.
if (stat(logo_name,&st) == 0) {
logo_size=st.st_size;
logo=malloc(logo_size);
if(logo) {
fd = fopen(logo_name, "rb");
So no memory is allocated and the file is not read. If i a "fake" the logo_size variable to the known file_size direct in the code,
fopen() & fread() are working and i can see the logo, loaded from the sd-card. So i think, i have to check the function address for stat().
-
Success, i added the call of this function:
I thought the only time that function is normally called is when you change the codepage ?
-
Not sure what this means :-
NSTUB(stat, 0xff835b08)
// ALT: NSTUB(stat, 0xff86d0c4) // 30/0
// Best match: 61%
Does that means it was found with 100% match ?
-
Yes, i have seen that there are two stat() functions found (both are not 100% hits), and i tryed allready both of them.
But stat() it still not working correctly, the returned filesize is in both cases zero.
-
Okay, i dumped the returned stat() structure of LOGO.dat into a file on the sd-card, and i think i found the problem.
It looks like, that the structure of "struct stat" has changed. I found the filesize in the binary dump now on another position.
In chdk struct stat, the item st_size is located unter st_ctime. In my dump, if found the size now unter st_ino.
struct stat
{
unsigned long st_dev; //?
unsigned long st_ino; //?
unsigned long st_size; // <--- New location
unsigned short st_mode; //?
short st_nlink; //?
short st_uid; //?
short st_gid; //?
unsigned long st_atime; //?
unsigned long st_mtime; //?
unsigned long st_ctime; //?
// unsigned long st_size; <--- Old location
long st_blksize; //?
long st_blocks; //?
unsigned char st_attrib;
int reserved1; //
int reserved2; //
int reserved3; //
int reserved4; //
int reserved5; //
int reserved6; //
};
If i am correct with my theorie here, then i am in doubt that this is maybe not the only change and possible more of the structure has changed.
-
Hmmm ... are there any tests you can do to determine the entire structure ?
Maybe you just need to find the location of the structure members that are used by CHDK ?
I guess you can just put a #if defined(CAMERA_g11) around the new structure.
In the 'old' days the FUT api was not used.
Not sure with which port that changed and why.
-
Okay, i will take a look on this later. I will now try to get the keys working.
I also managed to find out which function in conf_load_defaults() is crashing during load.
It is config entry number 65 (id=66):
CONF_INFO( 66, conf.menu_rbf_file, CONF_DEF_PTR, ptr:"", conf_change_menu_rbf_file),
If i skip this entry during loading in conf_load_defaults(), the function does not crash.
BTW: The current splashscreen at startup looks not so bad now. :)
-
You will know if the palette is suitable when you do the histograms.
You may be able to access the menus fairly soon.
I would guess the clock is working and you live in Germany !
static void conf_change_menu_rbf_file()
{
if (!rbf_load(conf.menu_rbf_file))
rbf_load_from_8x16(current_font);
rbf_set_codepage(FONT_CP_WIN);
}
Guess there is a problem with that.
rbf_load_from_8x16 is passed an array so no file opening there.
rbf_set_codepage is simply passed an integer value defining the codepage.
rbf_load is the one that opens a file.
So, because of the changed 'stat' structure any operation with files is going to cause a crash.
-
-
-
Remember to find the USB bit in physw_status[].
Just connect to the PC with the usual cable.
If you do not see any change the bit may be in the part of physw_status[2] that is masked.
Why does physw_status[1] have nine nibbles rather than eight ?
-
Yes, the USB bit stuff. Thanks for the hint, i will check this.
The one nibble you see on the screenshot is from a another debut output,
and not from the actual phy[1] output. I dont clear the hole framebuffer after a debug test write, so its normal
that sometimes old output survives. ;)
-
Yes, the USB-Bit (its #define USB_MASK (0x100000) for the G11) helps.
The camera is still easy to crash if i select something or try to open chdk menus, but anyway, there is progress visible... :D
-
So where was menu-entry crashing when you pressed PRINT button ?
-
Its not so easy to tell. The system crashes randomly if i play arround with the buttons.
If the system crashes, or freezes or startup normaly, depends currently on the content of the SD-Card.
Yesterday, i was able to startup the cam and make the posted screenshot.
Then i deleted some of the pictures on the sd-card (with the camera) and also shooted some new pictures this morning (while CHDK was running). I deleted again some JPEGs, and now, with the same diskboot.bin from yesterday, the G11 crashes&switches off before chdk splash screen is shown.
If i take some more pictures (chdk disabled by setting the write switch to write enabled) and starting again with CHDK enabled,
the camera starts, but at the point where normaly the splash screen is shown, the G11 freezes after 2 seconds and i have to remove the battery to reset the camera.
Very strange...
-
@ERR99:
Check the card's file system to make sure it's not corrupted...
-
Okay, i used checkdisk for a card inspection, but it does not find any errors.
Then i formated the SD-CARD again with Cardtricks and copied my CHDK folder and my diskboot.bin on the card.
And the camera started! Then i switched the camera off, and restarted again and it freezes at the Canon "PowerShot G11" startup screen. I did a compare with the SD-Card content and the CHDK folder on my harddisk, and i found a difference. It is the automaticly created CCHDK.CFG file. If i delete this files, the camera is starting again, until i shutdown the camera. Sometimes the camera is able to start, even if the file exists allready, but most of the time it crashes now. So something wie the config stuff seems to be the cause for the random crashes&freezes.
-
I did think of that but I thought you could not save files.
Maybe the problem is only opening files.
I would just keep deleting the CFG file for now.
I think in CHDK \core\gui.c there is a commented-out option to not autosave the CFG file.
EDIT:
Yes, at the top :-
#define OPTIONS_AUTOSAVE
-
Saving files works since the "SD Card protected" message dissapears. Now i have full file access and can read&write on the sd-card.
I disabled the AUTOSAVE feature now, and the camera start-up is now much more reliable. :)
I got now also a lot of CHDK menu visible, after i modified the function conf_change_menu_rbf_file() (instead of disabling this function complete, because it crashes at startup):
static void conf_change_menu_rbf_file() {
// if (!rbf_load(conf.menu_rbf_file))
rbf_load_from_8x16(current_font);
rbf_set_codepage(FONT_CP_WIN);
}
Now i am able to see a lot of nice CHDK menus.
-
Lets play. :D
-
The colors are looking not so good, i think the palette data needs to be updated.
-
Calendar is also so working.
The scripting does not seems to work, if i select a file it crashes the camera.
Or a try to show the memory usage also switches of the camera.
So a little more finetuning is needed i think. ::)
-
Looks good !
Oh no, not yet another palette needed ... could you post the playback palette as well for future reference ?
You will need it anyway.
-
The above palette schreenshot is the playback palette.
Here comes the screenshot for livemode:
-
Yes, that is a decent palette range with some good primary colours.
Some recent cameras, like the IXUS100, have palettes with quite a poor colour range, especially in playback.
It will soon be time to enable the image-capture task !
-
static void conf_change_menu_rbf_file() {
// if (!rbf_load(conf.menu_rbf_file))
rbf_load_from_8x16(current_font);
rbf_set_codepage(FONT_CP_WIN);
}
I now got also this function "not chrashing", by adding a "empty string" check:
int rbf_load(char *file) {
int fd;
char buf[8];
int i;
if (file[0] == 0) { <---------- Added check to avoid crash in open().
return 0;
}
fd = open(file, O_RDONLY, 0777);
if (fd>=0 && read(fd, &buf, 8)==8 /* Magic number */ && memcmp(&buf, RBF_HDR_MAGIC, 8)==0) {
read(fd, &rbf_font.name, RBF_MAX_NAME);
To avoid the 100% crash in the "memory usage" gui, i have to remove the second alloc/free while loop:
void gui_show_memory_info(int arg) {
static char buf[64];
int size, l_size, d;
char* ptr;
size = 16;
while (1) {
ptr= malloc(size);
if (ptr) {
free(ptr);
size <<= 1;
} else
break;
}
#if 0 <----------- disabled second while loop
l_size = size;
size >>= 1;
d=1024;
while (d) {
ptr = malloc(size);
if (ptr) {
free(ptr);
d = l_size-size;
if (d<0) d=-d;
l_size = size;
size += d>>1;
} else {
d = size-l_size;
if (d<0) d=-d;
l_size = size;
size -= d>>1;
}
#endf
}
sprintf(buf, lang_str(LANG_MSG_MEMORY_INFO_TEXT), size-1,MEMISOSIZE,&_start,&_end);
gui_mbox_init(LANG_MSG_MEMORY_INFO_TITLE, (int)buf, MBOX_FUNC_RESTORE|MBOX_TEXT_CENTER, NULL);
}
-
So why have no other CHDK builds crashed in rbf_load() ?
-
Don`t know for sure. May be a compare of the open function from the G11 firmware with the firmware of a G9 or so can help to understand this problem.
Reyalp wrote earlier:
"DRYOS version 2.3, release #0039 <- this means it's probably like ixus200, sx20, with many functions different from earlier cameras.
"
So it is not impossible that the behaviour of the open function has changed, i simply dont know. All what i know for sure is, that the camera does not crashes&switch off anymore when this check is added.
-
Yes, this appears to be a "feature" of the r39 cams. It was mentioned in the ixus200/sd980 thread: http://chdk.setepontos.com/index.php/topic,4228.0.html (http://chdk.setepontos.com/index.php/topic,4228.0.html)
It may save you some effort if you have a look through that and Radups other posts on the subject.
-
Useful thread, with its mention that the IXUS200 should be a new reference camera.
Also interesting : http://chdk.setepontos.com/index.php/topic,4228.msg41805.html#msg41805 (http://chdk.setepontos.com/index.php/topic,4228.msg41805.html#msg41805)
-
Thanks for the links. I read the thread and know i knew that this is "really" caused by r39 fw.
I now also merged the changes from RaduP (from the linked thread):
http://chdk.setepontos.com/index.php/topic,4228.msg41802.html#msg41802 (http://chdk.setepontos.com/index.php/topic,4228.msg41802.html#msg41802)
http://chdk.setepontos.com/index.php/topic,4228.msg41848.html#msg41848 (http://chdk.setepontos.com/index.php/topic,4228.msg41848.html#msg41848)
http://chdk.setepontos.com/index.php/topic,4228.msg41850.html#msg41850 (http://chdk.setepontos.com/index.php/topic,4228.msg41850.html#msg41850)
and now, e.g. the script fileselect dialog is not crashing anymore. :)
-
Can the config file be loaded on startup ?
So, is it time to enable the capture task ?
-
No, with configfile the camera crashes, or get freezed at startup.
I attached one of my "crashing" config files, looks this config file normal?
I currently dont have another CHDK capable camera here to compare.
I can find some printf() error/text strings in the configfile, so i think somthing went wrong here:
Snl %s: %d: in function '%s' in main chunk ? in function <%s:%d> level out of range flnSu
Also the CHDKConfig File Editor shows an error messsage if i load this cfg file (Error - unknown entry id=19268)
-
It stops at entry 183 in the conf file which should be the menu-symbol rbf file but is actually symbol enable.
Entry 62 should be symbol enable but is Menu Symbol RBF File
They seem to have been swapped around.
-
Thanks man!
This was the problem, because the config_load was chrashing previously (caused by the open()/empty string problem as we now know), i patched the config_load function to skip the crashing config IDs. And i have forgotten to remove this debug code after i merged the patches from RaduP.
Now i am using an non patched conf.c and config load&save seems now to work!
-
I don't know much about compiling or programming but I know just enough to be useful :)
-
You are very helpful Microfunguy. :)
And again i need some help. I try to get the caputure task running and it does not look so bad,
i got a 15MB raw file created on the SD-Card if i shoot with CHDK RAW feature active. But in raw_savefile()
the camera switches off. I find out that SetFileTimeStamp() causes the problem (it is called from utime(fn, &t) ) .
I took a look at this function and find out that the signature finder was not able to find the correct function address:
// Best match: 55% NSTUB(SetFileTimeStamp, 0xff94a8dc)
This address points into the middle of a function, so it is obviously wrong.
May be some one could help me and find the correct function pointer for SetFileTimeStamp()? (to avoid to nullsub the call)
-
How about 0xFF835C3C ?
As a matter of interest, why would you enable CHDK RAW support at all, why not exclude from the compilation ?
It is interesting that Canon state the RAW image is raw sensor data saved with ALMOST no image deterioration.
-
SetFileTimeStamp() is also failing with 0xFF835C3C. It crashes also if i nullsub the call, so i have replaced
the SetFileTimeStamp() call in utime() with this:
//res=_SetFileTimeStamp(fd, ((int*)newTimes)[0] , ((int*)newTimes)[1]);
res=1;
Enabling the simple CHDK-RAW (without DNG support) in the G11 firmware was no big deal, so why not doing it. :lol
It is another question if this is really usefull for the chdk-user. I think not, because saving an 15MB RAW-Image takes a couple of seconds, the original (packed) raw file is written much faster.
But setting the correct timestamp on files makes trouble. And if i search for utime() references, i see that also motion_detector and lua using this function. So i am afraid that this calls will also crashing and maybe i have to patch them also, if no suitable function address is found for _SetFileTimeStamp().
-
i am afraid that this calls will also crashing and maybe i have to patch them also, if no suitable function address is found for _SetFileTimeStamp().
OK, I will have another look later this evening.
-
Okay, thanks. :)
BTW: I am currently trying to get the exposure task running.
But there are also other tasks to do, and maybe someone can help me out to speed up the G11 porting process.
As descript here: http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera (http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera) , the shooting.c needs to be updated for the G11:
platform/<camera>/shooting.c
To fill aperture_sizes_table[] you can use the same method as for filling fl_tbl[] in main.c. In case your camera doesn't have an actual diaphragm, you just take pictures at the available zoom steps. Twice if your camera has an ND filter (once with filter and once without; either use the ND-filter option from the CHDK menu, if you have the right values in platform/<camera>/sub/<version>/stubs_entry(_2).S, or find specific modes that make sure the filter is used or not). The entries are of the form { idx, av, string } with idx starting from 9, av the values of PROPCASE_AV and string a string representation of the aperture (the value of which you can get from the EXIF data).
To fill iso_table[] you check PROPCASE_ISO_MODE for the different ISO values the camera allows you to select. Note that Auto gets index 0 and HI gets index -1.
For shutter_speeds_table[] you essentially have to try various exposure times and see if there is a difference with others. If not, you know that the used exposure time wasn't really supported.
To fill in modemap[], use the same procedure as key_map[] in kbd.c. Use the debug OSD with "Props" to show item PROPCASE_SHOOTING_MODE (see include/propcase1.h or include/propcase2.h, depending on your camera, for the right number) and change modes to see what value is shown. You might need to extend the enumeration in include/platform.h if your camera has new kinds of modes.
Finally, you'll have to find the right values for PARAM_FILE_COUNTER and PARAM_EXPOSURE_COUNTER by using the debug OSD. You can easily detect them by taking a picture and noting which value changes. Note that PARAM_FILE_COUNTER is a big number as it actually contains multiple counters (see its usage in platform/generic/shooting.c; taking a picture will add 16 to the number as a whole.
So i need the correct values for:
aperture_sizes_table[]
shutter_speeds_table[]
iso_table[]
modemap[]
It would be very helpfull if someone out there with a G11 can evalute this values, so i can keep focused getting the code running.
-
Obviously, you will need to upload a build.
-
SetFileTimeStamp() is also failing with 0xFF835C3C. It crashes also if i nullsub the call
I was going to compare with IXUS200.
Originally it was found with 95% match but Radup later nullsub'd it :-
http://chdk.setepontos.com/index.php/topic,4228.msg41742.html#msg41742 (http://chdk.setepontos.com/index.php/topic,4228.msg41742.html#msg41742)
No more has been heard from him.
-
According to my experience it's not big deal to find SetFileTimeStamp() function.
Please give me link to firmware dump you are trying to port for and addresses of some functions like rename(), lseek(), stat(), mkdir() and so on.
The more known functions you have - the easier it would be to find one more.
I think at least one function address from the list above should be enough.
-
Well, like the IXUS200 the code seems somewhat different.
Here is the drop http://drop.io/chdkdumps2/ (http://drop.io/chdkdumps2/)
I did not find Lseek.
In that approximate area I found :-
Fseek_Fut 0xff835658
j_read 0xff835a3c
and I would have expected SetFileTimeStamp to be between the two.
I suggested 0xFF835C3C
-
I suggested 0xFF835C3C
Probably yes. But it seems that SetFileTimeStamp in G11 does not require open() and close() calls (look at utime() wrapper).
-
A little bit strange firmware.
I have found ioctl() function which was used for many POSIX/ANSI functions, but it is not called at all in this firmware.
SetFileTimeStamp is 0xFF835C3C
But first parameter is not fd (file descriptor), it is pointer to file name.
So prototype is as follows:
int SetFileTimeStamp(char *file_path, int access_time, int modification_time);
It looks like function returns 1 if Ok, or 0 if error.
I have no camera to test, so you need to check this out yourself.
-
Okay, i will test this.
I have got another strange problem: Very often my diskboot.bin builds was crashing at startup (before chdk splash screen was shown), at that even if i have not changed any code which is exceuted during startup.
To track the root-cause of this problem, i included the romlog.patch to my build, so i got a exception register dump.
The dump shows me, that the Spytask was crashing with a faulty pointer in the free() function.
And with help of the stack dump, i found the problem here in script.c:
void script_load(const char *fn, int saved_params) {
int i, update_vars;
FILE *fd = NULL;
struct stat st;
// save_params_values(0);
if(state_ubasic_script && state_ubasic_script != ubasic_script_default)
free((void *)state_ubasic_script);
...
This function is called during config load, and sometimes this free() call crashes. And the cause i think is this not initalized pointer variable:
const char *state_ubasic_script;Most of the time, the variable is 0 at startup, and the free is not executed. But not allways...
So i replaced this with this initialisation:
const char *state_ubasic_script = NULL;And finally the camera is now booting stable.
But there is one more problem: I cant see the debug output on the display (i mean e.g. the output for "PropCase/ParamsData"). The normal menus, games, etc. are shown, but the complete "Debug data display" is not working.
No debug output is visible on the display, on the normal cameras menus or livepicture is shown. Is the debug output using other draw_functions for output? And where can i find the debug-output functions in the CHDK code?
And there is also another problem: If i switch from a "long" menu (like e.g. "Miscellaneous") via "<- BACK" to a "short" menu (e.g."Main Menu"). In this case, the "Miscellaneous" Menu is only simply overwritten, but not cleared before "Main Menu" is painted. So i can see the both menus overlayed. How the menu update process is working, and on which point the gui-framework clears the screen? Obviously this is currently now working in my port... :haha
-
there are also other tasks to do, and maybe someone can help me out to speed up the G11 porting process.
You need to post a build if people are to assist.
-
Okay, i dont know if a build without working debug menu output will be very helpfull, but here is my current build:
-
I am not familiar with the exact naming of the CHDK features.
Is display of Miscellaneous values and PropCases working ?
-
No, it is not working. Currently i got sometimes a yellow filled rectangle on the screen. So maybe this "is" the (faulty) output of propcases. But it is not very usefull. Thats why i want to know, in which part of the CHDK source i can find the code who draws the ProcCase output, so i can find out whats going wrong.
-
The CHDK code is more 'complicated' than the SDM code.
I will look shortly to find where that information is.
If it is any use, this is at the bottom of gui.c in SDM :-
//--------------------------------- Debug values ----------------------
if (debug_vals_show)
{
sprintf(osd_buf, "0:%8x ",physw_status[0]);
draw_txt_string(28, 10, osd_buf, conf.osd_color);
sprintf(osd_buf, "1:%8x ",physw_status[1]);
draw_txt_string(28, 11, osd_buf, conf.osd_color);
sprintf(osd_buf, "2:%8x ",physw_status[2]);
draw_txt_string(28, 12, osd_buf, conf.osd_color);
}
//---------------------------------- Debug propcase -------------------
if (debug_propcase_show)
{
static char sbuf[100];
int r,i, p;
for (i=0;i<10;i++)
{
r = 0;
p = debug_propcase_page*10+i;
get_property_case(p, &r, 4);
sprintf(sbuf, "%3d: %d ", p, r);sbuf[20]=0;
draw_string(64,16+16*i,sbuf, conf.osd_color,1);
}
}
} //_conf.show_osd
-
A little bit strange firmware.
I have found ioctl() function which was used for many POSIX/ANSI functions, but it is not called at all in this firmware.
SetFileTimeStamp is 0xFF835C3C
But first parameter is not fd (file descriptor), it is pointer to file name.
So prototype is as follows:
int SetFileTimeStamp(char *file_path, int access_time, int modification_time);
It looks like function returns 1 if Ok, or 0 if error.
I have no camera to test, so you need to check this out yourself.
I changed the code to this:
wrappers.c:
int utime(char *file, void *newTimes) {
#if !CAM_DRYOS
return _utime(file, newTimes);
#else
int res=0;
#ifdef CAM_DRYOS_2_3_R39
res=_SetFileTimeStamp(file, ((int*)newTimes)[0] , ((int*)newTimes)[1]);
#else
int fd;
int res=0;
fd = _open(file, 0, 0);
if (fd>=0) {
res=_SetFileTimeStamp(fd, ((int*)newTimes)[0] , ((int*)newTimes)[1]);
_close(fd);
}
// return value compatibe with utime: ok=0 fail=-1
#endif
return (res)?0:-1;
#endif
}
stubs_entry_2.s:
NSTUB(SetFileTimeStamp, 0xFF835C3C)
lolevel.h:
#ifdef CAM_DRYOS_2_3_R39
int _SetFileTimeStamp(char *file_path, int time1, int time2);
#else
extern int _SetFileTimeStamp(int fd, int time1, int time2);
#endif
but it still does not work. This assert hits:
ASSERT!! Mounter.c Line 2563
-
The CHDK code is more 'complicated' than the SDM code.
I will look shortly to find where that information is.
If it is any use, this is at the bottom of gui.c in SDM :-
Thanks, now i found the code ( gui_draw_debug_vals_osd() ) . ;)
I moved this functioncall from the bottom of gui_draw_osd to the head of the function gui_redraw().
And now i can see the debug/property values. So something seems to be different with
the display updates on G11. I assume that the debug values are written anyway, but the cleaned/overwritten by the original canon display output or so...
Anyway, here is my build with permanent debug output:
-
mattkime and kingcang have both expressed interest in this build, maybe they can help find the information that you need ?
At least now there are others who can boot the G11.
-
If found in the sourcecode this comment:
// uncomment if you want debug values always on top
//gui_draw_debug_vals_osd();
So i changed again the callpoint for gui_draw_debug_vals_osd(); and now the debug output and the CHDK menu are
more usable. So maybe this build is usable for getting the PropValues. I added this build to my previous post on page 15.
-
I tryed to find the correct address for "RefreshPhysicalScreen",because this was nullsubed actual. Which can maybe the cause for the strange display update behaviour.
So i checked the SX200IS port, which also sets a variable "enabled_refresh_physical_screen", before RefreshPhysicalScreen() is called. I think the G11 needs this also, and i think i found the funktion in the G11 firmware:
NHSTUB(RefreshPhysicalScreen, 0xFFA11130)
DEF(enabled_refresh_physical_screen, 0x98B4+0x28)
So i added this function and checked also that it is called.
void vid_bitmap_refresh()
{
extern int enabled_refresh_physical_screen;
enabled_refresh_physical_screen=1;
_RefreshPhysicalScreen(1);
}
But nothing changed, display update/clean is still not correct working...
If this maybe not the correct function address for _RefreshPhysicalScreen()?
-
Some progress. The reason why OSD Debug values was not correctly shown (without patching gui_osd.c), are some not updated variables in stubs_min.s ( like "canon_menu_active" and so). Now the debug output is working "normal", without any patches.
But there are still some variable addresses left to find:
DEF(recreview_hold, xxx)
DEF(movie_status, xxx)
DEF(some_flag_for_af_scan, xxx)
So it would ne a great help if someone could find the correct addresses for the G11-FW.
-
Hi there,
I have a G11 and I can run your DISKBOOT.BIN here. I know C/C++ and Assembler, but I have no idea how CHDK works under its hood... But I've got some little spare time, so I could help if you tell me how. I saw that there are some arrays to be filled:
So i need the correct values for:
aperture_sizes_table[]
shutter_speeds_table[]
iso_table[]
modemap[]
But frankly, I do not have any idea how to find out those values and http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera (http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera) doesn't help me either... If anyone has a "How to find those arrays for Dummies", I could probably help ;-)
cheers,
Ben
-
The modemap is now off the list, i got this values using the "Debug parameters/PropCase" Viewer for Property 49:
static const CapturemodeMap modemap[] = {
{ MODE_AUTO, 32768 },
{ MODE_P, 32772 }, // also C1,C2
{ MODE_TV, 32771 },
{ MODE_AV, 32770 },
{ MODE_M, 32769 },
{ MODE_VIDEO_COLOR_ACCENT, 2601 },
{ MODE_VIDEO_COLOR_SWAP, 2602 },
{ MODE_VIDEO_STD, 2603 },
{ MODE_SCN_NIGHT_SNAPSHOT, 16395 },
{ MODE_SCN_LANDSCAPE, 16396 },
{ MODE_SCN_PORTRAIT, 16397 },
{ MODE_SCN_NIGHT_SCENE, 16398 },
{ MODE_SCN_KIDS_PETS, 16400 },
{ MODE_SCN_INDOOR, 16401 },
{ MODE_SCN_SUNSET, 16402 },
{ MODE_SCN_FOLIAGE, 16403 },
{ MODE_SCN_SNOW, 16404 },
{ MODE_SCN_BEACH, 16405 },
{ MODE_SCN_FIREWORK, 16406 },
{ MODE_SCN_UNDERWATER, 16407 },
{ MODE_SCN_AQUARIUM, 16408 },
{ MODE_SCN_SPORT, 16903 },
{ MODE_SCN_STITCH, 16906 },
{ MODE_SCN_COLOR_ACCENT, 16923 },
{ MODE_SCN_COLOR_SWAP, 16924 },
{ MODE_SCN_ISO_3200, 32799 }, // Candle ?
{ MODE_SPORTS, 33313 } // Quickshot ?
};
I am not sure which "hackmode" is the correct one for the LowLight Mode ("Candle") and for Quickshot. For now, i mapped them to ISO_3200 and MODE_SPORTS.
-
Okay, again some progress:
I corrected the playrec mode adress, so now the CHDK gui knows that we are not in playmode.
I also hooked in the movietask, so it is now possible to use the optical zoom during movierecord. :D
Also the updated modemap[] is now included.
So here is my new version of diskboot.bin to play arround:
-
Oh yes, this very important feature is now also working: "Dual-view" histogram: :lol
-
Oh yes, this very important feature is now also working: "Dual-view" histogram:
Let us see the colour of your RGB histograms :)
Don't forget to charge your battery !
bassist offered to find some values for you.
-
I am not sure which "hackmode" is the correct one for the LowLight Mode ("Candle") and for Quickshot. For now, i mapped them to ISO_3200 and MODE_SPORTS.
For C1 and C2, there should be a value to set these in the canon mode list, which can be found at FFBE7010
Looks like these are 8229 and 8230. These are not in the modemap yet, but are useful to keep in a comment. Setting a "C" mode sets whatever mode you had previous saved.
The hackmodes are named purely after the name in the canon manual right now. If the camera has some that don't match any existing ones, just add it at the end of the list. (I got half way through re-working this, but RL has me busy right now :()
Looking at http://www.usa.canon.com/consumer/controller?act=ModelInfoAct&tabact=ModelTechSpecsTabAct&fcategoryid=222&modelid=19209 (http://www.usa.canon.com/consumer/controller?act=ModelInfoAct&tabact=ModelTechSpecsTabAct&fcategoryid=222&modelid=19209) "Low Light" appears to be new. "Quick shot" may be the same as other cameras quick modes (e.g. sd990) ?
-
A little bit strange firmware.
I have found ioctl() function which was used for many POSIX/ANSI functions, but it is not called at all in this firmware.
SetFileTimeStamp is 0xFF835C3C
But first parameter is not fd (file descriptor), it is pointer to file name.
So prototype is as follows:
int SetFileTimeStamp(char *file_path, int access_time, int modification_time);
It looks like function returns 1 if Ok, or 0 if error.
I have no camera to test, so you need to check this out yourself.
I changed the code to this:
...
stubs_entry_2.s:
NSTUB(SetFileTimeStamp, 0xFF835C3C)
...
but it still does not work. This assert hits:
ASSERT!! Mounter.c Line 2563
Correction, it works if i modify the code as cppasm suggested! My last test was incorrect, i used NSTUB instead of NHSTUB and so it was still using the wrong address for SetFileTimeStamp. Now SetFileTimeStamp() is working correct. So canon really changed the interface for this function.
@reyalp: Okay, thanks for the explanation. I will change the modemap and add the new hackmode to the end of the list.
-
Correction, it works if i modify the code as cppasm suggested! My last test was incorrect, i used NSTUB instead of NHSTUB and so it was still using the wrong address for SetFileTimeStamp. Now SetFileTimeStamp() is working correct. So canon really changed the interface for this function.
I am not absolutely sure, but there may be some problems with this function if file does not exists.
At least Canon's firmware checks for file existance using Open() in readonly mode and then Close() it if Ok.
So I'm not sure how SetFileTimeStamp will act on non-existent file - maybe it will return zero, but maybe DebugAssert() will be called with camera shutdown.
This need to be checked and maybe you will need to add checks for file existance to the wrapper function.
-
I tested it with an non existing file path on the sd-card. The function does not crash or throws an assert/exception.
But anyway, if canon does as filecheck before using SetFileTimeStamp, i do it not also. :haha
I changed the utime function now to this, and it works:
int utime(char *file, void *newTimes) {
#if !CAM_DRYOS
return _utime(file, newTimes);
#else
int res=0;
int fd;
fd = _open(file, 0, 0);
#ifdef CAM_DRYOS_2_3_R39
if (fd>=0) {
_close(fd);
res=_SetFileTimeStamp(file, ((int*)newTimes)[0] , ((int*)newTimes)[1]);
}
#else
if (fd>=0) {
res=_SetFileTimeStamp(fd, ((int*)newTimes)[0] , ((int*)newTimes)[1]);
_close(fd);
}
// return value compatibe with utime: ok=0 fail=-1
#endif
return (res)?0:-1;
#endif
}
-
Good work !
So, what is next ?
-
Let us see the colour of your RGB histograms :)
Don't forget to charge your battery !
Dont worry, i have also a second battery available. ;)
An here is the RGB histogram. It does not look so bad after i updated the COLOR defines in gui_draw.h:
-
i updated the COLOR defines in gui_draw.h:
Do you mean you have changed an existing palette or defined a new one ?
If an existing palette, it obviously has to be correct for the other cameras that use it.
-
I created a new one (CAM_BITMAP_PALETTE 4). I used as base the values from palette 3 and modfied a few values.
In the mean time, i also updated the shutterspeeds_table[] and iso_table[].
The values does not differs great from other cams, looks like the "usual" values:
const ShutterSpeed shutter_speeds_table[] = {
{ -12, -384, "15", 15000000 },
{ -11, -352, "13", 13000000 },
{ -10, -320, "10", 10000000 },
{ -9, -288, "8", 8000000 },
{ -8, -256, "6", 6000000 },
{ -7, -224, "5", 5000000 },
{ -6, -192, "4", 4000000 },
{ -5, -160, "3.2", 3200000 },
{ -4, -128, "2.5", 2500000 },
{ -3, -96, "2", 2000000 },
{ -2, -64, "1.6", 1600000 },
{ -1, -32, "1.3", 1300000 },
{ 0, 0, "1", 1000000 },
{ 1, 32, "0.8", 800000 },
{ 2, 64, "0.6", 600000 },
{ 3, 96, "0.5", 500000 },
{ 4, 128, "0.4", 400000 },
{ 5, 160, "0.3", 300000 },
{ 6, 192, "1/4", 250000 },
{ 7, 224, "1/5", 200000 },
{ 8, 256, "1/6", 166667 },
{ 9, 288, "1/8", 125000 },
{ 10, 320, "1/10", 100000 },
{ 11, 352, "1/13", 76923 },
{ 12, 384, "1/15", 66667 },
{ 13, 416, "1/20", 50000 },
{ 14, 448, "1/25", 40000 },
{ 15, 480, "1/30", 33333 },
{ 16, 512, "1/40", 25000 },
{ 17, 544, "1/50", 20000 },
{ 18, 576, "1/60", 16667 },
{ 19, 608, "1/80", 12500 },
{ 20, 640, "1/100", 10000 },
{ 21, 672, "1/125", 8000 },
{ 22, 704, "1/160", 6250 },
{ 23, 736, "1/200", 5000 },
{ 24, 768, "1/250", 4000 },
{ 25, 800, "1/320", 3125 },
{ 26, 832, "1/400", 2500 },
{ 27, 864, "1/500", 2000 },
{ 28, 896, "1/640", 1563 },
{ 29, 928, "1/800", 1250 },
{ 30, 960, "1/1000", 1000 },
{ 31, 992, "1/1250", 800 },
{ 32, 1024, "1/1600", 625 },
{ 33, 1056, "1/2000", 500 },
{ 34, 1088, "1/2500", 409 },
{ 35, 1120, "1/3200", 313 },
{ 36, 1152, "1/4000", 250 },
};
const ISOTable iso_table[] = {
{ 0, 0, "Auto", -1},
{ 1, 80, "80", -1},
{ 2, 100, "100", -1},
{ 3, 200, "200", -1},
{ 4, 400, "400", -1},
{ 5, 800, "800", -1},
{ 6, 1600, "1600", -1},
{ 7, 3200, "3200", -1},
};
-
I am not sure why these shutter-speed tables exist.
Tv96 values are precisely related to shutter-speed by the formula given in platform\generic\shooting.c.
-
I am also not sure, but anyway, the list is updated now.
In the mean time i did some bugfixing, some of the (not 100% hits) string functions addresses in stubs_entry.s was really wrong. This functions did not crash immediatly, but there are did some wild pointer action and crashes other functions. I fixed that, and now also scripting or loading of grids is working. I was now able to run LLIBTST.LUA script, without crashing the camera. :D
But there are still some open points on the list:
1) Finding the address of this variables
DEF(recreview_hold, xxx)
DEF(movie_status, xxx)
DEF(some_flag_for_af_scan, xxx)
2) Check if all of this (currently) nullsub functions, are really not available:
NHSTUB(rename, 0xFF810B04)
NHSTUB(rewinddir, 0xFF810B04)
NHSTUB(Unmount_FileSystem, 0xFF810B04)
NHSTUB(Mount_FileSystem, 0xFF810B04)
NHSTUB(Remove, 0xFF810B04)
NHSTUB(kbd_pwr_on, 0xFF810B04)
NHSTUB(EnterToCompensationEVF, 0xFF810B04)
NHSTUB(ExitFromCompensationEVF, 0xFF810B04)
NHSTUB(PT_PlaySound, 0xFF810B04)
NHSTUB(UIFS_WriteFirmInfoToFile, 0xFF810B04)
NHSTUB(readfastdir, 0xFF810B04)
NHSTUB(Lseek, 0xFF840F84)
NHSTUB(MakeAFScan, 0xFF810B04)
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF810B04)
3) Update of aperture table:
aperture_sizes_table[]
4) Finding the cause for the not correct working display clear/update problem:
-
2) Check if all of this (currently) nullsub functions, are really not available:
If you comment-out all entries (apart from PT_PlaySound) above and in stubs_entry.s, does the code still compile OK ?
I think only PTPlaySound is used by CHDK.
-
DEF(recreview_hold, xxx)
On the SX200, code starts at 0xFF964C00.
On the G11, compare with code at 0xFF998194.
Maybe 0x7D00 + 0xD8 ?
-
2) Check if all of this (currently) nullsub functions, are really not available:
If you comment-out all entries (apart from PT_PlaySound) above and in stubs_entry.s, does the code still compile OK ?
I think only PTPlaySound is used by CHDK.
No, it does not build if i simply comment this stubs out:
ERROR! There are unresolved addresses in 'stubs_entry.S' (g11-100j) for the following names:
EnterToCompensationEVF
ExitFromCompensationEVF
Lseek
PT_PlaySound
Remove
UIFS_WriteFirmInfoToFile
kbd_pwr_on
readfastdir
rename
and:
../platform/g11/libplatform.a(wrappers.o): In function `MakeAFScan':
wrappers.c:(.text+0x350): undefined reference to `_MakeAFScan'
wrappers.c:(.text+0x360): undefined reference to `_ExpCtrlTool_StartContiAE'
../platform/g11/libplatform.a(wrappers.o): In function `rewinddir':
wrappers.c:(.text+0x7ec): undefined reference to `_rewinddir'
../platform/g11/libplatform.a(wrappers.o): In function `remount_filesystem':
wrappers.c:(.text+0xdb0): undefined reference to `_Unmount_FileSystem'
wrappers.c:(.text+0xdb4): undefined reference to `_Mount_FileSystem'
collect2: ld returned 1 exit status
-
A couple of suggestions :-
DEF(some_flag_for_af_scan, 0x72B4) //found at ROM:FF965F34
DEF(movie_status, 0x6D58+0x38) //ROM:FF96249C
These are G9 nullsubs :-
NHSTUB(rewinddir, 0xFF810958) // nullsub
NHSTUB(Unmount_FileSystem, 0xFF810958) // nullsub
NHSTUB(Mount_FileSystem, 0xFF810958) // nullsub
NHSTUB(kbd_pwr_on, 0xFF810958) // nullsub
-
Okay, i think i found some of the missing functions:
NHSTUB(EnterToCompensationEVF, 0xFF8373D8)
NHSTUB(ExitFromCompensationEVF, 0xFF83741C)
NHSTUB(PT_PlaySound, 0xFF882414)
NHSTUB(UIFS_WriteFirmInfoToFile, 0xFF980560)
NHSTUB(MakeAFScan, 0xFF966130)
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF844CE0)
NHSTUB(Remove, 0xFF8359E4)
NHSTUB(readfastdir, 0xFFA84270)
So only the "rename" and "Lseek" function are left to be found.
-
I read somewhere that for one recent camera Lseek and lseek were the same.
Does CHDK use rename and Lseek ?
EDIT:
Yes.
-
A couple of suggestions :-
DEF(some_flag_for_af_scan, 0x72B4) //found at ROM:FF965F34
DEF(movie_status, 0x6D58+0x38) //ROM:FF96249C
Bingo! Addresses are correct. :)
Now also AF-Scan during videomode works.
I also added the suggested recreview_hold value, but i dont know how to test it.
In which use-cases this variable should change his value?
-
I am not able to test this but I guess you use the memory browser to monitor that location while you take a photo.
If you have set review hold to some value in the Canon menu then presumably that memory location changes while the camera is in review mode.
-
Hmm, nope. I cant see any difference in the value (if i set previously review hold to "HOLD" or to some seconds) during review of the taken picture. It it still zero. I tried 0x7D00+0xD8, 0x7D00+0x10, 0x7D00+0x64. Only at 0x7D00+0x10 the value is changing to 1, but only if i press the shoot button half. Does not make much sense.
I also got no progress getting the void vid_bitmap_refresh() functional.
It is still without effect, it does not lead to a redraw of the canon gui, so all chdk menus are overlayed drawn.
I am using:
NHSTUB(RefreshPhysicalScreen, 0xFFA11130)
and
DEF(enabled_refresh_physical_screen, 0x98B4+0x28)
in vid_bitmap_refresh().
If i add a draw_clear(); call in my vid_bitmap_refresh() function, the complete OSD is cleared (including the canon OSD), so i know that my function get called. Is my function adress for RefreshPhysicalScreen or enabled_refresh_physical_screen wrong?
-
NHSTUB(RefreshPhysicalScreen, 0xFFA11130)
Based on the SX200, that seems likely.
However, based on the IXUS200 it would be 0xFFA0FED8.
I have no idea if the IXUS200 is correct.
Maybe an IXUS200 user (or Radup) could confirm if the screen refreshes OK ?
-
Okay, i also tried 0xFFA0FED8, but still no success.
I also tried the vid_bitmap_refresh() variants, found in other ports:
void vid_bitmap_refresh()
{
extern int enabled_refresh_physical_screen;
enabled_refresh_physical_screen=1;
_RefreshPhysicalScreen(1);
}
void vid_bitmap_refresh()
{
extern int enabled_refresh_physical_screen; // screen lock counter
int old_val = enabled_refresh_physical_screen;
if ( old_val == 0 )
{
_ScreenLock(); // make sure code is called at least once
} else {
enabled_refresh_physical_screen=1; // forces actual redraw
}
_RefreshPhysicalScreen(1); // unlock/refresh
// restore original situation
if ( old_val > 0 )
{
_ScreenLock();
enabled_refresh_physical_screen = old_val;
}
}
void vid_bitmap_refresh()
{
_ScreenLock();
_RefreshPhysicalScreen(1);
}
But it was allways the same, screen refresh is not working. :'(
-
i also tried 0xFFA0FED8, but still no success.
You also need correct value of 'enabled_refresh_physical_screen'
As the IXUS200 seems to be working, maybe you could ask Radup how he found that value ?
-
Correction: I think you are right with 0xFFA0FED8 for RefreshPhysicalScreen().
I did a closer look on the dissassembly, and i think i found a variable that looks like "enabled_refresh_physical_screen": 0x9840
I dont know if its 100% correct, but now the screen gets refreshed and i dont have anymore overlayed drawn CHDK menus. :)
But there is now another problem: Sometimes at startup (if started in PLAY mode) at the point where normally the CHDK-Splash screen is shown, the camera crashes now with this assert message:
ASSERT!! FsIoNotify.c Line 451
Occured Time 2010:01:13 22:27:06
Task ID: 13828123
Task name: SpyTask
SP: 0x0038884C
StackDump:
0x00000000
0xFF86C8F8
0x000001C3
0x00000000
0x00000003
0x00000000
0x001772B2
0x19980218
0x19980218
0x19980218
0x19980218
0xFF86CA1C
0x00000000
0x001772B2
0x00000003
0x00000000
0x19980218
0xFF8359A0
0x4028DB80
0x003888B8
0x001772B2
0x19980218
0x19980218
0x00156F1C
0x00149A1F
0xFF816C5C
0xFF816C5C
0x000081FF
0x00000020
0x00000AC6
0x386D4380
0x4B4E4046
0x12C4925C
0x0000001A
0x0017E994
0x00000191
0x19980218
0x00141291
0x00372E40
0x19980218
0x19980218
0x19980218
0xFF816A20
0x19980218
0x19980218
0x00002008
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0f 0f 0f 0f 0f 0f 0f
00000090: *** Camera Log Start ***
00000100: SS:S-Imag
00000100: UI:ScreenLock
00000100: UI:ScreenUnLock
00000110: UI:Button:0x000010B4:WriteEnableMedia
00000110: UI:SetPanelDirectionToLcdController
00000130: UI:LogicalEvent:0x300a:adr:0,Para:0
00000130: UI:PB.Create
00000130: UI:DispSwCon_TurnOnBackLight
00000130: UI:TurnOnBackLight
00000210: UI:LogicalEvent:0x5001:adr:0,Para:0
00000250: UI:DispSwCon_MuteOffPhysicalScreen
00000250: UI:MuteOffPhysicalScreen
00000250: UI:LogicalEvent:0x3138:adr:0,Para:0
00000300: UI:ScreenLock
00000300: UI:ScreenUnLock
00000310: UI:LogicalEvent:0x112c:adr:0,Para:0
00000310: UI:SetPanelDirectionToLcdController
00000310: UI:LogicalEvent:0x5006:adr:0,Para:0
00000360: UI:ScreenLock
00000360: UI:ScreenUnLock
00000360: UI:SetPanelDirectionToLcdController
00000390: UI:PB.CreateE
00000400: UI:AC:StartPB
00000400: UI:DispSwCon_TurnOnDisplayDevice
00000400: UI:AC:EBtn
00000400: UI:PB.Start
00000400: UI:DSIC:46,0
00000440: UI:CC_CompFlhJpg
00000440: UI:_CompFlhJpg
00000440: UI:PB.Flash
00000440: UI:DSIC:46,0
00000440: UI:PB_LimiteActionOpenAndCloseLCD
00000450: UI:ScreenLock
00000450: UI:DSIC:46,0
00000720: UI:PB.DrawI
00000790: UI:LogicalEvent:0x320a:adr:0,Para:0
00000910: UI:LogicalEvent:0x3203:adr:0,Para:0
00000940: UI:PB.StartE
00000940: UI:PB.DPOF
00000940: UI:PB.IHist
00000950: UI:PB.DcdCBR
00000950: UI:ScreenLock
00000950: UI:PB.RfrsI
00000970: UI:ScreenLock
00000990: UI:ScreenUnLock
00000990: UI:SetPanelDirectionToLcdController
00001020: UI:LogicalEvent:0x3201:adr:0,Para:0
00001020: UI:DispSw: Unlock
00001020: UI:DispSwCon:Unlock
00001020: UI:DispSwCon_TurnOnBackLight
00001020: UI:DispSwCon_MuteOffPhysicalScreen
00001020: UI:MuteOffPhysicalScreen
00001020: UI:AC:EnryPB
00001020: UI:AP:ChkCnctUSB
So finding the correct sequence for screen-refresh/update is still an open-point.
-
An there is another thing: I think also a third propset.h is needed.
During my work to get the badpixel.lua script running, i discovered that at least this Props have changed:
"Old" propcase2.h defines, not working for G11:
#define PROPCASE_SHOOTING 206
#define PROPCASE_IS_FLASH_READY 208
G11 props that works:
#define PROPCASE_SHOOTING 208
#define PROPCASE_IS_FLASH_READY 210
Maybe there are more props changed, we will see...
-
As a matter of interest, how do you create and capture the ASSERT output above ?
-
Creation is easy, simply execute code that crashes the camera. :haha
But before you do this, merge the romlog.patch from this thread into your build:
http://chdk.setepontos.com/index.php/topic,275.msg20888.html#msg20888 (http://chdk.setepontos.com/index.php/topic,275.msg20888.html#msg20888)
Then you have another option in the debug menu, which calls the FW function "GetLogToFile",
and this will do the job and creates a file in the root of your SD-Card with the assert/exception information of the last crash.
Of course you have to find the adress for GetLogToFile, but this is not hard. Search for the reference to "aLogIsNotSaved_ DCB "Log is not Saved.". In the G11 Firmware for example, it is this function: NHSTUB(GetLogToFile,0xFF96D104)
-
-
-
Then you have another option in the debug menu, which calls the FW function "GetLogToFile",
and this will do the job and creates a file in the root of your SD-Card with the assert/exception information of the last crash.
You can also do this with the eventproc interface and a lua script, no patch needed. You probably need to call "System.Create" or "SystemEventInit" first.
I was going to merge the GetLogToFile patch, but I couldn't get it to work under vxworks, so I couldn't test it.
You can also read the log directly from ROM, seems to always be at FFFFE000 on the cameras that I've looked at. Some decoding would be required.
-
-
You can also do this with the eventproc interface and a lua script, no patch needed. You probably need to call "System.Create" or "SystemEventInit" first.
Cool. I think it would be very helpfull (for bugreports and also in generell for development), if its possible to get the ErrorLog via a script on every dryos camera without need of patching CHDK.
-
The port is almost finished, but during my test i found three things that are not working as expected:
1) If CHDK is used to put in the ND-Filter, the ND-Filter snaps in (good), but after 2-3 Seconds the camera throws an assert.
If i put in the ND-Filter via the original canon menu, and then via CHDK no assert happens, maybe they have now a check in the
code to verify (hw via. sw) state of the ND-Filter. So i currently disabled the HAS_NDFILTER option in camera.h for my port.
2) The lua testscript almost works, but there is one FAIL entry left. The "Remove" command is not able to remove the "A/MDTST0" directory. Removing files in the directory is working fine.
3) The Zebramode looks strange. With the standard zebra-osd-code, i got the screen half filled with strange pixel fragments. So i add the g11 to the define checks in gui_osd.c (#if defined (CAMERA_sx200is) || defined (CAMERA_g11)). So the sx200is code is used know, because of the same framebuffer & resolution layout. This looks a lot better, but not perfect. The zebra drawing does not match the overexposed areas, it is allways drawn under it. :blink:
-
Can you post an image showing a simple shape, such as a lightshade or overexposed computer monitor ?
-
The position in the buffer of a pixel at x,y is :-
sy=y*screen_buffer_width;
s=sy+x*2;
because every x pixel is drawn twice (or four times for multichannel).
If the zebra is drawn too low but correctly positioned horizontally, the value for screen_buffer width must be too big.
-
Okay, here is one example picture, the zebra drawing is to low and also streched.
Horizontally positioning looks ok, i think.
Currently, i use this size:
long vid_get_bitmap_buffer_width() { return 960; }
As may you can see, also a green distortion line on the top of the display often occurs with activated zebra drawing.
-
viewport_width = vid_get_viewport_width();
What width are you using for the live viewport ?
It is normally 360 but maybe it is 480 with the G11 ?
(I cannot remember if you have tested other features that require a correct value for viewport width, such as edge outline and motion detection).
-
Yes, i am using 360 as viewport_width. An no, currently i did not tested motiondetection&edge outline.
I tried now also a 480 pixel viewport width:
-
I also tried to double (360*2) the viewport width, which does not looks so bad.
But there is still this green line at the top and the camera crashes when i release the shutter with a exception of the spytask.
-
Probably too much memory allocated to the buffer.
Do you know how much spare memory there is on the G11 ?
(I think there is a CHDK option to display that).
-
Free memory: 879320 bytes
CHDK size: 287656 bytes
-
Read the free memory value after allocating the zebra buffer.
If necessary, comment-out the rest of the zebra code, just allocate the memory.
I do not think you will have enough memory to cover the entire screen, only a central section.
-
Okay, i disabled the code in gui_osd_draw_zebra() unter the zebra_init() call (which allocates the memory):
int gui_osd_draw_zebra(int show) {
unsigned int v, s, x, y, f, over;
color cl_under=conf.zebra_color>>8, cl_over=conf.zebra_color&0xFF;
static int need_restore=0;
int viewport_height;
int viewport_width;
int mrec = ((mode_get()&MODE_MASK) == MODE_REC);
int zebra_drawn=0;
color cls[] = {
COLOR_TRANSPARENT,
(mrec)?COLOR_HISTO_B:COLOR_HISTO_B_PLAY,
(mrec)?COLOR_HISTO_G:COLOR_HISTO_G_PLAY,
(mrec)?COLOR_HISTO_BG:COLOR_HISTO_BG_PLAY,
(mrec)?COLOR_HISTO_R:COLOR_HISTO_R_PLAY,
(mrec)?COLOR_HISTO_RB:COLOR_HISTO_RB_PLAY,
(mrec)?COLOR_HISTO_RG:COLOR_HISTO_RG_PLAY,
COLOR_BLACK
};
if (!gui_osd_zebra_init(show))
return 0;
#if 0 <------------------------------------------------------------- code disabled.
if(timer==0) {
draw_guard_pixel();
timer=1;
return 0;
....
}
Then i checked the memory usage after pressing the shutter half in a over exposed picture situation.
Free memory stays arround 87xxxx.
Then i also disabled one of the free() calls (free(buf) ; ) in gui_osd_zebra_free(), to see what happens.
Camera still works stable, but with every halfpress shutter, the memory goes lower (as expected) in this steps:
880672
650224
419808
189392
Update: As is see in my code, i did this measurement with a viewportsize width of 480 (and not with 720).
-
Deleted.
-
I repeated the test, now with 720 width.
I also commented out the used sx200 configuration (#define ZEBRA_HMARGIN0 30) and using #define ZEBRA_HMARGIN0 0 for max. memory usage.
If i only deactivate the osd-draw routine, nothing happens. Free memory after half pressing the shutter button is as high as before.
If i remove all free calls, memory drops down at the first half-shutter press to 356368 bytes and with the next press down to 95200 bytes.
-
A bitmap buffer size of 960x240 = 230400, which is what the above test reports.
If you actually take a photo after memory has been allocated, does it crash ?
If not, we know memory allocation is not the problem.
Is image-review mode on ?
If so, maybe the Canon firmware tries to allocate memory.
-
Image review mode is on.
Currently the camera does not crash after releasing the half-pressed shutter button. I can take pictures, zebra looks 'almost' normal. What is still there, is this strange pixel line at the top of the screen...
-
I can take pictures, zebra looks 'almost' normal.
So, what has changed, why did it previously crash ?
Is the green line on the very first row ?
I suppose you could start zebra at row 2.
-
Good question. I am not so sure, after the tests with commenting out the zebra code in osd_draw (now the code is active again of course), its does not crash anymore... :blink:
And yes, the green line (it is not allways green, sometimes the color is mixed) is allways "stable" on the very first row. If will test if starting @row 2 helps.
-
So, what has changed, why did it previously crash ?
Ah, yes. If found the difference, since i changed #define ZEBRA_HMARGIN0 30 to #define ZEBRA_HMARGIN0 0, the crash was gone away. I switched back to #define ZEBRA_HMARGIN0 30 an the camera crashes again.
-
I also got rid of the random pixelline in row 0:
In gui_osd_zebra_init() i added a memclear after the two malloc calls:
scr_buf = vid_get_bitmap_fb();
#if ZEBRA_CANONOSD_BORDER_RESTORE
cur_buf_top = malloc(screen_buffer_width * ZFIX_TOP);
cur_buf_bot = malloc(screen_buffer_width * ZFIX_BOTTOM);
// ERR99: Added buffer memclear
if (cur_buf_top) memset(cur_buf_top,0,screen_buffer_width * ZFIX_TOP);
if (cur_buf_bot) memset(cur_buf_bot,0,screen_buffer_width * ZFIX_BOTTOM);
#else
cur_buf = malloc(screen_buffer_size);
#endif
-
I do the same in SDM at \core\main.c\allocate_imgbuf() :-
imgbuf = malloc(imgbuf_size);
if(imgbuf)memset(imgbuf,COLOR_TRANSPARENT,imgbuf_size);
So, what does that leave ..... edge overlay ?
-
Hmm, i never used edge overlay before (to be honest, before i started porting CHDK to the G11,
i only seen CHDK twice on another camera and have no really experience using CHDK... :haha ) , but i think it is allready working:
-
Yes, that looks good.
Useful for stereo photography of distant scenes with a single camera.
You can photograph a town from a hilltop, move a metre or so and use the edge-outline to line-up the second shot.
The two images form a stereo pair.
Because your brain assumes your eyes are about 70mm apart (not a few metres), it makes you think you are looking at a tiny model of the town !
If you save the edge overlay there is an option to save the zoom setting.
When reloading that overlay (maybe one year later), the camera should zoom to the correct position.
-
Hmm, i never used edge overlay before (to be honest, before i started porting CHDK to the G11,... but i think it is allready working
Whoo... GREAT, looks like the breakthrough is near! What else has to be done before a release of the CHDK-baby, ERR99? 8)
-kingcang
-
Yes, that looks good.
Useful for stereo photography of distant scenes with a single camera.
You can photograph a town from a hilltop, move a metre or so and use the edge-outline to line-up the second shot.
The two images form a stereo pair.
Because your brain assumes your eyes are about 70mm apart (not a few metres), it makes you think you are looking at a tiny model of the town !
If you save the edge overlay there is an option to save the zoom setting.
When reloading that overlay (maybe one year later), the camera should zoom to the correct position.
Wow, cool feature. I tried the save/load thing and the g11 really zoomes to the correct position. ;)
-
Whoo... GREAT, looks like the breakthrough is near! What else has to be done before a release of the CHDK-baby, ERR99? 8)
-kingcang
So, i think its time for a field test of the current (beta) version.
I cant test every chdk feature on the G11, so lets grow the numbers of testers to do this.
It would be great if you (and of course all other G11/CHDK interested people here) could test this version and post here
how it performs. So i am interested to know, if its stable enough for a release and if all main features are working (or not).
The known restrictions of this version are:
- ND-Filter support via CHDK disabled (assert crashes the camera)
- Remove directory does not work (if used e.g. via lua script)
- Parameter for RAW->DNG conversion are not fully updated. I need the values for cam_CFAPattern, CAM_COLORMATRIX1, cam_CalibrationIlluminant1, CAM_ACTIVE_AREA_xxx in camera.h, so maybe someone out here who knows how to get this values can evaluate this values with this release and post it here.
- The original g11 menus very often draw, scroll, etc. one the screen. This can lead to disappearing chdk menus. Simply push a button or use the jogdial in ALT mode an the menu will redrawn.
- The config autosave is still disabled for debugging reasons. If you wish to save your current config, select "Save options now..." in the CHDK Main-menu.
How to install:
- Make card bootable (e.g use cardtricks.exe)
- Copy the attached diskboot.bin into SD-Card root folder
- Optional: Copy the standard CHDK folder on your sd-card (to get the nice splash-screen and so)
- Make sure that the SD-Card write protect switch is set correctly, so CHDK can boot.
In case of an error (if the camera switches off / crashes), please re-power on the G11 and go into the "Miscellaenous stuff->Debug parameters" menu and choose "save ROMLOG.txt". After this, you have a romlog.txt into the root directory of your sd-card. This can be very helpfull to pinpoint the location of a crash. So if a crash happens, post here how to reproduce it and/or post the romlog.txt.
Key handling:
As usual, a short/standard press of the ON/OFF button powers the camera on into PLAY-Mode. To power on directly in to ON/Shooting mode, hold the ON/OFF key longer (ca. 1s). The ALT-Key is the "S"/Print button on the G11. To enter the CHDK Menu, power camera on, press ALT-Key and then the MENU key.
So, have fun with this version (hopefully :P ).
-
Good work !
Now, have a rest :)
-
Hi there,
I tried your DISKBOOT and found those things:
1) I set the camera to TV and select a shutter speed, for example 1/40.
Then I open the CHDK menu, and leave it again.
Now, the shutter speed is not 1/40 anymore, but 1/160.
Same happens with other shutter speeds, and happens also in M mode.
The ALT/S key in the original menu is set to the first option "Not Available".
2) The original histogram is enabled. I open the CHDK menu, and the histogram is now painted on top of the menu.
3) After leaving the CHDK menu, ALT is still enabled. Don't know if this is actually a bug, or if it is possible to disable that. I think it is a bit annoying.
Thank you anyway for the beta build!
cheers,
Benedikt
-
AWESOME work, ERR99! So far it looks great, athough that white stretched rectangle on the left side of the screen bugs me a little. It disappears upon pressing the shutter though. Then appears again. Furthermore I noticed that CHDK seems to appear as an overlay on top of the original G11 menue, which makes it look somewhat clumsy at times.
- Optional: Copy the standard CHDK folder on your sd-card (to get the nice splash-screen and so)
Where to get the mentioned folder? Splash-Screen? You bet! :P
-kingcang
-
athough that white stretched rectangle on the left side of the screen bugs me a little.
...the CHDK file space (http://chdk.wikia.com/wiki/CHDK_User_Manual#Filespace) indicator ;)
Where to get the mentioned folder?
Expand one of the full packages from the Autobuild Server (http://mighty-hoernsche.de/) to the card, delete the ps.fi2 and & replace the diskboot.bin with the G11 beta binary ;)
-
-
The Beta version was announced in ERR99's 99th post !
He must have known right from the start ::)
-
I can confirm this works on GM1.00K firmware, even though CHDK boot screen posts J.
I'm going to be honest, I'm a little sad. The only think that made my G7 better than G10/G11 was CHDK support. Esp now that my dad bought a G11 and I still have a G7. =[
I'm only visiting my dad atm, leaving in two weeks so I'm happy to do any testing till then.
-
-
I can confirm this works on GM1.00K firmware, even though CHDK boot screen posts J.
That is useful to know.
Do you know when the camera was bought ?
-
Hi
I have GM 1.00K as well. Bought it on Jan 8. And most of it works...
Another bug I found:
sometimes, when I open a sub-menu or go one menu back, the menu disappears. As soon as I press UP, DOWN or SET key or turn the wheel again, the menu appears again and everything works fine.
I tell how to reproduce it, it just happens some times.
cheers,
Ben
-
Thanks for the error reports so far, it looks like there is still work to do. :D
I got also response in the german CHDK forum, and there are some issues regarding script loading:
- Some scripts can not be loaded. I find out that the fopen() function failes to open some files (e.g. "A\CHDK\SCRIPTS\examples\eggtimer.bas"). It looks like that the current DryOs cant open files with a path lenght >32 characters. So if you cant load a script, put it in a shorter path, e.g. direct in the SCRIPTS folder.
- At least one script (md_burst) makes trouble if you try to load it. CDHK does not respond anymore and the scriptload menu looks
strange. If find out the it has something to do with the name tag in the script. CHDK gets very busy during the try to draw the script title into the scriptmenu. Current workarround to get it run, is to change the title in the script:
@title Fast MD Burst/Review + Mask 080411
to
@title Fast MD Burst
-
I have GM 1.00K as well. Bought it on Jan 8. And most of it works...
Oh, a new firmware version, interesting. We better check if the are major differences to 1.00J.
I can try to build a CHDK Version with integrated udumper, so you can dump your firmware onto sd-card
and post it here. So i can do a compare to the old version and see if there are adaptions needed.
-
I can try to build a CHDK Version with integrated udumper, so you can dump your firmware onto sd-card
and post it here. So i can do a compare to the old version and see if there are adaptions needed.
I think I could do it... but I have only Mac OS X, does udumper work here?
Ah just found out that I need only a bootable SD card... I have that :-). So if you upload the udumper image, I'll try it.
-
I can try to build a CHDK Version with integrated udumper, so you can dump your firmware onto sd-card
and post it here. So i can do a compare to the old version and see if there are adaptions needed.
I think I could do it... but I have only Mac OS X, does udumper work here?
Ah just found out that I need only a bootable SD card... I have that :-). So if you upload the udumper image, I'll try it.
Lets try a very simple version of a udumper. I modified my current beta version quick&dirty to dump the ROM onto SD-Card. I was to lazy to add a seperate menu item for that, so i am using the "save romlog.txt" to call the romdump function.
So please put the attached diskboot.bin on your bootable sd-card and start your camera in PLAY mode. Then enter the CHDK Menu: "Miscellaneous stuff"->"Debug parameters" and select "save ROMLOG.txt" and hit "FUNC SET" button. Then the camera should "freeze" for 3-5 seconds and then you will (hopefully) see the text "ROMDUMP finished!" at the top of the screen. Then remove the battery and take a look on the sd-card. Hopefully you have then a file on the root of the sd-card, called "ROMDUMP.bin" with a size of ca. 8MB. Please zip this file and upload it on the web and post the link to the romfile here.
Then we will see what we got. ;)
-
1) I set the camera to TV and select a shutter speed, for example 1/40.
Then I open the CHDK menu, and leave it again.
Now, the shutter speed is not 1/40 anymore, but 1/160.
Same happens with other shutter speeds, and happens also in M mode.
I cant reproduce this behaviour, is this happens all the time or is it a sporadic?. Please check if you have any overrides active. Is the "Value factor" for "Override shutter" in the "Extra Photo Operations" menu set to zero? Also check the setting for "Safety Shift" in the original canon camera menu. If this is set to "ON" it can lead to different shutterspeed then requested in TV-Mode.
2) The original histogram is enabled. I open the CHDK menu, and the histogram is now painted on top of the menu.
The original canon software is updating/drawing the histogramm all the time and CHDK does not know anything about it. So i think we cant do anything to prevent this. :(
3) After leaving the CHDK menu, ALT is still enabled. Don't know if this is actually a bug, or if it is possible to disable that. I think it is a bit annoying.
If you close the CHDK main menu via "MENU" Button, it is standard CHDK behaviour that you are still in ALT mode.
At least my other camera here with CHDK do it that way, so i think it is "normal". ;)
-
Thank you for the time, energy and brains that are going into this.
Mine loaded fine and ran a photo interval script fine. But I can only auto-boot it. I can't manual boot by loading a new firmware. (Which means, I think, I'm stuck with my 4gb card, and can't use my partitioned 16gb card).
-
-
Create/swap partition functions don't seem to work yet, so I can't get CHDK to work off my SDHC card (http://chdk.wikia.com/wiki/Bootable_SD_card#Windows:.C2.A0Case_.234)--stuck with using an old 32MB Canon SD card =D Not having a PS.FI2 adds to the complications (I think).
Edit:
Scratch that, I got dual partition booting to work. Had to use a replacement driver for my card reader to be able to copy CHDK on second partition, but at least now I can read both partitions at the same time. =]
-
Thank you for the time, energy and brains that are going into this.
Mine loaded fine and ran a photo interval script fine. But I can only auto-boot it. I can't manual boot by loading a new firmware. (Which means, I think, I'm stuck with my 4gb card, and can't use my partitioned 16gb card).
Good news: that's not true, it's just the other way around !
Manually booting CHDK (thru the 'Firm Update' menu) should work off all file systems (FAT12, FAT16, FAT32), while autoboot
requires FAT12 or FAT16, and is therefor limited to 4 GB maximum partition size.
hth,
wim
-
Thank you for the time, energy and brains that are going into this.
Mine loaded fine and ran a photo interval script fine. But I can only auto-boot it. I can't manual boot by loading a new firmware. (Which means, I think, I'm stuck with my 4gb card, and can't use my partitioned 16gb card).
Good news: that's not true, it's just the other way around !
Manually booting CHDK (thru the 'Firm Update' menu) should work off all file systems (FAT12, FAT16, FAT32), while autoboot
requires FAT12 or FAT16, and is therefor limited to 4 GB maximum partition size.
hth,
wim
I got partition booting working, as mentioned above. And no, manual booting doesn't work. AFAIK, camera checks for PS.FI2 file in card, which is different for each card. I don't think G11 development has gotten that far yet, which is why ERR99 tells users to make card bootable with cardtricks.
The problem in Windows is that it can't detect more than one partition on removable drives; but that's just a driver thing, not hardware. Follow the guide here (http://www.uwe-sieber.de/usbtrouble_e.html), look for the title "On flash drive only the first partition works". Basically, you're going to replace the driver used by Windows on your card reader, and it will be detected as a drive, much like USB hard drives.
Once done, you can format the SD card as you would HDD's. Partition one as FAT, two as FAT32 etc. Put CHDK on both partitions, and use cardtricks to make partition one bootable, and you're set. Bonus is now you don't need to use partition swap on CHDK before plugging into computer. =]
-
I got partition booting working, as mentioned above. And no, manual booting doesn't work. AFAIK, camera checks for PS.FI2 file in card, which is different for each card. I don't think G11 development has gotten that far yet, which is why ERR99 tells users to make card bootable with cardtricks.
I don't even have such a "Firmware Update" menu on my G11. Do you have one?
[...]
Once done, you can format the SD card as you would HDD's. Partition one as FAT, two as FAT32 etc. Put CHDK on both partitions, and use cardtricks to make partition one bootable, and you're set. Bonus is now you don't need to use partition swap on CHDK before plugging into computer. =]
The Downside is though, that if you do not want to use CHDK for a while and disable it by setting the SD-card to read/write, the camera only sees this small first partition... :-/
Is there a solution for this?
PS: Any MANY thanks to ERR99 for the work! I followed this thread the last weeks, but did not find any time to contribute. This may change though. At least I can test the port.
-
I got partition booting working, as mentioned above. And no, manual booting doesn't work. AFAIK, camera checks for PS.FI2 file in card, which is different for each card. I don't think G11 development has gotten that far yet, which is why ERR99 tells users to make card bootable with cardtricks.
I don't even have such a "Firmware Update" menu on my G11. Do you have one?
Nope, but again, as I mentioned several times already, you CAN NOT load CHDK manually. The G11 PS.FI2 hasn't been developed yet (AFAIK), so you can't update via "Firmware Update" menu. You need to place diskboot.bin (and CHDK folder from a full build if you want) on an SD card, and set to to bootable via cardtricks, as mentioned by ERR99.
[...]
Once done, you can format the SD card as you would HDD's. Partition one as FAT, two as FAT32 etc. Put CHDK on both partitions, and use cardtricks to make partition one bootable, and you're set. Bonus is now you don't need to use partition swap on CHDK before plugging into computer. =]
The Downside is though, that if you do not want to use CHDK for a while and disable it by setting the SD-card to read/write, the camera only sees this small first partition... :-/
Is there a solution for this?
PS: Any MANY thanks to ERR99 for the work! I followed this thread the last weeks, but did not find any time to contribute. This may change though. At least I can test the port.
Ohh...good point. *Takes a look at G11 without CHDK*
Hahaha, photo capacity: 1 photo
lol
-
Nope, but again, as I mentioned several times already, you CAN NOT load CHDK manually. The G11 PS.FI2 hasn't been developed yet (AFAIK), so you can't update via "Firmware Update" menu. You need to place diskboot.bin (and CHDK folder from a full build if you want) on an SD card, and set to to bootable via cardtricks, as mentioned by ERR99.
I know this. Thanks.
I use Linux only so I do not need special tools and drivers to setup my SD-Card. ;)
I was just wondering why I do not have this "Firmware update" menu entry. So this is only visible with a valid PS.FI2 file?
-
So this is only visible with a valid PS.FI2 file
menu entry should appear even if you stick an empty or invalid PS.FI2 in there -
if used it will give an error though
hth,
wim
-
My trys to build a working PS.FI2 version of my CHDK version was not very sucessfull.
It starts booting the "firmware update", but then "E31" is shown on the display, than the CHDK-Splash shows up
(but without CHDK-Logo, which is available on the SD-Card) and then the camera switches off (without creating any entry in the romlog).
Currently i dont have any clue whats going wrong here, and why it is not working that way. :blink:
-
- At least one script (md_burst) makes trouble if you try to load it. CDHK does not respond anymore and the scriptload menu looks
strange. If find out the it has something to do with the name tag in the script. CHDK gets very busy during the try to draw the script title into the scriptmenu. Current workarround to get it run, is to change the title in the script:
@title Fast MD Burst/Review + Mask 080411
to
@title Fast MD Burst
I find the root cause for the "crash" here, it looks like a bug in the CHDK core gui_menu.c function:
In the the case "case MENUITEM_SEPARATOR:" the xx coordinate calculation is done in that way:
j = rbf_str_width(lang_str(curr_menu->menu[imenu].text));
xx+=(w-j-len_space*2)>>1;
..
draw_line(x+len_space, yy+rbf_font_height()/2, xx-1, yy+rbf_font_height()/2, cl);
draw_filled_rect(x+len_space, yy+rbf_font_height()/2+1, xx-1, yy+rbf_font_height()-1, MAKE_COLOR(cl>>8, cl>>8));On the G11 (with a screen_width of 320 Pixels, and not with the "usual" 360), this calculation results with the md_burst title to a really big negative xx coordinate:
unsigned int w=260;
int j=272;
int lenspace=8;
int xx=30;
xx+=(w-j-len_space*2)>>1;
Result is: xx=-2147483632
So the following draw functions start to draw a really, really, long line over the hole RAM area, and crashes the camera.
I can workarround/bugfix this by adding a cast in that way:
xx+=((int)w-j-len_space*2)>>1;
or so:
xx+=(int)(w-j-len_space*2)>>1;
Both fixes the problem with the "unsigned int w", which seems to be the cause for negative xx result.
But the drawn result looks not so good, because the width is now correct (check attached photo).
Another way to fix the crash is to change the calculation of w in void gui_menu_init(CMenu *menu_ptr):
Original code: w = screen_width-30-30;
G11 fix version: w= screen_width-10-10;
This fixes the crash, and also the menu looks good on the G11. But why are here used "fixed" magics (-30) anyway?
So i think the calculation routines in gui_osd.c needs some updates to fix the problem with cameras which
have a screen_width smaller then 360 (which are working fine with the above "unfixed" calculation routine).
Should i open a new issue in the CHDK mantis bugtracking system for that?
-
On the G11 (with a screen_width of 320 Pixels
That is news !
The only other camera with that screen width is the SX200IS.
In camera.h:-
#define CAM_X_STRETCH 1 // 1 = no stretch, 2 = 2x, 3 = 9/4 times
value should be '3' to 'stretch' 320 to 720.
That is used by the draw pixel function.
-
Are you sure? I searched for CAM_X_STRETCH and cant find any occurence of that in CHDK.
In the SX200IS Port, the only reference to 9/4 is this:
#define ASPECT_XCORRECTION(x) ( ( ((x)<<3) + (x) ) >>2 ) //correction x*screen_buffer_width/screen_width = x*720/320 = x*9/4 = (x<<3 + x)>>2
And i allready use this seetings in my G11 Port. :blink:
-
In gui_draw.c, draw_init() calls 'draw_set_aspect_xcorrection_proc(NULL)' which selects 'aspect_xcorrection_std' that returns ASPECT_XCORRECTION(x).
For the SX200IS and G11 that returns ( ( ((x)<<3) + (x) ) >>2 ) which = 9x/4.
Anyway, you have already done that.
Screen width in the menus is a different issue I guess ::)
-
Hey guys,
I've been following you all since page 18 and you've been doing phenomenal work! I am still currently a G10 owner and wasn't planning on upgrading anytime soon, but I was wondering if you'd be able to create anything at all to work with the G10 or at the absolutely very least, allow me to override the shutter speed. I figured it wouldn't work, but I went ahead and loaded the Diskboot.bin that you had created and it of course didn't work. I thought maybe by some crazy strike of luck that just because they had the same DryOS and Digic IV processor that it'd magically work.
I was just curious as to how much work it'd be to create something for the G10. Anywho, thanks for your awesome work!
-
There's a G10 port thread (http://chdk.setepontos.com/index.php/topic,3661.30.html), which has stalled, you could try making some noise there. You'll need to either wait for someone who has a G10 and who is willing to work, or get down and dirty and do it yourself. Some of the effort used to get CHDK running on the G11 might help, but unless you get someone a G10 and somehow convince them to port it for you, you'll have to wait like everyone else.
-
Here is a second betaversion release of my CHDK build for the G11.
Changes in Beta V2:
- Enabled Config Autosave
- Fixed crash in Scriptmenu if @titel tag in scriptfile is very long.
- Enabled CAM_QUALITY_OVERRIDE, so SUPERFINE JPEG compression is now available via CHDK.
PS.FI2 Version of build is still not working correctly. The G11 switches off, shortly after start of CHDK (and shows Errorcode E31). So only diskboot.bin version is available.
-
my CHDKed A620 "left me" three months ago...
so I bought my G11 just hoping someone would start soon with the new building...
ergo... ERR99, you're my hero!
Thanks for all your efforts :)
-
I have been following this for the past month, and was thrilled to see a beta version of the build. Went out and purchased the G11 today, with the 100j version of the firmware loaded. I had been using a G9 and the SDM version of CHDK, along with a Intervelometer Script. I powered up the G11, and the script worked great on the first try. Awesome! I'd be happy to help test the build, and will post any issues as I find them. Thank you!
-
Not sure if you even want issues with scripting on the G11 posted here, but I found something that works on my G9, but not the G11.
:shoot_video
press "dm_movie"
sleep 3000
press "shoot_full"
sleep 500
release "shoot_full"
sleep 3000
rem start of video delay loop
for n=1 to h
sleep 1000
next n
press "shoot_full"
sleep 500
release "shoot_full"
sleep 3000
release "dm_movie"
sleep 3000
return
This is part of the Wind Watcher KAP script, and this routine allows for video recording. The entire script has an option for the user to select if they want video, or just pictures as part of an intervelometer. If I don't call this routine, the script works fine.
-
That is an old WindWatcher script that used Dave Mitchell's original method of switching to movie mode.
It relies on overriding the memory-mapped I/O value of the mode dial position.
The G11 port (and CHDK) do not support that.
As Dave mentioned on the KAP Group, SDM added the simpler 'shoot_movie_for' uBasic command.
e.g.
shoot_movie_for 15
captures a fifteen second movie.
When SDM is ported to the G11 that command (and other KAP features) will be supported.
That will include control of a forthcoming commercail device.
-
Not sure if this is the place to ask but will there be a Bulb setting, allowing the shutter to remain open as long as the shutter is depressed (by a remote)??
Thanks,
Steve
-
I have a G11 with firmware version GM1.00F and when trying to load the DISKBOOT.BIN from this thread the camera appears dead. It shows no response to pressing the on/off or play buttons. It stays that way until i unlock/switch the sd card and remove the battery for a second. What would you suggest i should do to dump the firmware? If possible i could also update to the latest firmware version.
-
I have a G11 with firmware version GM1.00F and when trying to load the DISKBOOT.BIN from this thread the camera appears dead. It shows no response to pressing the on/off or play buttons. It stays that way until i unlock/switch the sd card and remove the battery for a second. What would you suggest i should do to dump the firmware? If possible i could also update to the latest firmware version.
It is not possible to update the firmware of your camera unless Canon brings out an updated firmware, which it has not done for the G11. The differences between firmware versions like 1.00f, g and h are usually very small, but, as you have discovered, can be big enough to need another version of CHDK.
So I would advise you to dump this firmware version and maybe someone can look at it and see if they can adapt the current beta for this firmware version.
-
I have a G11 with firmware version GM1.00F... What would you suggest i should do to dump the firmware? If possible i could also update to the latest firmware version.
Lets try a modified udumper. I am not sure if it works with 1.00F, but we will see. ;)
So do this steps:
- Use cardtricks to create a standard udumper sd-card with the dummy file (Click on "NewDryOs" button)
- replace then the diskboot.bin on the sd-card with the attached one
- Switch on write protect on the sd-card, put it in the camera, and start camera in playmode.
If everything works, you will see that the ISO-LED and the AF-Light goes on. If it so, wait 1..2 Minutes, then remove the battery and check the dump in cardtricks with the "Strings" button. If you see a lot of ASCII Strings/Text everything works ok. Use then the "clean" button to let cardtricks remove the useless trailing bytes and save the resulting dump on your harddisk.
-
#1 - Awesome work! I have been watching from day one and you all have come a long way in a short time. Very exciting stuff.
#2 - Here is the rub: What are the chances of getting HD video working on the G11? This is one of those features that I think is probably within the capability of the G11 hardware but might have left out of the C firmware by C on purpose.
#3 - I also would like to see the ability to set a maximum ISO on the AUTO setting.
HD is the BIG question...
I am still working on getting this setup on on a 128 MB SD card. Since I am on a Mac I am using the Terminal to do this and it does not like the size of the card...even though I have seen someone on this forum running CHDk off of a 32 MB card (I think).
THANKS!
-
CHDK only needs a couple of megs, aside from extras like scripts. Make sure you have the card preped for autoboot; since there's no PS.FI2 file, you can't boot CHDK from the Firmware Upgrade menu.
ERR99 is still working to get the basic features of CHDK working; also, I assume no other CHDK build has HD support, so HD video is probably still a while yet.
-
#2 - Here is the rub: What are the chances of getting HD video working on the G11? This is one of those features that I think is probably within the capability of the G11 hardware but might have left out of the C firmware by C on purpose.
The sensor of the G11 does not support HD video, so this will not be changed bij CHDK. Apparently, a higher sensitivity sensor makes it more difficult to have high video resolution. Therefore Canon chose not to have HD, but to have higher ISO capabilities.
The sensor can handle a bit higher resolutions as VGA, but not 720p or higher.
See for more info this thread on dpreview:
http://forums.dpreview.com/forums/read.asp?forum=1010&message=34005427 (http://forums.dpreview.com/forums/read.asp?forum=1010&message=34005427)
-
#2 - Here is the rub: What are the chances of getting HD video working on the G11?
Almost certainly zero.
This is one of those features that I think is probably within the capability of the G11 hardware but might have left out of the C firmware by C on purpose.
Very unlikely. The camera market is very competitive, HD is a significant selling point, and Canon doesn't have anything higher in that the same line-up that does HD. Conclusion: If they could just turn it on, they would.
-
Lets try a modified udumper. I am not sure if it works with 1.00F, but we will see. ;)
Thank you for the detailed instructions. Please find below the link to the renamed "empty.dum".
g11_100f.7z - 1.92MB (http://www.zshare.net/download/716207431e79c7a6/)
-
Cool, the modified udumper works, dump looks good!. :D
-
Added the G11 1.00f dump from this post (http://chdk.setepontos.com/index.php/topic,4647.msg46189.html#msg46189) (8MB, from "my_username", dumped with a modified udumper) to the drop.io - chdkdumps2 (http://drop.io/chdkdumps2) backup archive.
http://drop.io/chdkdumps2/asset/g11-100f-7z
Thx to the 'dumpers' & uploaders !
-
BTW, did you see my K dump several pages back?
-
BTW, did you see my K dump several pages back?
Yes ;)
Added the G11 1.00k dump from this post (http://chdk.setepontos.com/index.php/topic,4647.msg46054.html#msg46054) (8MB, from Kaydat, dumped with a modified 100j CHDK version) to the drop.io - chdkdumps2 (http://drop.io/chdkdumps2) backup archive.
http://drop.io/chdkdumps2/asset/g11-100k-7z
Thx to the 'dumpers' & uploaders !
-
Oh, groove E. =]
-
1.00k has some differences to 1.00J, but nothing CHDK code related. Looks like "only" some data has changed.
The main difference in the important upper 4MB region is only the build-date:
Sep 28 2009 08:45:15 vs. Oct 27 2009 15:33:17
So it looks like that there are no changes necessary for 1.00k, the 1.00J build should be ok.
For 1.00f, there is work to do. There are more changes, and after a first quick look i can say, at least boot.c needs to
be updated.
-
-
-
-
Can you post your modified udumper source ? It would be great to come up with a modification that works generically on new cams
Funny, i've just been working on upgrading the CardTricks udumper section this afternoon - so i'm also interested
keep up the good work,
wim
-
I am not a home, so i dont have the source available. But i can tell you what i did.
1) The WriteSDCard functions seems to have now to additional function parameters. At least, i have to add two int/"0" parameter at the end of function call/prototpye to get it write something on the sd-card.
2) For finding the WriteSDCard funtion adresses, i use a very, very simple aproach, i dont think it will work on much other cameras, but it is at least good enough for g11. ;) After checking several firmware dumps of other ports, i see that the variables with the function pointers for Read/Write-SD Card are allways short behind the "DISKBOOT" string. So im simply search for that at take the next data that looks like a flash adress in the upper 4MB of the camera as WriteSDCard function address. What differs is, which of the both function adresses is for read and which is for write. For the G11, its seems it is allways the first one.
-
Lets try a modified udumper. I am not sure if it works with 1.00F, but we will see. ;)
Thank you for the detailed instructions. Please find below the link to the renamed "empty.dum".
g11_100f.7z - 1.92MB (http://www.zshare.net/download/716207431e79c7a6/)
Now a first bootable version of the 1.00f port is ready. I dont have a G11 with 1.00f Firmware to test it, i got some help in the german chdk forum to get this port running (thanks goes to genervi and kriki :) ). Hopefully here are also some 1.00f users who wants to test the current 1.00f beta version. So here it comes:
-
You are working very hard :)
When do you think the builds will be ready to add to the trunk ?
-
Now a first bootable version of the 1.00f port is ready. I dont have a G11 with 1.00f Firmware to test it, i got some help in the german chdk forum to get this port running (thanks goes to genervi and kriki :) ). Hopefully here are also some 1.00f users who wants to test the current 1.00f beta version. So here it comes:
It seems to be working. The only bug i've encountered so far is that the button with the flash sign (right of func set) is not working when in playback mode. For example when zooming into a picture i've taken i can scroll up, down and left but not right.I'm new to chdk and i have not tried all of the new features yet. Overriding the shutter speed and zebra are working fine and i really like it. Thank you very much!
-
It seems to be working. The only bug i've encountered so far is that the button with the flash sign (right of func set) is not working when in playback mode.
Oh yes, you are right, a bug! I played arround with altmode keymasking and used a wrong keymask. ;)
So here comes 1.00f Beta V2, now also the right/flash key should work in playmode.
-
Oh yes, you are right, a bug! I played arround with altmode keymasking and used a wrong keymask. ;)
So here comes 1.00f Beta V2, now also the right/flash key should work in playmode.
The key now seems to be working properly. Thank you!
-
When do you think the builds will be ready to add to the trunk ?
The main part of the port is now done i think, i did not heared anything about real show-stopping bugs.
But for a integration into the trunk, there are adaptions in the CHDK core needed (releated to the new dryos #r39 features, e.g. the stat() function). I rebased my build to the current trunk, but as far i can see, this changes (from RaduP, see SD980 porting thread) are still not available in the trunk. Or is there another developing/experimental/testing branch available for new ports? I used this one for my work: https://tools.assembla.com/svn/chdk/trunk
Also the gui core needs a bugfix to avoid camera crash, caused by long script titles and "small" bitmap display width.
Another unsolved problem is the strange behaviour of the Firmwareboot/PS.FI2 methode ("E31" errorcode is shown during startup of CHDK, then camera shuts down without producing a error log).
-
Okay, i think my work on the G11 port is now done. So i posted the sources here: http://chdk.setepontos.com/index.php/topic,650.msg46343.html#msg46343. (http://chdk.setepontos.com/index.php/topic,650.msg46343.html#msg46343.) :D
-
Here is a second betaversion release of my CHDK build for the G11.
Changes in Beta V2:
- Enabled Config Autosave
- Fixed crash in Scriptmenu if @titel tag in scriptfile is very long.
- Enabled CAM_QUALITY_OVERRIDE, so SUPERFINE JPEG compression is now available via CHDK.
PS.FI2 Version of build is still not working correctly. The G11 switches off, shortly after start of CHDK (and shows Errorcode E31). So only diskboot.bin version is available.
I tested the CHDK features on my A610 and now I have the latest V2 (for FW GM1.00J) installed on my G11. With CAM_QUALITY_OVERRIDE enabled (works as described in the CHDK handbook) I took pairs of shots with quality sup.fine and without (toggle: shutter half released and button DOWN pressed).
Using the internal file browser I compared the size of the files. There was no difference in most cases.
Is the difference in quality really so minimal that it cannot be judged from the file size ?
Did anyone alread test this feature?
-
The G11 port is now in the official CHDK source tree (since changeset #871 (http://tools.assembla.com/chdk/changeset/871/)).
The latest binaries are available from the CHDK Autobuild server (http://mighty-hoernsche.de/).
The autobuild server now serves 3 G11 versions (BETA state):
- G11 1.00f
- G11 1.00j
- G11 1.00k (this is simply a copy of the 1.00j version, it will also report 1.00j in the splash screen / CHDK fw info box)
Note: the manual loading method (ps.fi2, with "Firmware update" from the Canon menu) does NOT WORK yet !
-
I tested the CHDK features on my A610 and now I have the latest V2 (for FW GM1.00J) installed on my G11. With CAM_QUALITY_OVERRIDE enabled (works as described in the CHDK handbook) I took pairs of shots with quality sup.fine and without (toggle: shutter half released and button DOWN pressed).
Using the internal file browser I compared the size of the files. There was no difference in most cases.
Is the difference in quality really so minimal that it cannot be judged from the file size ?
Did anyone alread test this feature?
The file size difference is huge. I (re)tested the feature (also the V2 Beta) and superfine works normal (i think). I got a filesize differences (between fine and superfine) from 1..2 MB, if i shoot the same scene.
-
The G11 port is now in the official CHDK source tree (since changeset #871 (http://tools.assembla.com/chdk/changeset/871/)).
Cool! Thanks for the very fast integration! :D
Hopefully now also other developers with a G11 can help to fix this nasty PS.FI2 problem (i have currently now idea why this "E31" error is shown) , and maybe this codebase helps pushing the S90 CHDK port a little.
-
Thanks for the very fast integration! :D
In the next few days I will try to port to SDM, that should keep me occupied for some time !
maybe this codebase helps pushing the S90 CHDK port a little.
It is a pity that rachelkitty seems to have walked away from this.
We have not heard anything from the person who started that thread either.
-
Nice to see the progression of G11 CHDK development. I know I didn't contribute much at all, but I'm departing from Hong Kong tomorrow, leaving behind my dad's G11 as well, which means I can't contribute anything any more. ='[
Best of luck, I'll be keeping an eye on the thread with my trusty old G7 next to me. =]
-
Great job guys. I've been very busy lately and I missed this thread, but I am glad my previous work helped you.
If you need my latest SD980 source, let me know.
-
i'm thinking about buying one. anyone know if the g11 will power on when usb is plugged in?
-
Nope. No automatic power on via usb-cable. You have to press PLAY or ON/OFF button, after connecting the usb-cable, to power on the G11.
-
I have started trying to port to SDM.
A bit of a pain as I use Canon shooting-mode values.
I found string AC:PTM_Init but do not recognise any likely mode values nearby.
I have asked someone to monitor property case 49 while rotating the mode dial.
-
Hi,
take a look at shooting.c, the values of Propcase 49 for G11 are the same as in the modemap array:
tatic const CapturemodeMap modemap[] = {
{ MODE_AUTO, 32768 },
{ MODE_P, 32772 }, // also C1,C2
{ MODE_TV, 32771 },
{ MODE_AV, 32770 },
{ MODE_M, 32769 },
{ MODE_VIDEO_COLOR_ACCENT, 2601 },
{ MODE_VIDEO_COLOR_SWAP, 2602 },
{ MODE_VIDEO_STD, 2603 },
{ MODE_SCN_NIGHT_SNAPSHOT, 16395 },
{ MODE_SCN_LANDSCAPE, 16396 },
{ MODE_SCN_PORTRAIT, 16397 },
{ MODE_SCN_NIGHT_SCENE, 16398 },
{ MODE_SCN_KIDS_PETS, 16400 },
{ MODE_SCN_INDOOR, 16401 },
{ MODE_SCN_SUNSET, 16402 },
{ MODE_SCN_FOLIAGE, 16403 },
{ MODE_SCN_SNOW, 16404 },
{ MODE_SCN_BEACH, 16405 },
{ MODE_SCN_FIREWORK, 16406 },
{ MODE_SCN_UNDERWATER, 16407 },
{ MODE_SCN_AQUARIUM, 16408 },
{ MODE_SCN_SPORT, 16903 },
{ MODE_SCN_STITCH, 16906 },
{ MODE_SCN_COLOR_ACCENT, 16923 },
{ MODE_SCN_COLOR_SWAP, 16924 },
{ MODE_LOWLIGHT, 32799 },
{ MODE_QUICK, 33313 }
};
-
I found string AC:PTM_Init but do not recognise any likely mode values nearby.
The actual mode table is several functions away from the reference to this string. The patter is very similar on all recent cameras.
For G11 100j the canon mode list is at FFBE7010
-
Yes, thanks, I found it after the tester sent me the results so I was able to tell him he had missed two of the video modes.
I do not have the stamina to wade through endless compiler errors right now, I will continue tomorrow.
-
-
-
-
@ERR99:
Did you ever find the address for _GetCurrentTargetDistance() ?
I am told the G11 has a ND filter.
If correct, that should be added to camera.h.
-
No, currently i dont know the adress for GetCurrentTargetDistance(). But i can try to find it. ;)
An yes, the G11 has a ND-Filter, but snapping the ND-Filter in/out via CHDK makes trouble. The ND-Filter
reacts as expected if activated/deactivated via CHDK, but after a 1-2 seconds the original canon software throws an
assert and the camera switches off. So it is currently not very usefull, and thats the reason why i removed the
ND_FILTER option for the G11 in camera.h
-
@ERR99
Porting to SDM was reasonably easy apart from edge-outline which I am struggling with a little bit.
(I do it slightly differently than CHDK, including for the SX200IS .. which works).
You are allocating 720x240x3 bytes of memory for the live-image 'viewport'
That implies the viewport is 1440 pixels wide, is that really correct ?
Each row is incremented by 720x3 bytes and I guess it works.
When drawing to the bitmap buffer, you scale the 'x' value by 8/9 as the screen is 320 wide and the bitmap buffer screen width is 360.
This is a little confusing as the SX200IS bitmap screen width is 720 so in SDM I scaled 'x' by 9/8.
In camera.h, you have said that the viewport is 360x240.
This is getting a little complicated ... what area of the bitmap buffer does the Canon firmware render to the 320x240 screen ?
Is each pixel drawn twice, as with the SX200IS.
Apart from the viewport width, all other parameters for the G11 are the same as the SX200IS.
-
Recently got a G11 (few hours ago) and did a vers.req and got - 1.00H
Could this be a similar situation as the G9 where I can use chdk for 1.00X = FirmWare 1.00H
where X could be 'f' 'j' 'k'
A quick search of the forums didnt reveal a hit with G11 & my "H" firmware so I though I'd ask
Edit: I'll take the time to get a dump and post the resutls in the day or two.
zepp
-
Only you can answer that question, why don't you just try it ?
David
-
Results of Beta with G11 with firmware 1.00H.
Both J & K seem to work with menus and splash. Splash screen shows 1.00j as the firmware for both. I'll test further for operation and scripts with each.
CHDK for 1.00F will not power up.
-
@zepp
Congrats, you're a lucky person (statistically, the chance for this to happen is only 1 in 7)
Since the 'k' version is generated from the same source as 'j' it shows the same version;
I suppose the same will apply to your 'h' version - it should take a dev only minutes to
add this to the source tree.
cheers,
wim
-
A simple question for understanding RAW in chdk and G11 (chdk handbook and wiki hasn't enlighted me):
Does everything in the RAW menu of chdk is only supposed to work with the chdks own RAW files (and not the CanonCR2 which are produced by the camera itself)?
I tried to "develop" a CanonCR2 with the function in the chdks RAW menu and it didn't work. I guess... it will only work with ChdkRAW? Or is it a bug and it should work with CanonCR2s? (a late develop of RAW is interesting, because the camera only prints JPGs)
Therefore I guess, the badpixel function may only map the bad pixels in ChdkRAWs and DNGs and not in the CanonCR2s?
Please tell me... is that right or is that wrong?
-
I tried to "develop" a CanonCR2 with the function in the chdks RAW menu and it didn't work. I guess... it will only work with ChdkRAW?
Only CHDK RAW files supported by Develop RAW command.
Canon CR2 files have completely different format and they are compressed - it is impossible to develop them.
Therefore I guess, the badpixel function may only map the bad pixels in ChdkRAWs and DNGs and not in the CanonCR2s?
There are two badpixel patching processes:
1. using badpixel.bin
2. using badpixel or badpixel.txt
First (badpixel.bin) is used only when saving DNG in camera.
Second (badpixel or badpixel.txt) is used to remap bad pixels.
Remapping is applied to RAW data directly after shooting before any camera processing - so this will have influence to all images: CHDK RAW, Canon CR2 and JPEG image.
-
Hi everyone, thanks for all your work, great stuff. One question - I'm having trouble getting the shutter speed override to work correctly. The correct override values show up in the OSD, and while the aperture override seems to work well, I'm unable to get shutter speeds faster than 1/4000. I've tried increasing the aperture to the maximum value possible, but to no avail. Any ideas?
-
@thanh,
If I set 1/100k as Tv, the camera gives me a 1/4000 in the display... but I guess, this is conform to the chdks manual. There is written, that also the exif info would be wrong = set to the maximum value, which are just plausible for the camera.
If I take photos with 1/100k they are very dark -- therefore, the Tv is much higher than 1/4000... but to know the real Tv, one has to take test shots under constant lightning conditions with different TVs.
to know exactly the override values, you could display them with chdk in the display.
-
I tried to manually activate/deactivate the override values via HalfPress+DOWN (or HalfPress+UP = G7)... but both procedures didn't work.
Is this a bug? Or is this feature set to other key/button combinations for the G11?
-
but I guess, this is conform to the chdks manual. There is written, that also the exif info would be wrong = set to the maximum value, which are just plausible for the camera.
If I take photos with 1/100k they are very dark -- therefore, the Tv is much higher than 1/4000... but to know the real Tv, one has to take test shots under constant lightning conditions with different TVs.
to know exactly the override values, you could display them with chdk in the display.
Yes.
The Canon firmware only knows the "own", Canon values; the Canon OSD shows the nearest known value, e.g. the max. available Canon Tv value.
Since the Canon firmware also writes the EXIF data, it's the same with the those values.
But there are also some useful informations in the EXIF meta data area: the camera writes some CHDK-overwritten (real) values to the EXIF makernotes...
To handle the EXIF data (and also view/edit the makernotes there), there's Phil Harvey's great ExifTool (http://www.sno.phy.queensu.ca/~phil/exiftool/).
-
I tried to manually activate/deactivate the override values via HalfPress+DOWN (or HalfPress+UP = G7)... but both procedures didn't work.
First check whether Disable Overrides is set to OFF,
then try other half-press key combinations, e.g. half-press + left (Ixus series)...
With the correct key you'll see NO OVERRIDES on the OSD...
-
"Yes. The Canon firmware only knows the "own", Canon values; the Canon OSD shows the nearest known value, e.g. the max. available Canon Tv value.
Since the Canon firmware also writes the EXIF data, it's the same with the those values."
Yeah, although the canon firmware is able to display correctly higher apertures when I use the override aperture function - e.g. the canon firmware will display an aperture of 11 , when without chdk running too, it can't get that slow.
The Tv values displaying using the OSD are correct (i.e. the overrided values e.g. 1/10,000), but the exposure seems to be exactly the same for 1/100k as 1/4k, with the same ISO and Av. Will try that exif tool and report back ..
-
Have looked at the exif data using the above tool, and it seems that the Tv has maxed out at 1/4,000 on all the shots I took, even when the override was set to a much faster value. Any ideas?
-
First check whether Disable Overrides is set to OFF,
then try other half-press key combinations, e.g. half-press + left (Ixus series)...
With the correct key you'll see NO OVERRIDES on the OSD...
Okay... that solves the Problem ;-) -- I should have read the manual more carefully
Could this override on/off mapped to some other key/button combinations (maybe as function in one of the chdk menus)? The ring/quadbutton is not easy to press with half pressed release button; especially under circumstances like darkness or cold and clumsy fingers. The two buttons above the ring/quadbutton have no function while the release button is half pressed.
-
Have looked at the exif data using the above tool, and it seems that the Tv has maxed out at 1/4,000 on all the shots I took, even when the override was set to a much faster value. Any ideas?
I guess, one has to use the Tv-mode (on dial) to use the override values. I just tried Tv and Av overrides and set M on the dial. That worked... I just took a photo with 1/1000 and f2.7 ... 1/4000 and f2.7 via override (and not set via the Canon own settings).
Just in the moment I wanted to try 1/8000 and f2.8 (and look if the picture is visibly darker) my battery gave up ... that brings me to the question: Is the last battery readout saved somewhere (in some hidden debug data)? It was something between 7V and 6.7V ... I would like to know the exact value for battery calibration.
-
Ah Sorry, just remembered one more thing - I can override Tv for values lower than 1/4k, but anything faster that doesn't work. It's the fast speeds that I'd like access too
-
@thanh:
Yeah, although the canon firmware is able to display correctly higher apertures when I use the override aperture function - e.g. the canon firmware will display an aperture of 11 , when without chdk running too, it can't get that slow.
Often the Canon firmware tables contain values which are not available from the Canon settings, e.g. ISO values lower than 80 or 50...
Have looked at the exif data using the above tool, and it seems that the Tv has maxed out at 1/4,000 on all the shots I took, even when the override was set to a much faster value. Any ideas?
+I can override Tv for values lower than 1/4k, but anything faster that doesn't work.
Maybe it's an issue known on some newer cameras, the "Extended Ev (http://chdk.setepontos.com/index.php/topic,4392.msg41875.html#msg41875)" issue...
E.g. on the SX10, the fast speed shutter overrides need to be set different to other cameras in the CHDK code...
-
-
-
Hello. I just wanted to know what min/max voltage values will provide the best battery percentage for my G11. I tried searching the thread to see if it had been posted earlier but found nothing. Sorry of i'm asking again.
Thanks.
-
Hello. I just wanted to know what min/max voltage values will provide the best battery percentage for my G11. I tried searching the thread to see if it had been posted earlier but found nothing. Sorry of i'm asking again.
I use max = 8.00V and min = 6.750V ...
my "measured" max value is roughly 8.2V, but with a smaller value, the percentage doesn't got immediately below 100% ... the battery discharges in the beginning very fast, I think... maybe I will set my max value to 7.750V ...
my "shutoff" min Value is 6.6V -- but the time between the drain from 6.75V to 6.6V isn't large at all, therefore I have a very litte backup time.
After all... you have to find the values of your own battery. Especially, if you use non-Canon batteries.
-
One question... I don't know, if this behaviour is correct or not.
If I start my G11 without CHDK via "On-Button", the lens extends and the camera is in "picture taking mode".
If I start my G11 with CHDK via "On-Button", the lens is inside and I have to press Half-Release to get my camera into "picture taking mode".
Is this wished? Is it possible to go directly into "picture taking" with CHDK?
-
@KaLi
That's normal behaviour ... keep "ON" pressed until CHDK logo appears (a second or so)
and you can boot straight into shoot mode.
HTH,
wim
PS note that this can easily be changed in the CHDK source code, but for most (?) users this setting
is the most secure (protection against accidental lens extension while in pocket/bag)
-
Deleted.
-
-
Some kind of bug-report / feature request.
When I swivel the display facing toward the front of the camera, the CHDK display messages are not upside down but mirrored. It would be nice, if the display is painted correct -- and automatically switched, of course. ;-)
-
When I swivel the display facing toward the front of the camera, the CHDK display messages are not upside down but mirrored.
You can set "Reverse Disp." to OFF in the Canon menu...
-
You can set "Reverse Disp." to OFF in the Canon menu...
I guess (I have my cam not by the hand), this would result in an upside down view on the display... therefore the chdk messages would also be upside down, but (as positive effect) not mirrored anymore ;-) .
So... I have to learn to read mirrored messages or upside-down messages (in connection with upside-down display readouts).
By the way... it's easy to read mirrored text.... but reading mirrored numbers is very confusing ;-)
-
By the way... it's easy to read mirrored text.... but reading mirrored numbers is very confusing ;-)
i cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno't mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Azanmig huh? Yaeh and I awlyas tghuhot slpeling was ipmorantt!
(thanks to Cybercom)
-
Well, that's easy for you to say.
-
But try to read that mirrored...
looks somehow cyrillic to me :D
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fimg230.imageshack.us%2Fimg230%2F5493%2Fmirrorm.jpg&hash=be52f8b496282d818a498f19b3228618) (http://img230.imageshack.us/i/mirrorm.jpg/)
-
Just received my G11 today and made a dump of the 1.00L firmware as I havent seen this anywhere yet :(, I used ERR_99`s modified udumper bin and it seems to have worked fine...
G11_100L.7z - 1.92MB (http://www.zshare.net/download/735579769073332e/)
If the wizzes could take a look that would be fantastic :) thank you
-
Hi everyone,
I've been mucking about with CHDK on an old TX1 and have been so impressed I went out and bought a G11.
its has the 1.00L version of the firmware, anyway im keen to help to get it working.
Heres what i got using the ver.req file.
Canon PowerShot G11
P-ID:31DF NT D
Firmware Ver GM1.00L
NoError
Jan 7 2010 13:21:02
Adj Ver.003.009
SubCPU Ver 0.06
Mecha Frim Ver. 3.04
I used the mac installer script to try out the K version.
Turn the camera on and nothing visible happens.
Take the card out, still nothing happens.
Remove the battery and put in back in without the card and the camera boots as normal without chdk. (phew).
maybe i should not have even tried that but I'm still under warranty :)
I've got a Software engineering background but am new to firmware programming.
I've also had a go at compiling CHDK, but I cant compile the ARM GCC toolchain on Snow Leopard. (still working on this)
Anyway, I'm keen to help. Do we need another firmware dump or is the one above enough?
cheers, Marc.
-
Hello & welcome, Marc !
Do we need another firmware dump or is the one above enough?
One dump is enough...
--> http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version (http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version)
(btw - there are only 2 real G11 development versions, the 100f & the 100j)
Good luck & have fun ;)
-
Awesome, thanks.
Just what i need to get me started.
-
Marc, I guess owners with the G11 and 100L firmwares will be coming out of the woodwork more and more now, so hopefully a port will be looked at with the developers on this one soon.
I had the same as you with booting up a different firmware, tried them all, absolutely nothing. Bit scarey as I didnt expect that at first.
-
Hello.
I have made some analysis and found custom white balance property case.
Information is stored in Wiki here: http://chdk.wikia.com/wiki/PropertyCase#PropertyCase_NOT_found (http://chdk.wikia.com/wiki/PropertyCase#PropertyCase_NOT_found)
Developers with access to camera now needed to verify this property case value.
If value is correct please update wiki (move value to table) or post information here and I will update it myself.
The format of custom WB data is the same as for other cameras: 28bytes of data (7 ints).
-
Just received my G11 today and made a dump of the 1.00L firmware as I havent seen this anywhere yet :(, I used ERR_99`s modified udumper bin and it seems to have worked fine...
G11_100L.7z - 1.92MB (http://www.zshare.net/download/735579769073332e/)
If the wizzes could take a look that would be fantastic :) thank you
Oh dear, another FW for the G11... Anyway, the fw-dump looks good. A binary compare to the old fw-versiones shows a lot of changes, so it is normal that the current versions of CHDK are not working for 1.00L. I am currently a little bit busy, so i dont know exactly when i will find some free time to start a "blind" port CHDK for the 1.00L fw-version. I still only have the 1.00J FW on my G11, so i cant test a 1.00L fw port on my camera.
-
Oh dear, another FW for the G11... Anyway, the fw-dump looks good. A binary compare to the old fw-versiones shows a lot of changes, so it is normal that the current versions of CHDK are not working for 1.00L. I am currently a little bit busy, so i dont know exactly when i will find some free time to start a "blind" port CHDK for the 1.00L fw-version. I still only have the 1.00J FW on my G11, so i cant test a 1.00L fw port on my camera.
ERR99 The fact your thinking about looking at another port with this firmware change is massively appreciated by all Im sure. :), so we`ll keep our fingers crossed :D. Thank you, and keep up the excellent work.
Im guessing these slight firmware changes are bug issues
-
Marc, I guess owners with the G11 and 100L firmwares will be coming out of the woodwork more and more now, so hopefully a port will be looked at with the developers on this one soon.
Don't expect too much from me, ill have crack at it, but in time, I'm a pretty rusty old programmer. A lot of this stuff is new to me, and fascinating too. An amazing project, hats off the developers.
cheers.
-
Marc, I guess owners with the G11 and 100L firmwares will be coming out of the woodwork more and more now, so hopefully a port will be looked at with the developers on this one soon.
Don't expect too much from me, ill have crack at it, but in time, I'm a pretty rusty old programmer. A lot of this stuff is new to me, and fascinating too. An amazing project, hats off the developers.
cheers.
You may want to check out http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version (http://chdk.wikia.com/wiki/Adding_support_of_a_new_firmware_version)
edit:
and I might want to read more carefully and see that fe50 already linked it ;)
-
Added the G11 1.00L dump from this post (http://chdk.setepontos.com/index.php/topic,4647.msg47327.html#msg47327) (8MB, from sam_m, dumped with ERR_99's modified G11 udumper) to the drop.io - chdkdumps2 (http://drop.io/chdkdumps2) backup archive.
http://drop.io/chdkdumps2/asset/g11-100l-7z
Thx to the 'dumpers' & uploaders !
-
Okay, here is my first try of a 1.00L port. It is completely untested, so users with 1.00L FW, please check what happens if you try to start the attached diskboot.bin. If i dont make any mistake, chdk should work as expected. But we will see... it is also possible the the camera crashes or does not boot. Then there is more work to do... ;)
-
Okay, here is my first try of a 1.00L port.
Boots up fine, from here will further testing be 1.00L specific?
I quicky ran the lua lib test script.
io OK
os FAIL 2
string OK
-
Nice, so its booting. :)
The "os FAIL 2" is also with the other FW versions, so no 1.00L specific Problem (removedir makes trouble in this test).
Ok, the current result shows me that boot & keyboard task modifications are working. Please also test if exposure & movie overrides are also working. So please enable some overrides in the chdk picture & movie menu and test if the are working (e.g. exposure or ISO override and zooming and/or AF-rescan during video).
-
1.00L working fine for me too, so many options, im not used to this from the A620, ive tried the zooming and focus overrides with video and it worked fine, will do more testing later, but so far ive not come into any issues, crashing etc.
Thanks so much for your hard work on this, its hugely appreciated.
-
Hi guys,
I'm completely new to CHDK but am looking to help out in any way I can. I have a G11 and CameraVersion reports I have firmware "1.00 rev a.00".
Is there anything I can do? I'm confused as to if the version numbers in this thread are CHDK version numbers or G11 firmware version numbers (i.e. my "A" revision isn't helpful).
(BTW -- I'm comfortable dealing with alpha/beta code as long as I can revert to OEM firmware if CHDK is having issues.)
-
I never used "CameraVersion" to get the firmware version until now, i only know the "Firmware info" method in the wiki (http://chdk.wikia.com/wiki/G11 (http://chdk.wikia.com/wiki/G11)). But if "CameraVersion" works correct, it looks like you have a very old firmware version: 1.00A
You can simply try if one of the allready available g11 chdk ports is working for your camera/fw-version. If none of the ports work, and your camera freezes, shuts down or does not start at all, dont worry, simply remove the battery and the set sd-card switch back to R/W and your g11 is back to normal, because chdk does not change/overwrites the original canon firmware. It is only copied from sd-card to RAM and runs directly out of the RAM.
If no of the available ports works, then i think another port for 1.00A is needed. For that case, it is necessary to get a dump of your 1.00A firmware. For this, use the modified udumper (you can find the link in the chdk g11 wiki) and upload the fw dump please.
-
I never used "CameraVersion" to get the firmware version until now, i only know the "Firmware info" method in the wiki (http://chdk.wikia.com/wiki/G11 (http://chdk.wikia.com/wiki/G11)). But if "CameraVersion" works correct, it looks like you have a very old firmware version: 1.00A
You can simply try if one of the allready available g11 chdk ports is working for your camera/fw-version. If none of the ports work, and your camera freezes, shuts down or does not start at all, dont worry, simply remove the battery and the set sd-card switch back to R/W and your g11 is back to normal, because chdk does not change/overwrites the original canon firmware. It is only copied from sd-card to RAM and runs directly out of the RAM.
If no of the available ports works, then i think another port for 1.00A is needed. For that case, it is necessary to get a dump of your 1.00A firmware. For this, use the modified udumper (you can find the link in the chdk g11 wiki) and upload the fw dump please.
Yeah, my G11 is from like immediately after it came out. It arrived in late November.
I'll confirm my version number using the ver.req method and then give F, J, and K a go.
Thank you! :)
-
Okay, if you really have 1.00A on your camera, i think it is enough to test the "closest" firmware version port 1.00F. The chance that the newer ones are working on 1.00A is very, very small (allmost 0% ;) ).
Please make also a dump of your 1.00A fw version, it is needed anyway for a dedicated 1.00A port, if 1.00F is not working.
For this, e.g use cardtricks under windows: Use the "NewDryOs" Button to create a udumper sd-card, an then replace the diskboot.bin on the sd-card with this one: http://chdk.setepontos.com/index.php/topic,4647.msg46175.html#msg46175. (http://chdk.setepontos.com/index.php/topic,4647.msg46175.html#msg46175.) Then run the sd-card on the G11. Finally use the "strings" button to check if you have got a non-zero dump file on the sd-card and then use the "Clean" button to create a cleaned up version of the dump file.
-
I am running the 1.00L diskboot.bin and I am getting a crash (camera turns off) when running the Time-Lapse Lua script from the SDM common files. I tried following the instructions for a "save ROMLOG.txt file" but the options was no in the debug parameters menu.
Anyways, the script runs until the shutter is about to open and the camera shuts off.
If I can be of any more help, please let me know.
Thanks for all the great work!!!!
-
Welcome !
There are no Lua scripts in the SDM Common_files.zip.
I guess you are using CHDK as there is no SDM 1.00L version yet.
The SDM time_lapse.bas will not work with CHDK.
-
Opps. Yea time-lapse.bas. Sorry, I saw all the other Lua scripts and "[admin: avoid swearing please]-u-me-d" that it was Lua as well. While I am not directly interested in 3D with a Canon, I AM interested in time-lapse.
Can a more basic functioning script be written to support time-lapse photography?
Thanks
-
The SDM time_lapse.bas is a very powerful script, but you will have to wait until the 1.00L version is available before you can try that.
A lot of CHDK users use this script :-
http://chdk.wikia.com/wiki/UBASIC/Scripts:_Ultra_Intervalometer (http://chdk.wikia.com/wiki/UBASIC/Scripts:_Ultra_Intervalometer)
-
I AM interested in time-lapse.
You may also be interested in these Lua scripts for CHDK:
* http://chdk.wikia.com/wiki/LUA#Minimalistic_Intervalometer (http://chdk.wikia.com/wiki/LUA#Minimalistic_Intervalometer) (Minimalistic Intervalometer)
* http://chdk.wikia.com/wiki/LUA#yet_another_accurate_intervalometer (http://chdk.wikia.com/wiki/LUA#yet_another_accurate_intervalometer) (yet another accurate intervalometer)
* http://chdk.wikia.com/wiki/User:Fe50#double_intervalometer (http://chdk.wikia.com/wiki/User:Fe50#double_intervalometer) (my double intervalometer)
-
So, what say the testers? Is the 1.00L port working well enough to integrate/add the port to the SVN so it can be part of the autobuild?
Or are there any serious problems left? ::)
-
I have some kind of feature request for the G11...
In "Quick Shot" mode, the CHDK display enhancements overlay the Canon "quick settings" menu... it would be a good idea, if the chdks display enhancements would be fully deactivated, when the camera is set to "Quick Shot". As it is now, "Quick Shot" is rather useless, when chdk is booted.
Any comments?
-
Sorry I have not responded earlier, but I have been playing with my G11 and my time lapse script!!!
I have not tried all the functions for the 1.00L, but the ones I have tried seem to work. I don't know about other versions, but the chdk menu seems to disappear a LOT on my camera. I know it was an issue but it makes it REAL hard to use as I have to keep rotating the dial back and forth to keep the menu up sometimes.
Also it seems that I have to press the "Alt" button a few times to bring up the chdk menu--again it could be related to the menu not displaying (or displaying and disappearing).
Other than that, of the fuctions I have tried, they have worked--temp, icon locations, scripts, reversi ect. I have not used any overrides other than the superfine jpg options.
So, my recomendation is YES it is ready for integration to the SVN. I will keep testing functions as I learn about them and report any thing I find.
Again, THANKS for all the hard work ERR99. I know how much (or at least have a good idea) how much effort and work you and Microfunguy have put into this project and a lot of it goes un or underappriciated.
-
ERR99,
Question for you and I am not sure where I should post it on this forum, so I am just going to post it here.
On the G11 it only offers Fine and Normal compression for JPG files. Chdk offers a SuperFine option.
Is this just a setting in a PropCase or is the Chdk code actually using a different JPG encoding function that what is in the G11 firmware?
If it IS just a PropCase or variable, would it be possible to edit the dumped firmware (hack it) to make the Normal setting set the SuperFine option instead of "Normal"?
The reason I am asking, is I don't always need the full chdk functionality, but I WOULD like to always have SuperFine JPG files. Also, I NEVER use NORMAL compression, so would it be possible to hack the original firmware and then have that loaded either into the flash memory or at least boot up the hacked firmware on startup.
Thanks and if this is not the correct place to ask this question, please let me know. I am new to this forum.
-
...but the chdk menu seems to disappear a LOT on my camera. I know it was an issue but it makes it REAL hard to use as I have to keep rotating the dial back and forth to keep the menu up sometimes.
Switch to playback mode or open the Canon menu when using the CHDK menu; the CHDK menu should be much more "stable" then...
-
So, what say the testers? Is the 1.00L port working well enough to integrate/add the port to the SVN so it can be part of the autobuild?
Or are there any serious problems left? ::)
Ive been using it since you uploaded the bootdisk.bin, so far no problems at all, everything ive tried seems to be working fine, havent had any crashes. boots up everytime, shuts down without any problems, so far its been spot on :D
-
Fine, thanks for the feedback. I posted now the sources for 1.00L in the "[REQ]Adding new cameras, applying patches into trunk (with source code prepared)" thread, so hopefully it is soon part of the autobuild.
-
I posted now the sources for 1.00L in the "[REQ]Adding new cameras, applying patches into trunk (with source code prepared)" thread, so hopefully it is soon part of the autobuild.
...work in process... ;)
Edit: Done, changeset #882 (http://tools.assembla.com/chdk/changeset/882)
Binaries should be available from the Autobuild Server in ~20 minutes.
-
Hi everyone, I'm a new comer. I'm using G11 with 1.00L version (used vers.req to check it). I had read a lot information on this site before asking a new question. Now, here is my problem..
I have a 8GB SD Card and I want to use CHDK for my G11. But I don't know how to split two partitions FAT16(or FAT12) and FAT32 for it.
I tried guide on this site (Windows method - Case #4):
http://chdk.wikia.com/wiki/Bootable_SD_card (http://chdk.wikia.com/wiki/Bootable_SD_card)
But it failed because G11 doesn't support the manual loading method through the firmware update.
I searched on Google. There is a guide use WM5Storage to make Windows recognize SD Card as Disk Storage Device and can create new partition. But this method need a Windows Mobile 5 device. I don't have anything like that.
So, is there any method create partition for 8GB SD card on Windows for using CHDK on G11?
Please help me :D
Best Regards.
-
Hello & welcome, trickyboy !
So, is there any method create partition for 8GB SD card on Windows for using CHDK on G11?
Pls. read here:
--> Multi partitioning support & MS Windows (http://chdk.setepontos.com/index.php/topic,2468.msg30911.html#msg30911)
--> Swap partitions with SDM installer (http://chdk.setepontos.com/index.php/topic,3910.msg36763.html#msg36763)
-
This is probably going to sound stupid but has anyone tried loading the g11 beta on a g10? Because as far as I can see they are identical cameras except for the screen and megapixel resolution. Am I missing something as to why the g10 has been so challenging as opposed to the g11?
Sorry if this post is ignorant but I would very much like to know as I own the g10 ;)
Thanks,
Mindstrm
-
This is probably going to sound stupid but has anyone tried loading the g11 beta on a g10? Because as far as I can see they are identical cameras except for the screen and megapixel resolution.
Sorry, it wont work that way. CHDK stops working most of the time if only the FW is updated on the same camera! CHDK needs to known EXACTLY the adresses for functions and variables of the original firmware. If this adresses are changed or shifted (even only by one byte, e.g. because a text string was changed somewhere ), camera crashes. So getting the G11 port working (simply by booting the G11 port) on G10 is impossible. G10 will crash.
Am I missing something as to why the g10 has been so challenging as opposed to the g11?
I dont think that the G10 is more challenging then the G11 (or any other allready ported camera). You simply need someone who has a G10 AND the time, skills and motivation to do the port. If you dont find someone with this profile... you got no chdk port.
-
Hello & welcome, trickyboy !
Pls. read here:
--> Multi partitioning support & MS Windows (http://chdk.setepontos.com/index.php/topic,2468.msg30911.html#msg30911)
--> Swap partitions with SDM installer (http://chdk.setepontos.com/index.php/topic,3910.msg36763.html#msg36763)
Hi fe50,
Thanks for your supporting :D. But I found that software doesn't work for my card.
Luckily, I tried Paragon Partition Manager and it worked. I have a FAT 16 partition now (just use 1.9GB and other GB is useless :D ). After that, I used CardTrick to make it bootable and copy full CHDK into it. Hope this method is useful for anybody have same problem with me.
CHDK run on my G11 but sometimes it makes memory card error after reset camera.
I will continue try it and report if there is any problem.
Best Regards
-
@trickyboy
If you're german speaking, I would suggest
http://www.wirklemms.de/chdk/forum/viewtopic.php?t=1784 (http://www.wirklemms.de/chdk/forum/viewtopic.php?t=1784)
in the german chdk forum. I found a nice (german) website with a (working) link to the hitachi driver and some info, how to get things work -- in the german forum, I posted my findings.
The hitachi driver works very well. It sits in WinXP between the system usb/card driver and the card reader and filters the bit, which gives WinXP the info, if the connected device is a harddisk or a removable media. With this driver, WinXP uses the sd-card in a card-reader as a harddisk and both partitions can be accessed directly without partition-switching.
On my Mac, I don't need a special driver. There the double-partition-card can be accesed by default.
I've tried to find the lexmark bootit tool, but couldn't find it. Otherwiese, the lexar tool can only used once to set the bit to "harddisk"... and then, the card is a harddisk for lifetime. So, the hitachi driver is preferable.
If you only speak english, I would suggest to google for "xpfildrvr1224_320.zip" (the name of the filter-driver-package) or "hitachi +microdrive +driver", and maybe, you will find a tutorial for installation in english -- probably in an eee-pc forum.
-
@ERR99
Do you know if ubasic_set_led is working correctly with firmware 100f ?
In particular, the autofocus led ?
-
ERR99,
I been having something weird happening on my G11 1.00L. When I go to turn it on, or sometimes when I turn it on with the Play button, the camera starts up and then shuts off again. It seems to be a new phenomenon. I didn't notice it a little while ago, but now it seems to happen about every other time I try to turn on the camera. Matter of fact, tonight at a birthday party, the camera shut off 3 times in a row before I got it to boot up.
I am currently only using the battery display, the Super Fine JPG override setting and have 2 scripts (time lapse and motion detection) on the camera. I am not using the zebra, games or CHDK raw settings.
Is anybody else having this happen or am I just getting unlucky. And yes, my battery is at over 90% charge, so it is not that.
Any idea what it could be?
Thanks,
Bruce
-
Strange thing... A romlog would be helpfull, but for that you need a special chdk build.
For now, you can try to start with a fresh config file. So save you CHDK.CFG from the SD-Card on your computer and then delete the CHDK.CFG file on the SD-Card. Then check if the problem is gone. If it so, change the configuration of CHDK as you wish, but please test after every single change if the camera is still starting up correctly.
-
@ERR99
Do you know if ubasic_set_led is working correctly with firmware 100f ?
In particular, the autofocus led ?
I tested it once, (long time ago...) on the 1.00J. At it was possible to set all LEDs via set_led. But i was lazy and put the LEDs 'unsorted' into the set_led array, so maybe the index number for AF-LED is different then expected.
-
@1bigpig
In case ERR99's instructions don't help:
Also check the card's filesystem, or better backup your images and then format the card.
In the past there were some (rare) reports of issues like yours when the fs was corrupted or
very fragmented, sometimes also on cards with a big amount of files, especially on slow SD cards...
-
@fe50
Thanks. I did check that and the filesystem seems to be ok. It is a decent card (class 4, 4gb SanDisk Extreme) and it only has about 525 files (~1gb worth of images) and I am guessing a good quarter of them are CHDK related files.
So, I will see if that helps and report back.
@ERR99
Got something funny going on. The file CCHDK.CFG now has a date of 01/01/2000 12:00 AM.
The backup card has a date of 03/18/2010.... So somehow when this file seems to be written, the date is now getting wiped out.
Anyways, I will delete this and see if that works.
Also, noticed something funny (and not sure what they are for). In the DCIM folder, the camera is creating a folder called CANONMSC (I am not shooting RAW files) and in this folder are a bunch of 1K files with consecutive numbers: M0100.CTG --> M0118.CTG) The funny thing, these files seem to have the creation time which seems to be around the time that I remember trying to turn my camera on and it shutting off. Are these file relevent and is this just a coincidence?
Thanks,
Bruce
-
i was lazy and put the LEDs 'unsorted' into the set_led array, so maybe the index number for AF-LED is different then expected.
The led array is the same for all firmware versions.
Are you saying the numbers in the table are correct but maybe not in the right order ?
The only other possibility is that the address of _LedDrive is incorrect but you would expect that to crash the camera.
EDIT:
The tester has just told me the orange led lit ... on the BACK of the camera !
I had previously removed the 'set_led' command from SDM, I will now reintroduce it as it makes debugging this type of problem easier.
-
Also, noticed something funny (and not sure what they are for). In the DCIM folder, the camera is creating a folder called CANONMSC (I am not shooting RAW files) and in this folder are a bunch of 1K files with consecutive numbers: M0100.CTG --> M0118.CTG)
The .ctg files are Canon catalog files with additional image informations, used by some Canon Software, e.g. ZoomBrowser.
The camera creates the files automatically; it looks like that the catalog files are scanned by the Canon firmware when the camera powers on - with lots of files or corrupted images on the card this process could take some seconds.
-
@ERR99
Only one of the led's is reported as lighting.
Try this script :-
@title led test
@param a led number (4-10, 6 unused)
@default a 9
print "LED number ",a
sleep 2000
set_led a 1
sleep 3000
set_led a 0
end
-
Hi ERR99.
It looks like you are using wrong property case for WhiteBalance.
From where did that value came from?
#define PROPCASE_WB_ADJ 270
In the firmware G11 100F I found following code:
ROM:FF8B79BC MOV R2, #0x1C
ROM:FF8B79C0 ADD R4, R2, #0xF3
ROM:FF8B79C4 MOV R0, R4
ROM:FF8B79C8 MOV R1, SP
ROM:FF8B79CC BL PT_GetPropertyCaseString
R0=R4=R2+0xF3=0x1C+0xF3=0x10F=271 (NOT 270!)
-
Hi ERR99.
It looks like you are using wrong property case for WhiteBalance.
From where did that value came from?
I used the propbrowser to check which propnumber is changing, if i change the whitebalance mode in the canon oem menu ( from AWB, to daylight, cloudy, etc. It changes from 0...7). And prop 270 was the one who was changing. Is this wrong, and PROPCASE_WB_ADJ means something else?
-
if i change the whitebalance mode in the canon oem menu ( from AWB, to daylight, cloudy, etc. It changes from 0...7). And prop 270 was the one who was changing. Is this wrong, and PROPCASE_WB_ADJ means something else?
Yes.
Prop 270 is white balance mode (Auto, Day Light, Cloudy etc.) - not used in CHDK.
Prop 271 (maybe) is white balance fine tuning (color channel multipliers, 28 bytes for propset 1-2) - CHDK requires this one (PROPCASE_WB_ADJ). Used in DNG for "white balance embedding".
-
Aaaah, okay. Thanks for the clarification. Currently, DNG support for G11 is disabled anyway, so this error does not hurt so much. ;)
Anyway, i will change the propcase value for PROPCASE_WB_ADJ from 270 to 271.
-
@ERR99
Only one of the led's is reported as lighting.
Try this script :-
@title led test
@param a led number (4-10, 6 unused)
@default a 9
print "LED number ",a
sleep 2000
set_led a 1
sleep 3000
set_led a 0
end
I tested the script with this numbers, and the following LEDs goes on & off:
0 - Viewfinder upper LED = Green
1 - Viewfinder upper LED = Red
2 - Viewfinder Lower LED = Yellow
3 - ON/OFF (Power switch) LED = Green
4 - AF-LED = White
5 - ISO dial LED = Yellow
6 - EV correction = Yellow
I cant find any other LEDs on my G11, so i think it is possible to controll every LED via CHDK. ;)
-
Well, they are not the 'official' numbers (4 to 10, exclude 6) given here :-
http://chdk.wikia.com/wiki/UBASIC/TutorialScratchpad#LED_Lamp_Control (http://chdk.wikia.com/wiki/UBASIC/TutorialScratchpad#LED_Lamp_Control)
Anyway, I will check the SDM build.
-
Tried this out on my G11 today and seemed to work fine. However i was wondering about the possibility of adding some features. For instance the video mode on the G11 always seemed crippled IMO, My sister had some semi cheap powershot and it had 720p video available and my G11 would only do 640x480. Is it beyond the scope of this project to possibly add higher video resolutions? or to enable variable video framerate. Obviously there's technical limitations for increasing the framerate, but i was mostly interested in the possibility of a 24 FPS mode.
-
I never used "CameraVersion" to get the firmware version until now, i only know the "Firmware info" method in the wiki (http://chdk.wikia.com/wiki/G11 (http://chdk.wikia.com/wiki/G11)).
Just an update: I did the ver.req method and it is more accurate. I have the 1.00J firmware. :)
I'm off to try the firmware now.
EDIT: Woot, I got it working! :D However besides the clock, battery meter, and having to press the shutter button in order to get it to come out of playback mode (pressing the power button wrongly makes it start up in playback mode), what's the difference? I don't seem to have any additional features. Or is that it for the moment due to beta?
-
EDIT: Woot, I got it working! :D However besides the clock, battery meter, and having to press the shutter button in order to get it to come out of playback mode (pressing the power button wrongly makes it start up in playback mode), what's the difference? I don't seem to have any additional features. Or is that it for the moment due to beta?
No, nothing beta related. Please refer to the CHDK manual to see how to power on the camera direct into shooting mode (hold the ON/OFF button longer), and how to enter the CHDK menu (press the print button).
-
Can anyone with G11 1.00F firmware check out the function at 0xFF95F0E8 ??
It should be GetCurrentFocalLength() function and should return current focal length.
Its prototype is int GetCurrentFocalLength(void).
-
No, nothing beta related. Please refer to the CHDK manual to see how to power on the camera direct into shooting mode (hold the ON/OFF button longer), and how to enter the CHDK menu (press the print button).
Ah excellent, thank you. Apologies for being a moron who didn't RTFM. :)
-
HELP... :-[
with my G11 I take a lot of shots with only one hand while I'm rockclimbing... 8)
so that often my thumb accidentally touch the rear control wheel >:(
Could anyone release a feature (script?) to DISABLE THE REAR CONTROL WHEEL when needed ? ::)
Thanks... :)
-
Disabling the WHEEL in non ALT mode should be possible (and i think this would be also a usefull feature for the S90 port, because you change here the wheel all the time accidentally, and that happens on the S90 also without doing any rock climbing! ;) )
But its not possible to do this with a simple script or so. The port/chdk has to be adapted to provide this function (so this is a CHDK feature request to be specific).
The question is, how to do the enabling/disabling of the wheel. Via a CHDK menu entry, or what do you have in mind?
-
Disabling the WHEEL in non ALT mode should be possible (and i think this would be also a usefull feature for the S90 port, because you change here the wheel all the time accidentally, and that happens on the S90 also without doing any rock climbing! ;) )
But its not possible to do this with a simple script or so. The port/chdk has to be adapted to provide this function (so this is a CHDK feature request to be specific).
The question is, how to do the enabling/disabling of the wheel. Via a CHDK menu entry, or what do you have in mind?
Uhmm... :blink:
I thought an Override option in Main Menu>Extra Photo Operations, is it possible? :-[
-
Maybe i can make a testbuild with such a feature. Which firmware version do you have?
-
Maybe i can make a testbuild with such a feature. Which firmware version do you have?
J version... :)
-
Okay, then please try the attached 1.00J build.
Under "Miscellaneous stuff" you will find (at the bottom of the menu) the new menu point "Lock Jogdial".
If activated, the rear jogdial should be blocked for NON-ALT mode. That means the jogdial is still usable in the
CHDK Menus/ALT mode, but locked for the "normal operation" canon menus.
-
Okay, then please try the attached 1.00J build.
Under "Miscellaneous stuff" you will find (at the bottom of the menu) the new menu point "Lock Jogdial".
If activated, the rear jogdial should be blocked for NON-ALT mode. That means the jogdial is still usable in the
CHDK Menus/ALT mode, but locked for the "normal operation" canon menus.
:o Wonderful !!
What can I say... THANK YOU is not enough ! :D
but ... :-[
if I want to lock the entire directional (up/down/right/left) button ... is it possible? ::)
-
No problem, any single key can be locked if necessary.
Try the attached build, now also UP/DOWN/LEFT/RIGHT should be locked in non-alt mode.
-
No problem, any single key can be locked if necessary.
Try the attached build, now also UP/DOWN/LEFT/RIGHT should be locked in non-alt mode.
my precious treasure ERR99... :)
you left me without words... and ( for now ;) ) any other requests
thanks a lot!! :D
-
Hi ERR, first of all thanks for your work (I won't say hard because you're prolly a pretty smart individual).
I have a quick question for you and all that are active on this forum and please feel free to forward me to another section of the board if the members frown upon the placement of my question...here goes:
- I have the G11 (sweet camera!) and after much time wasted trying to figure out a way to format my Sandisk SDHC (8gB) card using the built-in card readers on my Windows and Mac laptops I decided I better just buy the dang card reader!
- Anyhow, I successfully followed this tutorial (http://chdk.wikia.com/wiki/FAQ/Mac) (formatted disk with a 10mB partition and the second partition as 7.4gB calling them CHDK BOOT and CHDK SOURCE, respectively.
- After that, I used Terminal in the MAC to make the first partitioned sector of the disk bootable.
- Next I copied the BootSector.bin and PS.FI2 to the CHDK BOOT portion of the disk and the CHDK (for 1.00L) build and vers.req files to the CHDK SOURCE portion of the disk.
- Finally, I locked the card, inserted the card into my G11, turned on the G11, went to Play/Review mode, pressed my alt+menu key combination and nothing...
Note, I got CHDK working earlier by copying both CHDK (1.00L) builds to both partitioned sectors of my card, but at 10mB it soon ran out of room to write to and did not automatically begin writing to the larger partition of my card...so it appears I must need CHDK on BOTH partitions of the card and I still need to figure out how to get CHDK to jump to the other card upon booting...
Any ideas why I can't get CHDK to boot per the directions on the MacFAQ? I'd appreciate anyone's experience with a card >4gB!! :-[
-
- Next I copied the BootSector.bin and PS.FI2 to the CHDK BOOT portion of the disk and the CHDK (for 1.00L) build and vers.req files to the CHDK SOURCE portion of the disk.
1) The PS.FI2 file is not needed/working on the G11. So no need to copy it (but it does not hurt if you copy it on the sd-card, it takes only useless space on the sd-card).
2) After partitioning and making the sd-card bootable, you have to copy the diskboot.bin file to the first(boot) partition of the sd-card.
-
Thanks, I'll double-check that i've done that (I believe I have - not sure if I mentioned it above and I'm at work right now so I'll have to check when i get home). what does the PS.FI2 file do??
- Next I copied the BootSector.bin and PS.FI2 to the CHDK BOOT portion of the disk and the CHDK (for 1.00L) build and vers.req files to the CHDK SOURCE portion of the disk.
1) The PS.FI2 file is not needed/working on the G11. So no need to copy it (but it does not hurt if you copy it on the sd-card, it takes only useless space on the sd-card).
2) After partitioning and making the sd-card bootable, you have to copy the diskboot.bin file to the first(boot) partition of the sd-card.
-
Sorry, I meant to say DISKBOOT.bin; it was just a typo on my end. CHDK works, but it still won't swap to my 7.8gB portion to perform the write image routine...
If anyone can refer me to a link for other persons setting up partitions on an SDHC card (>4gB) then I would be stoked! I assume this build supports the SDHC cards...when the disk is full after on or three shots how does CHDK know to switch over to the other partition or how come CHDK doesn't switch over when it captures the very first shot??? I'm confused...
-
CHDK does not "switch" over from one to another partition during shooting.
During boot, CHDK checks if there is a second FAT32 partition avalaible. If so,
ONLY this second partition is used to store the pictures.
If you still got the pictures on the first (small) partition, you did something wrong by creating the SD-CARD.
Maybe the second parition is not created, or not correctly formated, so that chdk is not able to detect a second
FAT32 partition and has to use the first small partition.
If you have access to a windows pc, simply use the SDM-Installer. It will creates a corrected formated dual-partition SD-Card by a push of a button.
-
Newbie here, but have an oddball question. I'm runing v. J on a H firmware g11. How do you keep the green focus box from disappearing when shooting? When I exit chdk, it works normally. Thx
Jerrich
-
Newbie here, but have an oddball question. I'm runing v. J on a H firmware g11. How do you keep the green focus box from disappearing when shooting? When I exit chdk, it works normally.
Hi there, Jerrich! First of all, why are you using the "J"-version of CHDK with the "H"-version of the Cam?
Makes no sense to me. Please download and use the correct version, maybe your problem will vanish without a trace...
-kingcang
-
Thanks for the reply. When searching for the correct version, there wasn't an "H" and a footnote to use "J".
I would like the green focus box to not disappear when shutter is pressed. I might have a setting wrong somewhere, since there are 10,000 !! :)
JR
-
Is it possible to make the G-11 remote capture using CHDK and the factory usb cord? I use 'capture one' which you can fire off the camera via the laptop and would love to have the G-11 be able to utilise this.
-
Newbie here, but have an oddball question. I'm runing v. J on a H firmware g11. How do you keep the green focus box from disappearing when shooting? When I exit chdk, it works normally. Thx
Jerrich
I think i dont understand the problem. The focus box only goes green if you half press the shooting button in shooting mode (and the camera is able to find focus in the area). What exactly do you mean with exit chdk?. Leaving the ALT-Mode via ALT-Key, or booting the camera without CHDK? If you are in ALT-Mode, i dont expect that you can focus via shooting button, because this button is used to start scripts in ALT-Mode.
-
Is it possible to make the G-11 remote capture using CHDK and the factory usb cord? I use 'capture one' which you can fire off the camera via the laptop and would love to have the G-11 be able to utilise this.
Canon does not support the G11 via the Canon-SDK anymore, so it is not possible to do this via the "usual" software tools, available for older canon cameras. With CHDK you can trigger the camera to shoot, if you use the USB-Trigger way. To control this
via software on the PC is not so easy. You need the posibillity to switch the powersupply on/off on your usb-port. I dont know if this is allready possible with a sw-tool.
A possible solution could be to implement the PTP extension. But this is not done now for the G11. Also this way works only on 32-Bit Windows machines (the PTP Client software driver / USB-Lib need on the PC-Site is only available for 32-Bit windows). I dont know if there is client software available for linux or mac. As i have now only 64-Bit machines running, i currently dont have any intension to implement the PTP-Extension for the G11/S90. (Maybe i pick up this task if someone releases a stable running usblib for 64-bit windows). I tried in the past to get this stuff running for the G11, but it does not run very stable so i canceled any further implementation of the ptp-stuff.
-
I think i dont understand the problem. The focus box only goes green if you half press the shooting button in shooting mode (and the camera is able to find focus in the area). What exactly do you mean with exit chdk?. Leaving the ALT-Mode via ALT-Key, or booting the camera without CHDK? If you are in ALT-Mode, i dont expect that you can focus via shooting button, because this button is used to start scripts in ALT-Mode.
In my case the green box appears for a fraction of a second with half and full press, then disappears. When I turn off chdk with the card lock switch and shoot normally, the green box stays present until the picture is completely taken. It's not a big deal, but just an irratation since I like the continuous confirmation that I'm in focus. Maybe it's a setting? Thx.
JR
-
Canon does not support the G11 via the Canon-SDK anymore, so it is not possible to do this via the "usual" software tools, available for older canon cameras. With CHDK you can trigger the camera to shoot, if you use the USB-Trigger way. To control this
via software on the PC is not so easy. You need the posibillity to switch the powersupply on/off on your usb-port. I dont know if this is allready possible with a sw-tool.
A possible solution could be to implement the PTP extension. But this is not done now for the G11. Also this way works only on 32-Bit Windows machines (the PTP Client software driver / USB-Lib need on the PC-Site is only available for 32-Bit windows). I dont know if there is client software available for linux or mac. As i have now only 64-Bit machines running, i currently dont have any intension to implement the PTP-Extension for the G11/S90. (Maybe i pick up this task if someone releases a stable running usblib for 64-bit windows). I tried in the past to get this stuff running for the G11, but it does not run very stable so i canceled any further implementation of the ptp-stuff.
Thankyou Err99 for looking into this so promptly. I didn't realise it would be such a pain staking effort just to get the images off the camera...I suppose I'll stick with still plugging in/out the card reader until someone can come up with a stable fix:(
-
CHDK does not "switch" over from one to another partition during shooting.
During boot, CHDK checks if there is a second FAT32 partition avalaible. If so,
ONLY this second partition is used to store the pictures.
If you still got the pictures on the first (small) partition, you did something wrong by creating the SD-CARD.
Maybe the second parition is not created, or not correctly formated, so that chdk is not able to detect a second
FAT32 partition and has to use the first small partition.
If you have access to a windows pc, simply use the SDM-Installer. It will creates a corrected formated dual-partition SD-Card by a push of a button.
Sorry for the slow reply, it's been a busy few weeks at my new job AND I still am searching for my first home! Anyhow, I can't use the SDM-installer as my G11 is the 1.00L firmware...SDM is one of the first things I thought would be interesting to get!
I'll keep playing around on the MAC until I get it I guess! Thanks for the responses ERR99, you truly know your stuff!
Just to make sure, CHDK has to be installed on the smaller partition (less than <4 gB to retain FAT32 indexing structure) and the second partition can be any size (in this case my first partition for CHDK is 10mB and my second partition for RAW storage is 7.69gB), correct? Thanks again!
-
Well, good luck with your first job and home.
That should take-up a lot of your time.
The SDM installer can be used to prepare your card regardless of the firmware version.
(If you want to try SDM for 100l I can upload a version for you.)
David
-
Well, good luck with your first job and home.
That should take-up a lot of your time.
The SDM installer can be used to prepare your card regardless of the firmware version.
(If you want to try SDM for 100l I can upload a version for you.)
David
Thanks David, that would be great! Hopefully I can get it working before Thursday (holiday/vacation wkend!) Yes, the house-hunting is taking up a lot of my time as I am VERY particular about everything. Hopefully the rates keep dropping (currently 4.75%!)
If you send me a PM with a YSI (you send it) or whatever is most popular that would be great. Are you the developer of SDM? I'm asking since I am confused as I did not see a version available for 1.00L... :)
-Josh
-
Another odd ball question: What setting do I have wrong to make the lcd display an outline of the picture subjects, and a FROZEN msg appear? This happens when the shutter is pressed in Alt mode. I reset all the options and it corrected, but I had to reconfigure all my settings.
JR
PS. Never have yet figured out how to keep the green focus box present for the whole snapshot. Thx.
-
Sounds like you turned on "edge overlay" somewhere.
-
Another odd ball question: What setting do I have wrong to make the lcd display an outline of the picture subjects, and a FROZEN msg appear?
--> Edge Overlay (http://chdk.wikia.com/wiki/CHDK_User_Manual#Edge_Overlay) feature
-
Yes, that was it. I wrote Frozen in my index for future reference. Thx. Is there a script that will turn off all the leds on the g11? That would be handy when stealth is needed. Is there a read on scripts somewhere? I don't even know what egg timer is. :(
JR
-
Is there a script that will turn off all the leds on the g11?
No; LED's can be switched on & off with CHDK scripting commands, but the camera can enable the LED's at anytime again.
I don't even know what egg timer is. :(
It's a simple script to demonstrate CHDK scripting; use your Canon as a simple egg-timer...
-
For HDR, is there a way to over-ride the 3-exposure bracketing and use a 5 exposure range instead?
-
For HDR, is there a way to over-ride the 3-exposure bracketing and use a 5 exposure range instead?
Yes, of course - use the custom timer mode, adjustable from 2 to 10 shots. ;)
You can also use a script for an unlimited number of shots, for fastest speed you may try my fast shooter (http://chdk.wikia.com/wiki/User:Fe50#fast_shooter) script.
-
I thought these two threads should be mentioned here:
http://chdk.setepontos.com/index.php/topic,5322.0.html (http://chdk.setepontos.com/index.php/topic,5322.0.html)
http://chdk.setepontos.com/index.php/topic,5279.0.html (http://chdk.setepontos.com/index.php/topic,5279.0.html)
It would be good to know if any other CHDK users with the affected versions have anything to report.
I'm not convinced either caused by CHDK, but the possibility cannot be completely ruled out.
I think it would be good to start a wiki page as a clearing house for reported (possible) damage. If we ever do end up with a situation where are particular CHDK version is causing problems, we want to be able to recognize it at the earliest possible time, and that will require noticing a patter that is too unlikely to be coincidence.
edit:
http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK (http://chdk.wikia.com/wiki/Camera_failures_suspected_to_be_caused_by_CHDK)
-
Hello everyone,
I'm new on the forum and I have one problem and one question.
1 / I can't run the FW on my G11 (I tried with two different versions). Note: FW works fine on my G9.
2 / Is it possible to control the Capture and ZoomIn/Out functions with the USB by sending command with gPhoto (for example) ?
Thank you in advance,
-
hey, well i have used CHDK for my ixus for some years and i realy liked it so when i saw that chdk works for g11 i bought it. i have found some bugs on the L version if you are intrested.
1 In videomode when recording if i push the "macro"(flower) button the video frezes and the camera shuts down with the lens open and the video is not saved,
i have the options:
video mode, Quality
video bitrate 3x
fast video control on
video quality control on
enable optical zoom on
af key set-button
its not a big issue but it can be irritating to loose a video if you accidentliy push the button.
2 the chdk-raw saving dont work for me, all chdk-raw files are the same size and i cant open them up, i have tested all settings in the menu.
i wonder if anyone else got raw working and what is the difference between chdk-raw files and the camera-raw files, the thing i know is that it takes a lot more time to capture a chdk-raw.
Hello everyone,
I'm new on the forum and I have one problem and one question.
1 / I can't run the FW on my G11 (I tried with two different versions). Note: FW works fine on my G9.
2 / Is it possible to control the Capture and ZoomIn/Out functions with the USB by sending command with gPhoto (for example) ?
Thank you in advance,
have you checked so that the chdk-firmware version is the same as for your camera-fimware version?
http://chdk.wikia.com/wiki/Ver.req#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F
(http://chdk.wikia.com/wiki/Ver.req#Q._How_can_I_get_the_original_firmware_version_number_of_my_camera.3F)
du you have used cardtrix to make you card bootable? and the lock switch on?
and 2 check the post at the top of this (or previous) page.
-
Hello & welcome, totaltmega !
1 In videomode when recording if i push the "macro"(flower) button the video frezes and the camera shuts down with the lens open and the video is not saved
video bitrate 3x
fast video control on
Does it also crash with a lower bitrate, with the standard 1x ?
Does it also crash with "fast video control" set to off ? (this feature is known to crash on most cameras)
the chdk-raw saving dont work for me, all chdk-raw files are the same size and i cant open them up, i have tested all settings in the menu.
CHDK RAW's are unmodified sensor dumps, the file size is always the same; most software don't work with that format, you may try apps based on the latest DCRAW (http://www.cybercom.net/~dcoffin/dcraw/) version...
The CHDK RAWs are not comparable to Canon RAWs, they do not include any additional meta data, no file header...
You may try the CHDK DNG support, most imaging apps can work with the DNG image format...
-
thank you for the reply and if i disable fast video control it doesn't crash :)
my raws have been corrupted and dcaw couldn't convert them but somehow i managed to make one raw file work ant it was a little bit bigger in file size than the other and .dng files works too.
i may have been because i hadn't made a badpixel.bin so i made one using the badpixel.lua script and then it worked. i just have to figure out what setting i used when i made the raw that wasn't corrupted :)
-
i just have to figure out what setting i used when i made the raw that wasn't corrupted :)
There is no way for CHDK raw to be corrupted, since it isn't a format in the first place. The file is "valid" regardless of the contents, there's no meta data to be corrupted or interpreted wrongly. It's possible for the image to include invalid data, but there's no way any program will notice, it would just show a garbage image. The only other factor is the size of the file, which some programs use to guess what camera it comes from, but that's unlikely to change since it's a compile time constant.
It is possible to save DNG format with a CRW or CR2 extension, which programs may open correctly as DNG if they read the header.
-
okey i get it :). I have made a few more tests and i can just open the .DNG files and .CRW files that are DNG files but without the .DNG file-extension. I cant open the original .CRW files with my raw programs like UFRaw based on DCRAW. I dont think it is suported.
i suppose i will only use the .DNG raws i the future.
which raw format is the best? (most bit per chanel) the CHDK-DNG or G11 own CR2 format ~15mb vs ~10mb. well it must be some lack of bits per chanel in the CR2 files due to size.
-
which raw format is the best? (most bit per chanel) the CHDK-DNG or G11 own CR2 format ~15mb vs ~10mb. well it must be some lack of bits per chanel in the CR2 files due to size.
CHDK raw (including DNG) use the raw 12 bpp data directly from the sensor.
I would expect the canon raw to use the exact same data, but it could be losslessly compressed in some way. Although the raw buffer on most newer canon P&S are 12 bit, there's generally only ~10 bits of actual precision in the data.
-
Question:
How do i control the subject distance override using the wheel or zoom ring?
I used to do that on my Ixus 80. On the G11 i have to go to the override menu and change the value, then preview on half shutter press, then go back the override menu and adjust once more.. etc.
thanks alot.
-
Question:
How do i control the subject distance override using the wheel or zoom ring?
I used to do that on my Ixus 80. On the G11 i have to go to the override menu and change the value, then preview on half shutter press, then go back the override menu and adjust once more.. etc.
thanks alot.
Can't you just use camera MF ? Having a shortcut for this is generally a workaround for cameras without native MF.
-
I used to do that on my Ixus 80.
On the IXUS / SD series you can use SD override for emulating the MF, read about the keys here: http://chdk.wikia.com/wiki/CHDK_firmware_usage/AllBest#New.2FSpecial_Short-cut_Keys (http://chdk.wikia.com/wiki/CHDK_firmware_usage/AllBest#New.2FSpecial_Short-cut_Keys)
-
Can't you just use camera MF ? Having a shortcut for this is generally a workaround for cameras without native MF.
I guess you are right, but seeing the large SD range that CHDK offered made me think it was better than the MF.
-
I guess you are right, but seeing the large SD range that CHDK offered made me think it was better than the MF.
AFAIK it does not extend the limits, those are hardware.
-
Hello friends...
i get the canon G11 and the Kingston 8gb SDHC card
I was using my canon S5IS CHDK manually but in g11 only boot a card...
but i have problem... cardtricks not accept cards larger than 4gb... and I can not make a bootable disk.
i try use the SDM Installer and make 2 partition
1 FAT 12: 2mb
2 FAT 32: 7597mb
but in windows explore appears only 2mb ... a make bootable disk on cardtricks and camera say "card error"
can someone help me how to use this card?
i buy 2 :(
-
i try manually and appears E31 and power off camera :(
-
Hello & welcome, omarjunior !
I was using my canon S5IS CHDK manually but in g11 only boot a card...
but in windows explore appears only 2mb ... a make bootable disk on cardtricks and camera say "card error"
The G11 CHDK DOES NOT support the manual loading method through the firmware update mechanism !
Using a multi partitioned card (prepared with the SDM Installer) should work...
For the "Windows issue" read more here:
* http://chdk.setepontos.com/index.php/topic,2468.msg30911.html#msg30911 (http://chdk.setepontos.com/index.php/topic,2468.msg30911.html#msg30911)
* http://chdk.setepontos.com/index.php/topic,3910.msg36763.html#msg36763 (http://chdk.setepontos.com/index.php/topic,3910.msg36763.html#msg36763)
-
i try this method
http://mind-fields-ahead.blogspot.com/2008/04/canon-s5-is-chdk-hack-step-by-step.html (http://mind-fields-ahead.blogspot.com/2008/04/canon-s5-is-chdk-hack-step-by-step.html)
and work...
but for copy images from SD card ... is very very slow... its normal?
-
Hi to everybody, first of all excuse me if I make some error, but english is not my native language.
I have a question or maybe a request about chdk on G11
I noticed that in "low light mode" the burst speed is extremely faster than in the other modes. It would be very nice to have the possibility to shoot high speed burst, even @ 2,5 Megapixels. The problem at the stock setting is that (it's normal since it's a low-light mode) it boost the iso at a very high setting, ruining the already relatively low definition (2,5 MP) images with a lot of noise, also disabling raw mode.
Could it be possible to control iso, or force it to the lowest possible setting, maybe enable raw output and have some sort of control of the exposition instead of full auto?
In my opinion, one of the major lacks of this camera is the slow burst speed, having the possibility to shot at a decent burst rate, even if at a lower resolution, could be usefull in some circumstances
Thank you
Angelo
-
Hello & welcome, Angelo !
I noticed that in "low light mode" the burst speed is extremely faster than in the other modes.
...Could it be possible to control iso, or force it to the lowest possible setting, maybe enable raw output and have some sort of control of the exposition instead of full auto?
In this mode ("ISO3200" on some cameras) the camera doesn't use the full sensor capabilities, e.g. on the SX10 the resulting image is interpolated from ~ 1280 pixels to 1600x1200 pixels, newer cameras may do other tricks like pixel binning.
Also a smaller RAW buffer is used in this mode, the resulting (full-size) CHDK RAWs are not usable.
You should be able to use most of the CHDK overrides, e.g. you can set ISO80: the result normally is not very good, but better as with the Canon settings.
The CHDK Tv overrides (exposure time) should also work.
-
I'm interested to know if there is a way to make the screen show B/W while shooting RAW. I've tried to set it on the camera, first with RAW only shooting, then with RAW+JPEG. Neither way is permissible. I know that it's artificially imposed, because I've got other Canon cameras (even as old as 20D) that will show the display in B/W while shooting RAW. Any help is appreciated.
-
Hi, I have updated the camera.h to fix the generated dng exif for compatibility with dng supported products.
The patch file can be found here : https://sites.google.com/site/intelliriffer/downloads/g11_dng_patch.patch?attredirects=0&d=1
The Build for 100L version can be downloaded here : https://sites.google.com/site/intelliriffer/downloads/g11-100l-0.9.9-940_custom.zip?attredirects=0&d=1
Respective developers/gurus are requested to look into it and merge patch with repo.
Thank you,
Amit Talwar
-
I don't understand why you try to redefine CAM_DEFAULT_CROP_* ? No other cameras need this, and the way you have it won't actually redefine it anyway, because dng.h is included after camera.h in dng.c
If I understand the problem correctly, you just have to ensure that CAM_ACTIVE_AREA_X2-CAM_ACTIVE_AREA_X1-CAM_JPEG_WIDTH (and height equivalent) isn't negative, which your changes already do.
I've checked in with your values for active area, since they certainly won't be worse than what was there before.
-
CAM_DEFAULT_CROP_* was a test trying to come-up with some exact values that adobe dng converter generates however as you have noticed this did not affect the outcome and are not required.
The active area and the other values are not random but taken from valid dng files (adobe dng converter) created from actual g11 cr2 raw files.
prior to this chdk code change : I was converting the dng via exiftool with the command line options : -Exif:DefaultCropOrigin="16 12" -Exif:DefaultCropSize="3648 2736" -Exif:ActiveArea="16 8 2776 3692"
and these are the values I tried to implement natively.
Update: Thanks reyalp,
just compiled and tested the 941 build. Now the out of camera dng are fine.
-
i try this method
http://mind-fields-ahead.blogspot.com/2008/04/canon-s5-is-chdk-hack-step-by-step.html (http://mind-fields-ahead.blogspot.com/2008/04/canon-s5-is-chdk-hack-step-by-step.html)
and work...
but for copy images from SD card ... is very very slow... its normal?
-
hello, a friend of mine owns this camera and he's playing around with scripts, however seems like the exposure compensation cannot be set. I see from the wiki
209 RW Exposure Compensation Dial (+/- 32, 64, 96, 128, 160, 192 = +/- 1/3, 2/3, 1, 1 1/3, 1 2/3, 2) Note: you can write to it, but actual state doesn't change. Any clue on why? can you confirm this? Isn't there some workaround for this?
edit: also, setting set_user_tv_by_id(0), which should be 1", has a strange behaviour (black img like it's set to 0 secs)
(i think he has a not-too-new version, could that be the problem?)
-
Its been a while since anyone has posted anything about the G11.
If you have this camera, you might want to take a look at this thread (http://chdk.setepontos.com/index.php?topic=7071.msg76194#msg76194) as a problem fixed for the G10 & G12 might very well affect your camera too.
Please post in that thread if you try the test script and find the same failure mode.
-
If you are the owner of a G11 we need your help improving the manual focus / subject distance override capability of CHDK.
Please read the instructions posted here < Link to Testing Instructions (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859) > and test your camera.
TIA.
-
It seems, the function reboot() does not work for the G11. The camera restarts and the splash screen shows the text without graphics. After that crashes the camera.
It was tested with the ultimate intervalometer script and a small test script.
The problem was posted in the German CHDK forum: http://forum.chdk-treff.de/viewtopic.php?f=11&t=3325 (http://forum.chdk-treff.de/viewtopic.php?f=11&t=3325)
msl
-
It seems, the function reboot() does not work for the G11. The camera restarts and the splash screen shows the text without graphics. After that crashes the camera.
A romlog would be helpful (if the cam records one before the crash). Unfortunately I'm not familiar with booting issues (the notes say that "firm update" boot does not work, may be related).
-
Here is the romlog: http://forum.chdk-treff.de/download/file.php?id=2700 (http://forum.chdk-treff.de/download/file.php?id=2700)
msl
-
Here is the romlog: http://forum.chdk-treff.de/download/file.php?id=2700 (http://forum.chdk-treff.de/download/file.php?id=2700)
msl
Our old friend - FsIoNotify.
Was this with 1.2? If so I'd suggest trying the latest 1.3 with the recent fixes reyalp added for I/O related crashes.
Phil.
-
Was this with 1.2?
Yes. Now I wait for test results with 1.3.
msl
-
Same result with CHDK version 1.3 - crash.
msl
-
Same result with CHDK version 1.3 - crash.
On April 5, I protected additional functions in 1.3 for this assert, so it might be fixed now.
If it still happens in the current trunk, a romlog with the corresponding main.bin.dump from the build would be helpful.
-
I see all the G series now support FWT except the G11. I'd be happy to test any code to get it added to the list. ::)
Test version which includes fwt support and simpler loader code.
-
Sorry for the delay. I just tried the last build and the CHDK splash screen does not go away. It goes off for a moment and comes back on.
-
I see all the G series now support FWT except the G11. I'd be happy to test any code to get it added to the list. ::)
Test version which includes fwt support and simpler loader code.
@nafraf: Do you still have this code?
-
Hi,I found the code. The patch is in the attachments.
-
Hi,I found the code. The patch is in the attachments.
Thanks :)
edit:
Updated for current trunk and checked in as r5271, tested by koshy in https://chdk.setepontos.com/index.php?topic=13891.msg141387#msg141387