[01:17:15] morris: The only project I have thought about doing for CHDK is looking for a way to do a single version that sniffs the camera version, does a table lookup to find the right routine intercepts, and has all code dfiferences using runtime flags rather than compiler flags.[01:17:31] morris: Sound feasible?[01:18:04] morris: i.e. even if the version is fatter, it would be a whole lot easier to get people to get hooked in it.[01:18:19] PhoXy: morris, well, this sounds feasible, and it already is a feature request (i had the same idea), however it seems to be difficult[01:18:41] Hacki: and i supposed it would slow down the boot process quite a bit[01:19:18] morris: BTW: I am a developer (I have even done embedded programming) so it is just a matter of finding the time to hack, rather than lacking the skills.[01:19:33] Hacki: cool.[01:19:45] PhoXy: i am looking for the original thread or request i made just now[01:19:47] morris: PhoXy: what was the difficulty?[01:19:51] Hacki: really. experienced devs is exactly what chdk needs [01:20:39] PhoXy: difficulty? a) i dont speak asm. i dont even speak C if it boils down to effectiveness and sluggishness b) it seems to be difficult & tedious[01:20:56] morris: The problem is that expeienced developers also tend to do it during the day (or I should be LOL) so perhaps don't have the same desire to do dev after work.[01:21:45] Hacki: probably[01:21:53] Hacki: we need an experienced unemployed developer [01:22:13] morris: Yeah Go global meltdown! GO![01:23:04] PhoXy: lol[01:23:50] morris: PhoXy - Hmmm - a) I did some 6502 asm as a kid b) I have done work in C, c) boring tedious work is the crux -- sounds too much like my job ;([01:24:15] PhoXy: found the thread: we already have universal dumper... why dont we have a universal loader? didnt raise a lot of attention though [01:25:08] PhoXy: btw it wouldnt even be needed to include all adresses in ONE binary[01:25:15] PhoXy: like in my request in that thread[01:25:33] PhoXy: we just need a small program that can read/write/move files and set the boot flasg[01:25:35] PhoXy: flag[01:26:52] PhoXy: "universal loader" boots, finds the "camera info string + firmware version string", then moves diskboot.bin & ps.fir from for example "bins\s3is\101a" (locations are in the table) to the root of the card, sets boot flag - reboots[01:27:26] morris: Sounds like a reasonable solution...[01:27:27] PhoXy: the udumper already can write to the sdcard, so i guess it should be possible, more than feasible[01:28:03] PhoXy: also it sounds extremely un-tedious and very exciting, the more i think about it ^^[01:28:04] pixeldoc2000: at least this will took some space on your memory card to have a bunch of chdk versions on it...[01:28:40] PhoXy: and it would work only once.[01:28:55] PhoXy: but this may be overcome[01:29:14] PhoXy: by a chdk option like "set card to uloader"[01:29:56] pixeldoc2000: maybe a nice setup or gui to choose and install chdk on the memory card would be a better "solution"[01:30:28] pixeldoc2000: like to extend cardtricks...[01:30:45] PhoXy: of course what might be the better solution would be to only limit the "universal" part to certain firmware versions, not different camera hardwares. meaning there would be a universal bin for the g7 for example ( i think 4 firmware versions are known)[01:31:12] pixeldoc2000: know thats a better idea[01:31:35] PhoXy: this would rid us of the need to do the vers.req thing, i mean, the people know what cameras they have[01:31:48] morris: Without looking at the technical details of each of the ideas it is pretty difficult to know which is easiest, or which is best.[01:33:09] PhoXy: mind if i add this conversation to the thread so it doesnt get lost and also revives it, making room for other devs to join in on the fun?[01:33:17] pixeldoc2000: the question is, if its easy to determ firmware version early at the boot process[01:33:17] morris: PhoXy : about space: 500kb and 50 versions is only 25MB - so I would ignore that issue.[01:33:39] morris: It should be possible to sniff it safely.[01:34:35] PhoXy: btw morris perhaps you can invest time & brains in the ELF loader? any experience regarding that?[01:34:47] PhoXy: this covers almost the same subject[01:34:54] pixeldoc2000: yes, stick it to the post![01:35:03] PhoXy: as with the elf loader we would have much more room for the uloader[01:35:09] morris: pixeldoc2000 We know the universal dumper can safely access ROM memory, so it can search (or sniff) the version within that.[01:35:20] morris: Or even jsut use an MD5 hash of the memory.[01:35:41] morris: I don't know anything about the "ELF" loader feature.[01:36:09] morris: Sure, stick it in the post.[01:36:17] pixeldoc2000: but md5 will take some time on "limit" hardware... but could be an option[01:36:58] morris: Well, you probably only need to md5 every 100th byte..[01:37:00] PhoXy: new branch - CHDK : Elf Edition - Developers wanted ELF loader is one of the most needed features of chdk[01:37:23] PhoXy: basically if this thing runs, we will never have any space or memory restrictions[01:37:42] morris: Got you.[01:37:58] pixeldoc2000: morris: maybe this would be enough[01:39:17] morris: I was wondering about a loadable libraries feature too!
a) rename/copy/vector the appropriate CHDK build for the firmware from a complete list on the card and reboot into it (PhyrePhoX suggestion), or
b) have a table of entry points for all the known camera firmware versions, and have a single CHDK build that dynamically configures itself to use the appropriate entry points from the table for the camera the card is placed in. The CHDK code would also need to use normal control statements wherever code is currently statically #ifdef'd (conditionally compiled)
1) Anything that slows down camera startup or CHDK startup is to be avoided, especially if that startup makes the camera slower to start (from button press to ready to shoot status). I already compile my own CHDK, currently only because multipartition support makes CHDK startup significantly slower and I don't need it.2) I often use those tiny16MB or 32MB MMC cards for testing, so 25MB on the SD card actually is slightly significant.
reboot. Time to copy primary.bin + time to reboot = significant additional boot time
1) Anything that slows down camera startup or CHDK startup is to be avoided
2) I often use those tiny16MB or 32MB MMC cards for testing
Is it just so people don't have to figure out which diskboot.bin to put on their camera ? It may sound harsh, but I'm not sure that the people who can't figure how to use vers.req and download the right file are going to benefit much from CHDK
Started by msl LUA Scripting
Started by KANKU45 General Help and Assistance on using CHDK stable releases
Started by outslider General Discussion and Assistance
Started by rand0m « 1 2 » Creative Uses of CHDK
Started by 2frugal General Help and Assistance on using CHDK stable releases