pv2patch
Version 0.3.2 of pv2patch has been released at the sourceforge site. ( https://sourceforge.net/projects/pv2devkit/ ) This release is fairly beta - I changed to a new patching engine, which should be a bit more firmware neutral. This will allow me to patch into highly firmware-specific areas. That said, I did -*test*-('") on 6410, 6430, 6520 and 6550 firmware and all the patch locations looked good. New patches include time lapse mode, and flash disable patch. Oh yeah, 6550 piclimit patch has been fixed. Flash disable patch is a bit of a hack - it doesn't stop the flash cap from charging, it just stops the flash from strobing. As a result, if you turn the camera off and on quickly, it flashes during init. If anybody wants this improved, track down the exact charging mechanisms and the mechanism that checks if the flash cap is fully charged. Otherwise just accept it, warts and all. ;)

Oh cool... Unfortunately I think I patched too many things and made a brick... (working on getting it to bootloader now..) Edited: BLUE Cvs 6550 firmware 30pic limit: Still shrinking file sizes. Timelapse mode: DO NOT USE causes it to become brick. Timelapse timer: Didnt try Flash Mod: Still makes clicks like normal flash but no light = cool but only for bright areas. RED cvs 6550 30pic fix: As far as I can tell, 400-600k for first 25 and about 300k and below for the 26-30 pics. Was afraid to try the timelapse...

I tried the time limit patch and uploaded the patched firmware to my CVS 6520 type 30. It made the camera completely unresponsive. If you press the on/off button, nothing happened. I had to short the flash and upload the pre-patched firmware back to the camera and it's alive again.

Ok, it's official - stay away from the time lapse patch for now. I'll look into the problem and report back.

Solved the "bricking" problem, I believe, but I'll have to wait before I can -*test*-('") with an affected camera in front of me. The problem amounted to a bug in the patching engine that added an extra patch point for time-lapse in some later rev firmwares. Unfortunately the same bug didn't show itself when patch locations were just being reported (how I verified for most firmwares) :oops: awdark, I don't have a 6550-blue firmware. When you patched for the piclimit, did it patch 5 locations?

Scanning file for interesting locations... [029A] skipping mute patch (speaker_enabled) [03B5] skipping mute patch (speaker_enabled) [27F2] skipping mute patch (speaker_enabled) [419B] skipping mute patch (speaker_enabled) [5EDC] skipping mute patch (speaker_enabled) [7897] skipping mute patch (speaker_enabled) [79B9] skipping mute patch (speaker_enabled) [A422] skipping mute patch (speaker_enabled) [A544] skipping mute patch (speaker_enabled) [198A0] skipping mute patch (speaker_enabled) [1C3EF] skipping mute patch (speaker_enabled) [1D784] skipping mute patch (speaker_enabled) [0429] skipping timelapse_value patch (210_secs) [5F29] skipping timelapse_value patch (210_secs) [7A2D] skipping timelapse_value patch (210_secs) [A5B8] skipping timelapse_value patch (210_secs) [1D7F8] skipping timelapse_value patch (210_secs) [088F] skipping flashbulb patch (flash_enabled) [8785] skipping flashbulb patch (flash_enabled) [B8BD] skipping flashbulb patch (flash_enabled) [1A97D] skipping flashbulb patch (flash_enabled) [1D555] skipping flashbulb patch (flash_enabled) [69B3] skipping unlock_camera patch (unlock) [1A40B] applying piclimit patch (30) [7FEC] skipping timelapse_enable patch (disabled) [33B2] applying piclimit patch (30) [8B84] applying piclimit patch (30) [B853] applying piclimit patch (30) [1AD4B] applying piclimit patch (30) [6B12] skipping camera_pid patch (virgin_blue) first checksum incorrect. adjusting first checksum. second checksum incorrect. adjusting second checksum. first checksum verified as correct. second checksum verified as correct. Created bluemods.bin.patched Press any key to continue . . . Is what the program patched.

Ok, the 4+1 locations for piclimit is normal, but for some unknown reason the soft-limit patch doesn't work on the 6550. It may be that we don't just understand the soft-limit patch as well as we thought. Patching it to 30 works for most firmwares, but other values seemed to introduce random compression artifacts, so it's not as simple as a limit. See the original discovery thread for more detail: forumer.com/viewtopic.php?t=163" target="_blank">http://camerahacks.10.forumer.com/viewtopic.php?t=163 Gotta throw my hands up on this one until we understand it a bit better. If anybody wants to play, try patching the stand-alone piclimit patch location (that's the soft-limit) to different values and see if you can get the compression artifacts to go away.

I've yet to make my cable, though I have made some progress clearing a path to my workbench ... :roll: Just a thought here: has anyone tried to decrease the max number of pictures? I wonder if the camera would then create larger, less-compressed photos ...

I believe the RAWS the camera creates are already lossless so thats the best you can do with those RAWs. The last 5 are just weird raws that are compressed... but the first 25 are losslessly compressed. (the people here said so! ^_^)

Ah! Guess I missed that about lossless compression ... or more likely forgot it, with all the data here!

Actually... I can't say for certain that images are always losslessly compressed. When the header value (IMGR_ROWMASK) is 0, it does appear that the image data is the original CFA - or very close to it. But, when IMGR_ROWMASK != 0, some of the image decompression code appears to be setting values by averaging other values. That may indicate lossy compression in those situations. This is most often seen in the highly compressed images taken beyond the 25-pic limit. I think that only a careful analysis of the compression algorithm in firmware will tell us for sure.

So has anyone else tried the timelapse patch?

Vanzy, I have the patch working when I manually apply it, but the automatic method is another story - it seems there's a lot of firmware revision specific code around some of the patch points, so it makes it hard to get a unique patch "signature" that doesn't apply elsewhere. (false signatures matching is what happened when the timelapse patch bricked certain cams.) I've been a bit caught up in the camcorder work, and have neglected my pv2 programs. I'll take a look at it again a bit later this week and see if I can't get it working. Worst case, I might just put out instructions for manual patching.

BillW, I have a 6510 blue up and running. A manual patch would be nice to have as I'm going kiting this weekend :). Firmware time lapse is so much cleaner than my current 555 timer hack.