I-Appliance BBS The Official Source for Internet Appliance Upgrades and Mods BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.net Reply to Thread | Printer |

Home / MISC Areas / Cameras Bits Bytes & Beyond - 1 10 many 100 all Bits Bytes & Beyond - 1 10 many 100 all

Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Please use this thread for deep technical discussions on hard & soft wares of SMaL Cameras. For those recognizing Bed Bath & Beyond - I prefer hard 1s 2 soft 1s. Basically this thread is meant to be a continuation of Discoveries. 01-11-2005 22:03:42

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) sailpix Profile Ahhhh yes... There are 10 kinds of people in this world - those who understand binary and those who don't! - sailpix _/) 01-11-2005 22:43:41

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile I do not know why, but sailpix jibed an old memory from when I did not know binary. Binary was not in focus when I was in 7th grade (1964). While the perfect number patterns I saw and many others saw before and after involved powers of two, it is only now that my brite_eye catches some interesting 1s and 0s. I have not checked all known perfect numbers but it looks like all have a sequence of p ones followed by p-1 0s corresponding to the formula 2^(p-1)*(2^P - 1). For more detail follow perfect number link in my biography at: http://www.photo.net/shared/community-member?user_id=1135234 helping to solidify my number 1 google position. Do not despair over ramblings - soon we will all be scrolling to bottom and back up just few. 01-11-2005 23:58:24

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile I have completed an alpha version of PV2Tool2 http://forkboy.doesntexist.com/PV2Tool2.zip The general usage is [Find Camera] [Connect] [Unlock] [Get File Listing] then [Upload], [Download], or [Preview]... This version allows for the download and upload of individual files. Files uploaded to the camera have the restriction of needing to be the same size as the original file. You can also upload .BMP files which will be automagically converted to .TFTs and "Skin" your camera You can even be very brave and attempt to patch the Firmware.bin or .DAT files, provided the sizes don't change. Do this only at your own risk - You can kill your camera. So far I've only tested this with an older CVS Red. Now go make some discoveries! 01-12-2005 12:04:53

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Forkboy ...thx... I hope the UNLOCK is optional on the old pvtool you cannot download firmware if camera has no lock ie if we defeat lock will it function properly...... 01-12-2005 12:14:35

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email NEW CVS BLUE model DSUC 300 made by AOX.Inc D[SUC] D=? SUC=single use camera ?? > composite device 1> 3E8 \ 2480 \ Rev 316 2> 3E8 \ 2480 \MI_00 \ Rev 316 3> 3E8 \ 2480 \MI_01 \ Rev 316 > see USBMonitor results in Discovery > shutter/del/ON = 6A 31 > Have been unable to get LibUsb to recognize..I'm probably doing it wrong....!! 01-12-2005 13:13:05

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Forkboy.... It appears from your comments that I must upload entire Firmware.bin file.... If you had this out 2 days ago I may have saved my BLUE 400 Brite_eye Will PVtool2 download firmware from BlueFlatFoto???? 01-12-2005 13:19:55

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, I fear trying with an alpha release, but why - I can't share it. You returned yours right? Why not try again - with an SD card it becomes easy to transfer compressed files from Pure Digitals to SD card and decompress with blue flatfoto; and also allows over 150 pictures with a 256M card. I might be willing to try if I understand potential benefit. 01-12-2005 13:39:35

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, I would like to try a new AOX blue. Can you identify any outward appearance differences? I am not sure yet but the blues seem to produce better pictures with less imager noise - perhaps due to lack of lcd electronics. I will also check to see if AOX is involved in flatfoto hardware/software. 01-12-2005 13:56:59

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email They are a lighter shade of gray... The lens has concentric rings around it... It looks like it has an open shutter...and the shutter sound to flash time may be longer.... I have a sneaky suspicion that the model 400 is better,,but until I can extract pic's only guessing... The model # DSUC 300 is on bottom on the battery cover...you can see it in the package.... 01-12-2005 15:11:33

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, thanks. A bit odd model 300 less than 400 but pinch 6A 31 even better than my 2 mp blue flatfoto at 6620 assuming your pinch is firmware release. Maybe just newer software with inferior circuit board built in America instead of China for quicker response to hacked successes. Maybe I don't want to waste $10. 01-12-2005 15:34:42

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email FORKBOY..... I got another CVS Blue model 400 ...you new pv2tool2 cannot unlok it..... the display is all 00----00 LaMSxxxxxx64 your updated pv2tool 1.2 can somtimes un lock it your original pv2tool 1.1 works the best on this new blue..... and usbpoker can unlock it..... I think there may be a subtle timing issue with Pv2Tool2 ??????? may need longer delays between cmds???? just guessing...... OTHERS -- still no success on CVS BLUE model DSUC 300 01-12-2005 18:33:32

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Morcheeba and Forkboy... Can I write 0x400 bytes 2-512 blocks to flash with 1 command or must I use 0x200 bytes and write 1 ea 512 block I am unclear on this.................I don't want to trash another blue... 01-12-2005 18:37:18

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile I've never tried firmware writes with length != 512. I've been really cautious, so I didn't want to alter large blocks of firmware. You can always try this command with an unused block near the top of FLASH memory. Also, since files are allocated by clusters, it might not make sense to write more than one cluster's worth of information in case the allocated clusters are non-sequential. 01-12-2005 19:01:06

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile ForkBoy, nice tool2. Works great on my flatfoto blue - downloaded FIRMWARE.BIN without any difficulty. It is the same size as one I downloaded from a Pure Digital red blue cvs ritz I do not remember - but both are 125K. For all other cameras my experience is similar to mikes - no luck unlocking (find and connect work). pv2tool dated 12/30 works fine. I am guessing but I think it may be because you try both key types and if first fails second fails. My cameras are all reset LaMSSMaL. 01-12-2005 19:53:11

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile morcheeba, How is that flatfoto blue has same size firmware but operates with more functions and buttons. I can bring up a menu to turn flash - on auto off, size - small med large, lcd - high low off, ... . There are separate buttons to turn lcd off, format flash, view any picture ... Are there large vacant gaps in your 6410 code? 01-12-2005 20:01:32

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Finally got Libusb configured for CVS BLUE DSUC 300.....however I have no tool to talk to it Can someone mod usbpoker to intf 1 settings ?????? Looking at device \.\libusb0-0004--0x03e8-0x2480 This device has 1 possible configuration(s). Looking at configuration 0...This configuration has 2 interfaces. Looking at interface 0...This interface has 6 altsettings. Looking at altsetting 0...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 01h (Isochronous) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at altsetting 1...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 01h (Isochronous) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at altsetting 2...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 01h (Isochronous) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at altsetting 3...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 01h (Isochronous) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at altsetting 4...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 01h (Isochronous) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at altsetting 5...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 02h (Bulk) (In) Endpoint 01: Address 82h, attributes 03h (Interrupt) (In) Looking at interface 1...This interface has 1 altsettings. Looking at altsetting 0...This altsetting has 2 endpoints. Endpoint 00: Address 84h, attributes 02h (Bulk) (In) Endpoint 01: Address 05h, attributes 02h (Bulk) (Out)an someone mod usbpoker to different intf1 / endpoints.... 01-12-2005 20:18:37

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile I went to CVS tonight and got another CVS Red, I'll try to pick up a Blue tomorrow. This will give me chance to try the 2 keys... If the key fails or there are other errors, please copy & paste of the text from the debug info and email it to me. (Just select all of the text and do a Ctrl-C) Forkboy At Verizon Dot Net. Also, please go to device manager find the camera and send me the driver details - a list of all of the drivers used for the camera and their versions. Has anyone tried changing any of the values in the config .dat files? (morcheeba?) Also, I would stick to 512 bytes or multiples there of for reading & writing from the files (usbpoker & your own progs) 01-12-2005 21:09:47

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) Drmn4ea Profile Sorry Mike, not sure I understand the question (modifying usbpoker for different interfaces). All valid bulk configurations should appear in the dropdown list; just select & open. The INTerrupt and ISOchronous enpoints are not yet supported by usbpoker / libusb - these are probably for a webcam stream mode. (Support for ISO on the way! I think some test code for this is in the CVS snapshot version of libusb-win32.) 01-13-2005 01:39:04

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) cheapseats Profile ForkBoy, FYI... I tried the PV2Tool @ tonight and it just locks up (with static hour glass) when I try to get the file listing CVS Red Model 410 FW 6520 HW 06 TypeID 2B ====== PV2Tool 2 Alpha Use this software at your own risk. The author takes no responsibility if you damage your camera. Found the camera: SMaL Digital Camera, VID:0DCA PID:0027 Connected to camera. Attempting key 1... Attempting key 2... Success. ======= Is there a cmd line option to get more debug info? 01-13-2005 03:04:20

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Drmn4ea I was assuming you were using like addrs 84/04 etc but usbpoker is using 84/05 CVS BLUE DSUC-300 USBpoker won't bulk out to endpoint 5 get err.....this may be an attempt at hacker proffing.... There are still a lot of Blue 400/ Red 410 at cvs.... 01-13-2005 04:23:48

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile cheapseats - no there is no command line for more debug info. I'm wondering if your FAT table is at a different location - Mine is currently hard coded (BAD BAD BAD) Have you had success extracting the entire flash with the older pv2tool? Hopefully I can reproduce your problem with the Red I got yesterday. Drmn4ea - send me an email if you would like to collaberate on anything related to PV2 01-13-2005 07:22:10

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile ForkBoy, what is key1 and key2 - if key1 is virgin and key2 is hot plugged experienced reset then perhaps a failure of key1 prevents key2 from working? If so I would like to be able to select as before. Note if reverse of above is true then maybe key1 works and then is locked again by attempt at key2. 01-13-2005 07:48:05

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 1 times) ForkBoy Profile Okay, as requested, you can now select the key - Key 1 is the "reset" key, Key 2 is other other key that was floating around. http://forkboy.doesntexist.com/PV2Tool202.zip Maybe we should just have a key file... Anyone have any suggestions on a patch file format for patch firmware.bin function? 01-13-2005 08:07:35

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) cheapseats Profile ForkBoy, I do have the flash image from the older PV2Tool but not quite sure what to do with it. 01-13-2005 08:32:38

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Just tried Pv2tool2 on CVS Blue 400 ... Was able to unlock using key 2..... when trying to get file list ....+ DCIM diaplays in window then get POPUP PV2Tool OUT OF MEMORY ..this is on Win 98 with 64MB memory havn't tried on LAPTOP yet... 01-13-2005 08:47:14

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 1 times) ForkBoy Profile I will try to get a Blue and recreate the problem. The entire flash image is useful for checking where things are, if you aren't familiar with a FAT file system, it will probably not do much good. DCIM... Do you know how many images you have? Maybe there is a bug if the directory is empty. I'll try fixing the hard coded FAT locatation at lunch ~1pm EST 01-13-2005 08:54:19

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email CVS BLUE on XpSP1+ unlocked with key 2 ok ....get file listing ran,ran,ran, I stopped it after 5 min.... camera is virgin ..no picts .. verfied with download using pv2tool 1.2 01-13-2005 09:58:44

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile I just picked up a new 410 (one with preview-ours are blue by the way) to see if I could solve the blueness issue with the pictures (mike, forkboy - yes the blue/black appearance of the images but much detail can be made out)--the two files (PDSCRTCH.BIN & CAMCALIB.BIN) are missing from my old camera so I'd like to work explore the replaceing of them first. The new camera would unlock using key two with the version 202 of pv2tool2 but would hang when I pressed 'get file listing'. I tried with the old camera and got in, unmodded it, and was able to unlock, and get the file listing from it. Both cameras had the same number of original files. I did try the original pv2tool and found that it could unlock the new camera and and was able to download the flash contents. Upon examination I found the following: Both cfg.tar.fw.version=0x6520 Old cfg.camera.typeid=0x30 cfg.tar.creationdate=08.09.2004:16:17:30 cfg.tar.fw.src.file=t30-a06-f02-v6520.pack New cfg.camera.typeid=0x2b cfg.tar.creationdate=08.09.2004:16:12:53 cfg.tar.fw.src.file=t2b-a06-f02-v6520.pack I also compared the firmware.bin files and found many (very many) differences, even though both are 6520. Forkboy, could you add the entire flash download, and an entire flash upload to the new version. I have the original fresh dump and would like to try a reloading. Also, in the old tool, old camera unlocked at configuration 1 but not two and the new camera unlocked with configuration 2 but not one. Thanks ForkBoy! 01-13-2005 19:34:23

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile taytrr, mike. 2 of u r making my head spin. Blue is not blue, red is blue, what I am to do? I looked for mike's 300 at 4 CVS stores tonight but only saw 400s (most of these have to be slid off racks to look at model on bottom and there are 3 racks in different locations in most Michigan stores). Ok, taytrr, if Long Red is really blue is a Long Blue really red? I was looking closer at the lcdless b&w lcd and it seems very crisp with tiny characters (clearer than red brother) - does anyone know pixel dimensions and gray scale range. I think with enough time I could change firmware to display center of picture to allow focusing the screwable lens! The CVS Blues are $8.99 until 1/22. mike, can you supply a simple fool proof way to identify difference between 300 and 400 from front of packaging. For half the price, longer battery life, lack of clear red lcd image ..., I think the Blues are a better buy - especially for playing with firmware updates. 01-13-2005 20:15:37

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile brite_eye - Longs model 400 without preview (dca-28) are red Longs model 410 with preview (dca-27) are blue It seems that the most accurate way to identify them would be hwid + firmware as in: my old 400 would be a t28-6520 my old 410 would be a t30-6520 my new 410 would be a t2b-6520 This is the same notation that is referred to in the firmware name as well. Since there are clearly quite a few variations we should make a better effort than simply calling them red or blue, especially since each has different compatibility issues. What do you think? 01-13-2005 20:54:37

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile taytrr, I think before long it will be impossible to manage such version craziness on these threads. We need a more intelligent medium with internal google search ability. A good challenge for someone like binaryweaver - hey binary how much bandwidth can you handle? Without any financial incentive our efforts may be dwarfed by vastness of marketing for these cameras - a truly historic event for photography if these cheap cameras sell like CVS expects. Hundreds of hacked cameras will not even impact the bottom line. Any suggestions are certainly welcome as we are rapidly becoming overwhelmed. 01-13-2005 21:35:29

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile The model 400 little b/w lcd display only displays a few fixed items (no resolution). The items in the display are: * Two seven segment characters (for the counter and formware/sn readouts) * "Remaining" * "-Return for Prints" * "Wait" * "Timer" * "Delete" * a three bar battery power indicator * a slashed circle icon (a 'no' indicator) 01-13-2005 21:39:33

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile taytrr, yes I have seen the same, but a question remains are the displays sofware limited or hardware limited and is there any grayscale? 01-13-2005 21:58:44

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Taytrr.. the may be a prob with pv2tool2....Forkboy aware...I got out of mem on w98...and xpsp2 I stopped after 5 min of get file list....prob may be that there were no pics on camera Brite_eye the best way to check DSUC-300 is to read the label on the battery cover..I don't see anything on package that stands out ....the camera lens has concentric rings around it ,,,Also shutter is not visible,,,also there is no BLACK RING around the lens its gray...and the entire case is a lighter gray... 01-14-2005 03:42:20

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile Although it didn't yield any results in terms of windows file access, I was able to get the Windows XP USB Mass Storage driver to load for the model 410 (T30-6520) and stay loaded using the USBSTOR_CBI type in \windows\inf\usbstor.inf modeled after one of the NEC's there. I didn't have any luck until I modded the camera removing the authentication. I thought this worthy of posting because every other one failed and wouldn't start the camera, except this one. In addition, ForkBoy's PV2Tool can work with the camera using this driver (in case you don't want to use libusb). A final version of the whatever could be modeled using existing Windows drivers. In addition, we might be able to mod the firmware to actually work by changing the non-standard codes documented in morcheeba's web page. I wasn't sure where to look in the firmware though. Anyone think it's worth any effort? 01-14-2005 04:48:09

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, thanks looking for a gray instead of black ring will allow me to quickly scan a stack of cameras without sliding them off the hook. Down to just 2 blocks good work - I believe a single block change for just $80 01 to 02 would be easy considering comments in morcheeba's site on use of C compiler instead of hand coding - if there is no text available to change in $80 block then removal of excess code should allow an adjustment to avoid new checksum. Adding several camera codes to a single windows inf driver file will be far easier than several version level multiple block firmware updates. Some of us already have a slew of cameras and many of us will be acquiring more. Note I have had no problems switching from red 27 to blue 28 cameras to flatfoto 29 using a single Che-ez inf file containing 24, 27, 28 and my flatfoto 29. I doubt there is a separate chip just for lcdless b&w lcd. I also doubt if text for return and remaining are hard wired (amazing how sharp, clear, and tiny they are). I continue to hope for a way to display a focus ring of some sort on cameras with unglued lenses. 01-14-2005 06:46:08

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile taytrr - We must be on the same "wavelength" - I added a full flash download & upload last night http://forkboy.doesntexist.com/PV2Tool203.zip Now we can clone cameras. 256K chunks, takes about 60 seconds to download, haven't timed upload. I also had success with the 6520 patch to make it cheasy. Mike - I'll see if I can find an obvious memory leak when populating the directory tree. 01-14-2005 08:32:50

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile taytrr, I have failed to understand what you meant by "we might be able to mod the firmware to actually work by changing the non-standard codes documented in morcheeba's web page". Can you shine some brighter light so my eye can see it? 01-14-2005 08:53:29

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Forkboy... Did you test the flash upload????/ The CVS BLUE 6520 Type-8 will unlock and download flash but will not get files etc... I'm tempted to modify the firmware in the flash file and try upload....,,,but I may wait awhile 01-14-2005 11:10:25

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile ForkBoy - New tool (203) will download then error with a resulting flash file size of 2,883,584. The original tool will download the complete flash from same camera (I'm working with the modded T30-6520 - model 410). I'll wait (anxiously) until the download works before attempting an upload. brite_eye - The mod I referred to would be one that would allow the camera to work as a standars USB Mass storage device. On Morcheeba's page about the USB interface he heplains how the camera does some things differently and wont work as a regular USBMSD device. I was pondering if we could fix it, or if it was even worth the effort. 01-14-2005 17:09:13

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile ForkBoy - I can upload and download entire flash successfully on the T28-6520 (model 400) with Pv2Tool v.203 01-14-2005 17:40:22

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile Mike - Forkboy... Did you test the flash upload???? Yes, with a CVS RED 6520 Type-6, I successfully tested the flash upload with single files - FIRMWARE.BIN and .TFT as well as the full 16MB flash upload I have a new CVS Blue and haven't tried it out. taytrr - It is weird that a flash read would have an error mid-read. My best guess is that the problem is because I increased the read size from 128K to 256K to speed it up. I will change it back to 128K 01-14-2005 17:42:49

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email New CVS BLUE DSUC-300 PCA - > Avalon EPA Controller Rev A ODM00001524-100 chip 1 > F P35SB LVX32 chip 2 > DC0423112GU paper tag > HOLTEK HT1621 A341K0462-2 chip 3 > ENDPOINTS EP402C MGM2G000 200334 chip 4 > MT/TG -75F 0336 3-1 48LC4M16A2 chip 5 > SAMSUNG 337 K9F6408U0C-TCB0 T60124FA Korea Shutter assy paper tag DS04230020R ....have not removed assy to see image chip.... all 10 connector pins been scrubbed....appears that all pins may have a function ???? 01-14-2005 17:44:01

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email pv2tool203 ... I get directory err etc on CVS 6430 RED after 2-3 retries will read ..act like cam gets hung in some error state??? ... did not work until use pv2tool 1.1 download flash then PV2tool203 worked until I forgot to hit button when disp tft...then took replug and 3 retry's to continue....Xp-2 2.7GHZ Celeron I did not see this Xp1 Dell Laptop 700 MHZ 01-14-2005 17:51:01

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile More and more confusing. Looing back at "New type of Dakota, or is it a PV2?" thread there were reports of a non PV2 Blue that is similar to mike's "new" blue back in September. Here is a partial repost by koikoi on 9/05/2004: Getting the camera info (mentioned in epcam_init) yields: 16 00 02 04 6a 31 00 05 00 04 03 00 00 00 01 00 01 00 03 02 08 00 This is a series of two-byte values, LSByte first. value-by-value, referenced against user output in epcam, it turns into: 16 00: size of data (0x16 = 22 bytes) 02 04: camera ID (0x204 = 1026) 6a 31: revision (0x316a = 12650) - same as what you get when you hold shutter during power on 00 05: max width (0x500 = 1280) 00 04: max height (0x400 = 1024) Do these even have a SMaL imager? I wonder if someone exchanged an older Blue at mike's CVS. mike was there more than one 300 Blue? What State are you in? 01-14-2005 20:31:33

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, PO is not one of the 50 states I am looking for. 01-14-2005 20:38:13

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Well I just grabbed 2 Blues and didn't bother to check....both blues are DSUC-300... I think I will take one of them back and try to get a 400 I could not see any markings on the imager....... I'm in the south Atlanta Area..... 01-14-2005 21:19:18

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email CVS BLUE 400 Just used Forkboy's PV2tool203 Downloaded flash modified location 22991 changed from 1 to 2 changed 22b2b D i g i t a l to C i g i t i a l Uploaded aok...camera functions AOK Camera is permently unlocked........! yi pi ki yi aye!!! thx ForkBoy thx morcheeba sidenote! my trashed Blue is trashed ... every read give me my 1st 512 of firmware 01-14-2005 22:48:50

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) Drmn4ea Profile @ForkBoy I tried downloading flash from my 6410 Red (flash writes re-enabled) with PV2tool.exe and PV2tool203.exe; both begin transferring, but download fails after a variable percentage (have seen between 5% ~ 15% over about 8 runs). (The portion that is downloaded appears valid.) Also, using "Get file listing" causes the program to 'hang' at 100% CPU usage (2 runs; eventually killing the process after a couple minutes). Are these known issues with 6410? Any way to get more diagnostic info out of the program? (Suggest increasing libusb-win32 timeout from 1 sec. to e.g. 5 sec; USB timeout gave me trouble in the previous USBpoker causing 'long' transfers to fail. Maybe it only affects those of us with dinosaur PCs 01-14-2005 23:13:56

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Double Success posted in Success, patch reposted here: T28-6520 Patch: 6991 1->2, 6B2B D->C; T27-6520 Patch: 6910 1->2, 6AAA D->C. I have doubled my pleasure with doublemint success (old gum commercial - showing my age). taytrr, I do not have PDSCRTCH.BIN & CAMCALIB.BIN on any of my reset cameras and they all work fine. Please provide a link to a T30 selfportrait blue hue - I think T30 may not agree with Che-ez! I can now thanks to ForkBoy easily upload and try my flatfoto driver (at least I think that should work, if not I can copy to SD card and use my Blue FlatFoto). ForkBoy, Can I upload an IMG_0001.RAW using PV2Tool203? 01-15-2005 02:36:04

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) ForkBoy Profile New version of PV2Tool2 http://forkboy.doesntexist.com/PV2Tool204.zip Changes include 16MB flash disk read & write are now in 128K chunks, timeout is 5s. Also, it now works with my new CVS Blue 400 (PID28, LCD reports EB,50,44,43,40,90 on three finger salute) The CVS Blue problem was that with a virgin camera, the RAW directory file had junk (0xe5) where I expected it to be empty (0x00) * Note on CVS Blue 400 - It appears that the NVRAM.DAT changes each time I transfer the flash. (This doesn't happen with my CVS Red 410) The flash transfer functions have been tested by transferring files back and forth from the fash as well as the entire 16Mb. I checksum the files using MD5SUM 01-15-2005 16:48:19

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email FYI - late observation wxp-sp2 My pc has 4 usb connections 2 in front ,, 2 in rear ... Device mgr shows 4-root hubs / 3-host cu and 1 Enhanced host cu I can plug a new cam on bottom front usb port previously set for LIBUSB ,, then alter with PV2tool then move to top usb port that was previously set for Foxz2 ...no driver changing involved and no libusb mod to Foxz2 driver inf 01-15-2005 22:02:12

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile I've been working on my blueness issue on the T30-6520 (model 410) and found the following: * .Raw's taken on and downloaded from the T30-6520 and uploaded to the T2B-6520 then downloaded with the Cheez2 driver are still blue. (previews are normal) * .Raw's taken on and downloaded from the T2B-6520 and uploaded to the T30-6520 then downloaded with the Cheez2 driver are normal. I tried uploading my T2B-6520 Flash to my T30 and the camera works normally except that pictures come out greenish with either the tops or bottoms damaged but the color mostly normal. T30 reloaded with original flash but nvram from T2B or deleted nvram file operates the same (blue pictures) I conclude that something happened to the software configuration that could be corrected with a factory flash load (to get it, I'll have to go out and buy another 410, and hope I get a T30). If someone else has it messed up in the same way we could swap camera's (my messed up T30 for your messed up T2B). If interested, email me at my id at comcast dot net, my id is taytrr. 01-16-2005 01:54:30

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile Another obvious implication of the difference in operation I experienced (see above) is that any firmware mods may need to be different in construction, not just file offset to work. This may explain why some modders have had trouble and ended up with cameras unusable and in boot-loader mode. Please be careful and if you're not absolutely sure what you're doing please wait on modding your camera. 01-16-2005 03:14:02

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile taytrr, I still think the blue hue is due to driver software level. Please send 1 or 2 blue raws to borg12of48 at yahoo dot com. 01-16-2005 04:14:52

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile brite_eye -- Thanks, I'd appreciate any help. .RAW's on the way (Oranges, Clock and, Kids Letters). I'm so sleepy I can barely type and am nodding off as I type - it's bedtime. 01-16-2005 04:59:27

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) Drmn4ea Profile @ForkBoy: Thanks, changing the timeout seems to do the trick - I'm now able to read flash and file listing with PV2tool on my old USB 1.1 workhorse. With my irreplacable picture files safely off the CVS 6520 I'm going to test out my win32 port of morcheeba's PV2mod on the Ritz 6410 (remove challenge-response for Fozx2 driver) before daring to release it to the public. I'll try uploading the 6520 files to the 6410, snagging with Foxz2 and see what happens. 01-17-2005 14:55:09

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Have sucessfully altered firmware in 1 6430 CVS RED t27,, 5 6520 CVS RED t27,, 5 6520 CVS BLUE t28 and made macro lens setup in CVS BLUE ,,and have change 1 RED PID to 24 and 1 BLUE PID to 29 all with pv2tool204... pv2tool204 sometimes get error when start read/write cmd ..but retry somtimes works and somtimes must replug reopen etc.... I've had only 1 prob with a BLUE ,,,was getting no picts, just colored snow, dissassembled cam and looked saw nothing..reassembed, and think used different batteries...cam seems ok now ????? Brite_eye have you tried macro without shutter,,if so what did it look like......? 01-17-2005 15:34:15

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mike, no shutter on any macro. shutter jambed between black blob and lens holder. not on top of lens. short from i330 phone. 01-17-2005 17:35:49

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) Drmn4ea Profile @taytrr - how did you upload new pictures to a camera? (I looked at PV2tool, but it seems it only allows replacing an existing file, with the same length - or am I missing something obvious?) @all - Foxz2 does NOT seem to like the cutline black from my Ritz LCD 6410 (TWAIN frontend exits, and takes Paint Shop with it) - and leaves a partally completed 'JPEG' image in the user home directory containing EXIF data followed by the compressed file followed by space for (presumably the uncompressed one, to be replaced by a JPEG). Could be that a cutline pic is not even considered a valid, decompressable file? Or maybe just a post-process filter doesn't like it, and takes the Foxz2 driver down. Other downloaded pics transfer OK. I haven't yet tried uploading .RAW files from 6520 onto 6410; it's now looking like way more work than I had anticipated. 01-17-2005 20:56:52

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Trashed CVS BLUE DISCOVERY? $51 cmd to input 1fff or 3fff apparently enable's reading issue bulkins of same length as in cmd block until end with 13 bytes xfered got 8192*7 + 4607 + 13 = 61964 got 16384*3 + 13311 + 13 = 62476 don't know what this means?? status = LaMSxxxx effy 0000 00 y=1/3 01-17-2005 21:09:31

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile Drmn4ea - I downloaded the flash from both cameras, opened in WinImage, then moved files between, then uploaded updated flash's back to camera. 01-17-2005 21:31:02

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile ForkBoy - I'm still not able to download the flash from my type 30 (410) with the new tool 205. My type 27 (410) and type 28 (400) both download fine with the new tool. The original tool downloads the type 30 with no problems. The original tool settings are: configuration 1 and cleared key. The file downloaded with the new tool is 3014656 bytes (0x2E0000) in length. I can upload the file with preveios versions of the tool and still have a working camera with updates, just can't work with the whole flash. Could you allow an option to upload anyway if the length is wrong (with warnings of course) and help me with the inability to download the whole flash from the T30? 01-25-2005 19:09:53

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile I tried Drm4ea's latest windows port of morceeba's pv2mod but did not make it past first test read. I used PV2Tool203 to unlock camera then went to command line and executed "pv2mod -pid=0x0028 test-80-disabled" which resulted in: Looking at device \.\libusb0-0005--0x0dca-0x0028 Found camera with USB id 0DCA/0028 Camera interface looks legit, starting to process modfile ># This is a read-only script to see if the $80 command block has been disabled. >ReadFileBlock FIRMWARE.BIN 0x34 Reading file FIRMWARE.BIN, block 0x0034... Reading partition table... sending: 4c 61 4d 53 1d ba ab 1d 00 02 00 00 80 01 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Read pipe return = 0000020d (no error), size = 1024 Reading start of partition @ block ffffffff... sending: 4c 61 4d 53 1d ba ab 1d 00 02 00 00 80 01 00 52 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 Read pipe return = 0000020d (no error), size = 1024 BytesPerBlock = 0 blocksPerCluster = 0 reservedBlocks = 0 totalFATs = 0 maxRootEntries = 0 Reading FAT table @ ffffffff... Then windows presents send error report: AppName: pv2mod.exe AppVer: 0.0.0.0 ModName: pv2mod.exe ModVer: 0.0.0.0 Offset: 00001f85 HELP! Any suggestions? Is VerifyBufferCRC needed for each read and how are values obtained? Is it automatically calculated on writes? 01-30-2005 08:42:15

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile brite_eye- I'd guess that the $80 check was still in your camera because he data looks buggered. The first error is "partition @ block ffffffff...". When pv2mod reads a block, it ignores the status code -- that's a to-do on my list. There are two variables used that are similar, so I'll clarify: - There's the CRC (cyclic redundancy check), a 32-bit value computed to describe a block -- this is used only by PV2Mod to make sure that blocks about to be modified are the intended ones. This changes whenever you read a block of memory. VerifyBufferCRC is purely optional & I put it in the scripts to make sure that the block about to be modified is what's expected. When developing the mod files, I used the PrintBuffer command to print out the buffer & its CRC. - And, there are two 16-bit checksums used by the PV2 to verify FIRMWARE.BIN -- one covers address 0-ffc, and the other covers 0-EOF. These are modified whenever you do a SetBuffer, and can be reset to 0 by ResetBuffer. SetBufferChecksum can also reset the checksum. 01-30-2005 23:21:32

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile I hooked up another cable to my borked camera and started following j94501's lead at figuring out commands to it. (thanks for the good start you documented in the failures thread). I've tried getting the bootloader code from it so I can disassembler it, but so far no luck. So, I started looking at commands $26 and $28 in FIRMWARE.BIN. It turns out that these commands allow you to upload a small (<$4000) program into SRAM and execute it!. So, I cobbled together a short little program that turns on the LCD & makes a bunch of beeps -- it worked! If you want to develop code, then this would be a great way to try it out without burning FLASH every time & worrying that you might fry the camera. The bad news is that it doesn't seem to work with the borked camera, only the good one. Otherwise, to fix the camera, I'd upload a program to write a block of FLASH. Also, interestingly, during my experimentation with the broken camera, I did something that made the LCD come on and display the Ritz "turning off" message - so, maybe there is a way to get it to ignore the bad checksum, or maybe I got lucky. 02-01-2005 01:34:41

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile morcheeba, I did not receive "Camera interface looks legit, starting to process modfile" when trying without unlocking camera first. The 1024 size returned seems a little odd - as if the 02 means 2 blocks not 512 (is this a change for newer cameras?). 02-01-2005 08:26:57

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mike Profile | Email Morcheeba Since YOU can load code and execute on a good camera ,,why not get the bootloader from a good camera,,,I'm assuming the bootloader is in the V8 rom???? YOU might be able to copy it into a internal file within the camera since you could get the memory addresss of destination before hand??? surely the files aren't crc'd What cmd's did you use to load this code ,,, what's your code look like???? Is there a manual available for the op-codes for the v8.....I havn't found anything useful...i.e. [like microchip manuals etc..] 02-01-2005 14:55:34

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile Try here for more info on the V8. One of the first firmware.bin mods I made was to change one of the commands to read an arbitrary 16-bit address from the processor's memory. I the whole 64K & found out that the unused areas (0x4000-0xf000) are just aliases of the SRAM memory (0-0x3fff), so to get to the bootloader will probably require some toggling some unknown register. Too bad. I'll probably have to keep working on my bootloader camera to get it to yield secrets. The code I wrote looks like this: 0xe0, 0x42, //924d2: e0 42 +10 LDI R0,#$42 // turn screen on? (reg is cleared when turning screen off) 0xc8, 0x2f, 0xf7, //924d4: c8 2ff7 +11 STA R0,$f72f ;($f72f) = $42 0xe1, 0x02, //924dc: e1 02 +14 LDI R1,#$02 // Set bit 2 of $F72E - turns screen on (cleared @ screen off routine) 0xe8, 0x2e, 0xf7, //924de: e8 2ef7 +15 LDA R0,$f72e 0x19, //924e1: 19 +16 OR R1 0xc8, 0x2e, 0xf7, //924e2: c8 2ef7 +17 STA R0,$f72e 0xe2, 0x40, //0090: 047e: e2 40 +15 LDI R2,#$40 -- make a beep 0xe4, 0x04, //0092: 0480: e4 04 +16 LDI R4,#$04 0xcc, 0x00, 0xf7, //0094: 046c: cc 00f7 +8 L046C: STA R4,$f700 0xca, 0x01, 0xf7, //0097: 046f: ca 01f7 +9 STA R2,$f701 0xe0, 0x02, //009a: 047e: e0 01 +15 LDI R0,#$01 0xc8, 0x02, 0xf7, //009c: 0475: c8 02f7 +11 STA R0,$f702 0xe8, 0x03, 0xf7, //009f: 0466: e8 03f7 +5 L0466: LDA R0,$f703 0x90, 0xfb, //00a2: 0469: 90 fb +6 BNZ L0466 ... 0xbc, 0x90, 0x00 // bc 9000 +45 JMP L0090 Sorry, I couldn't make the formatting look good. 02-02-2005 00:42:38

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Great info from morcheeba. It should be easy to come up with a one block firmware mod to permanently unlock cameras (different assembler sequence with same result but also same checksum). Can Drmn4ea's tool be used to write a single block? Does $52 automatically supply a CRC that is needed(?) for flash writes? When and how is bufferCRC calculated? Overly cautious after one fried borked Ritz 6410! 02-02-2005 09:39:21

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile I have been able to temporarily unlock a new 28/2F CVS Blue using Drmn4ea's windows version of morcheeba's pv2mod with an uncommented test-80-disabled modfile. Looks like my previous pv2mod failure was a result of mixing forkboy's pv2tool to unlock(challenge/response) and pv2mod to readfileblock - must do both in pv2mod. I am still afraid to unlock permanently using a multiblock script. I have found a couple high risk one block changes that I would like to test in SDRAM (not FLASH). Anyone having disassembled 6410 firmware please feel free to comment on my suggestions (I do not have a computer brain and have not fully explored all consequences): Two instruction change (1 block) 1390D: e4 01 change to e0 04 (for a -1 checksum change and note 13906 is also e4 01). 13912: e0 01 change to e0 02 (as in morcheeba's change but with no checksum change). ____________________________________________________ One instruction change to permanently unlock camera 131a5: e1 01 change to e0 02 Note that R1 was previously set to $04 and still will be $04. 131ab will always branch since if $0f21 is $04 then 131a3 would have already branched to 131b5. _____________________________________________________ Which of the above has least risk? 02-05-2005 11:15:46

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile woo hoo, it's late but better late than never. morcheeba's pv2mod (ported by Drmn4ea) works like a charm if you follow his instructions - if not expect another fry. I first tried my one instruction one block zap and out of fear (since once you disconnect its over if something failed) I ignored instructions to unplug immediately after script completion of pv2mod. Instead I wanted to see if I could download updated firmware using latest PV2Tool - no luck with file list but I did save 16M flash. Well when I finally disconnected it was fried. After reviewing code and finding 2 corrupted 256 blocks with LaMS headers, I decided to try again and unplug immediately without any attempt to verify (as indicated at end of morcheeba's log). YES that worked (lesson – do not try to verify before unplugging). I have only tested one picture but I am confident my one instruction zap is working fine! Here is script I used for a reset T28-6520 Blue CVS: GetChallenge PrintBuffer VerifyBufferCRC 0x0ea3bb88 SetBuffer 0 4c614d53000000000000... (all zeros to end for 128 byte total) SendResponse ResetChecksum ReadFileBlock FIRMWARE.BIN 0x31 PrintBuffer VerifyBufferCRC 0x7584eb5f SetBuffer 0x19 e002 PrintBuffer WriteFileBlock __________________________________ Note that this was using latest libusb from 11/18/04 and XP SP1 with all other drivers removed. I then tested on another instance of XP SP1 with modified flatfoto driverx.inf and older libusb combo, but expect it will work fine with just che-ez modified for 28 (will verify later and post to firmware thread). 02-10-2005 01:29:48

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile A little more experimentation with bootloader mode. I found bootloader-only command $51 but couldn't get it to do any useful tricks. Also tried some other stuff, but nothing worked yet... 02-13-2005 00:20:59

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Has anyone tried using internal SW1 along with $51, $19, $26, $52 writes ... on a fried camera? 02-13-2005 06:09:07

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) morcheeba Profile I've updated my FIRMWARE.COMMENTS file with my additions from the last two months. Download it here. I've rolled in my memcpy/memmove fix, and also thanks to j94501 for the makefile to help build on unix-like systems. FIRMWARE.COMMENTS have more info on a few of the less-used USB commands (the two that return general registers and status, not the ones that do cool stuff), beeping, and LCD screen power on/off, plus probably some things I've forgotten about. Here are the customary stats: last version: disassembly = 55k lines, 2.5MB, FIRMWARE.COMMENTS = 4635 lines, 182KB this version: disassembly = 55k lines, 2.5MB, FIRMWARE.COMMENTS = 5346 lines, 209KB 02-21-2005 16:52:43

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile sorry for the post in the dead thread guys... it's getting a bit confusing with all of the different threads around here. Anyway, here's the latest bit of good news... This discovery brought to you by Teslafreak... his procedure to reset a CVS Red camera to LAMSSMAL follows. It appears to be quick, easy, and repeatable. - installed liusb and ifranview with foxz2 driver - modded the inf file [so it includes a device with PID 27] - installed camera [pointing installer to foxz2] - clicked on device manager and removed the camera from the hardware list - unplugged camera and found the camera was reset I'd suggest anyone wanting to buy more cameras do it sooner rather than later, before they close this hole in the firmware. 02-23-2005 20:35:34

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Is the following a new accidental discovery? This weekend I made a new cable using a $1.49 official Palm hotsync cable (pricegrabber luspoc, 2 cables @ 1.49 plus 5.00 shipping or $7.98 total). I followed Drmn4ea's method but left the switch and capacitor and just soldered a short jumper from E10 to lower right S1. This was quite easy since when I made a cable using radioshack's cheaper version I add moved wire from palm 10 to palm 2 (camera 9) and created a custom serial to usb cable so as to not need any further mods to palm cable. The custom serial came in handy earlier when I bent one of the palm springies and needed to create a new cable again using another radioshack palm. Basically inside the palm cables E10 goes to DB9 5 which I then route to USB white. Sorry, way too much background. End result: both Camera 9 and Camera 1 are connected to USB white, which causes camera not to be recognized. Placing a piece of tape over palm 10 (Camera 1) solves that problem. So what does Camera Pin 1 do? Can it help recover fried cameras? 02-28-2005 21:19:36

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) taytrr Profile brite_eye: From an examination of one of the previous camera models (latwer than the origianl but not a Dakota - USB ID: DCA-81A), which has been cable compatible (atleast on the usb side 6-10), pins 1-5 seem to be for serial connectivity (1, 3, & 4 are labeled RS232 on circuit). My interpretation of the circuit leads me to believe that the full pinout is: pin 1 rs232 (unspecified which signal) pin 2 Ground pin 3 rs232 (unspecified which signal) pin 4 rs232 (unspecified which signal) pin 5 +? (missing resistor for connectivity on board but probably +5 when connected) pin 6 +5 Voltage pin 7 Ground pin 8 usb data + pin 9 usb Data - pin 10 Ground My guess is that the circuit will only talk USB or Serial, not both at the same time, and when the pins are shorted the camera doesn't know what to do. I didn't see anyhting indicating that there would be any short outside the cpu as the pins seem to run directly in to the cpu. 03-01-2005 14:16:02

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) binaryweaver Profile Hmmmm... It would most likely be RS232A. If you were going to try interfacing it to a computers serial port, you'd have to use a line driver like a MAX232. Even so, RS232A is 5 volt which would have to be applied externally. Anyone know if there appears to be serial communication code in the firmware? It would be interesting to know what purpose it serves. 03-01-2005 20:32:31

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile Pictures got the blues? I contacted Radio Shack and asked them about posting real Flatfoto 2MP drivers. Here's the info if someone wants to throw cash at the problem. DRIVER CD FOR 16-3831 (Flatfoto 2MP)... Part #:12427258 Cost:$2.49 may be obtained through the Radio Shack order center at 1-800-843-7422. It is not available for on line download or purchase. I'll wait longer to see where Sailpix takes us, as a point of pride, but I thought others might be interested. 03-04-2005 10:14:45

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile My earlier post a few above indicated palm pin 10 camera 1 was creating a problem. I assumed camera 1 because it was directly tied to camera 9 after I soldered jumper from E10 to S1 (if my memory of mulitester result is correct). And then when placing some electrical tape over palm pin 10 caused the camera to connect I again assumed camera 1 was the problem. Well after a few downloads the tape became a problem so I just ripped out palm pin 10. Surprise - it still wasn't connecting. Since the tape had also been over palm pin 9 camera 2, I ripped out that out as well and now I have a working cable! At this point I do not know whether camera 1 was part of the problem - I do know that cable would not work until camera 2 was disconnected. Most of the above makes little or no sense to me - especially since camera 2 is a ground and palm pin 9 is documented as not used for m100 series. Good luck to anyone trying to figure out exactly what each camera pin does. I still hope there might be a magic pin or switch or combination for recovering fried cameras. 03-06-2005 17:30:43

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile Just an FYI, Forkboy has kindly hosted two replacement fonts I provided for the Red cameras. Each font kit patches the LANG-EN.DAT with the new font. They're available at the ever popular http://forkboy.doesntexist.com/ If anybody is interested in the mundane details of converting LANG-EN.DAT to a bitmap and back let me know and I'll post the procedure I used. 03-09-2005 12:04:45

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) sailpix Profile Interesting discovery while trying to figure out multi-segment images... I've been dumping the .RAW header information and noticed: IMG_0024.raw (origin unremembered...)    Firmware Version: 6250    Hardware Version: 06    Hardware Serial: 2B    Imager Type: 05    CMOS Size: 1288 x 864 blue_img_0001.raw (fm. brite_eye)    Firmware Version: 6250    Hardware Version: 06    Hardware Serial: 2F    Imager Type: 08    CMOS Size: 1284 x 864 Both RAW files have the "output image" size set to 1280 x 860. So, perhaps the image processing in the older drivers just doesn't handle the 1284-sample wide CMOS data correctly. If it somewhere assumed the width was the old value of 1288 instead, that shift of pixels might explain why everything turns blue. The Foxz2 TWAIN driver seems to carefully use the image size for decompressing, but I haven't wandered into the post-decomp image processing, where I suspect the blue happens. - sailpix _/) 03-09-2005 22:33:33

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile Been playing around uploading programs to the camera via the $26/$28 USB commands. Neat stuff, but disappointing in one aspect - there appears to be some kind of timed interrrupt that kills whatever program is running after 6 or 7 seconds. To develop long running programs, like a time-lapse photo program, a mod to extend or kill the interrupt will have to be tracked down. Morcheeba, I couldn't find a graceful way of exiting a user program. RTS doesn't cut it, and I have no clue where I could JMP back to. If I understand correctly, the user program actually gets stored in memory that used to store the beginning of the firmware... so there's probably no good way to exit gracefully, right? 03-12-2005 00:37:53

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile For old times sake (things seem to be a bit slow), I just read some of the earlier posts in decompression thread. I miss scribble's and other's analysis of curves which I never fully understood. I am now wondering what role curves may still need to play once sailpix completes decompression. These may be questions he already has answers for - but I still do not believe anyone has demonstrated/proved any details of autobrite processing (whether it is completely imbedded in imager electronics or is also implemented in decompression download processing). I assume many pictures may not need the 120db claim of SMaL - and might even fit well within 8bit bayered images; but for 500 times claim one would need another 9 bits. Perhaps some of the difficulty sailpix is having with my sunnycad is related to higher dynamic range of sun and shadows. Having decompressed bayered DNGs may not help those of us unversed in curve manipulation if such is necessary to obtain images that compare to those downloaded using foxz2 or flatfoto drivers. Separately I wonder how close my direct Sun shots come to 120db range. A suggestion to sailpix - please try your latest decompression code with a direct Sun shot containing glistening water waves along with winded sail (probably best obtained next to boat with all but your head submerged - now that's what I would call a sailpix). 03-28-2005 03:56:42

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) sailpix Profile Hmmm... actually we sailors usually like to stay /out/ of the water. While we get nice weather this time of year, the lake water is still freakin' cold. I'm sailing in a regatta next week, so I'll take the camera along and try for some brite shots - if the weather cooperates. Besides, having a camera which I can risk while sailing was my plan all along. So far I haven't seen any evidence of data range expansion in processing the RAW files - but that's because what I'm tackling is just undoing the compression of Bayer data -> RAW. Once we can decompress anything then I'll start working on how to process that into a good looking image. I suspect that we will find that the data needs a bunch of work still... The Foxz2 TWAIN driver has a large section of image processing that is applied after decompression. I haven't looked into this yet - I'm sorta hoping that we can "develop" the image on it's own. That section of code appears, from a quick glance, to be at least as big and complex as the decompression - I'd rather not dig through that if we can do it some other way. Some of SMaL's image processing _could_ involve some data range expansion, however the .RAW file just decompresses to the Bayer data and a few individual header values - definitely no information for dynamic expansion on a per-pixel or per-row basis. So, any expansions that we figure out will have to be image-wide. I believe that AutoBrite is a hardware-only technology which implements automatic compression within the CMOS image sensor. This compression lets the 8-bit-per-element CMOS image sensor register a wider range of light levels than would be possible without the compression. But, I think the result is still just a straightforward 8-bit per element Bayer array image that includes the results of any hardware AutoBrite compression. In other words, I think the camera uses automatic compression to map an expanded range of light levels to discrete CMOS sensor readings, then everything else is handled like a regular digital camera. - sailpix _/) 03-28-2005 09:35:00

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile I recently had an interesting experiment... I opened the flash memory image in WinImage, and added 26 one-byte-length raw images to /dcim/raw. I then uploaded the image, unplugged, turned on the camera. The picture counter read "255 left", and indeed I could take more than 25 shots. Unfortunately, pv2tool doesn't want to show me all of the pics (It does this most of the time) and the foxz2 driver chokes when it tries to batch download and convert - it's likely getting hung up on the fact that they aren't real raw images. But I thought it was an interesting diversion, and there were some facts I inferred by repeating the experiment differently a few times... 1. Obviously the picture-limit is the asm equivalent of "if(count == max)" instead of "if(count>max)" 2. The dcim/raw tally routine only counts ".raw" images. Other extensions don't affect the picture count. If there was some way of creating a really small null-but-valid raw image, this might be a kludge to bypass the picture limit... but I'll be looking for the more elegant hack in firmware if I get some time this weekend. If anyone tries to duplicate this, it involves reflashing the camera, so the usual cautions apply. Also, use 1-byte RAW files instead of 0-byte length RAW files. The 0-byte ones seem to freak pv2tool out. 04-01-2005 11:52:49

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile Hi Matt, I'm moving the firmware-restoration talk to this thread, so we can avoid cluttering the Links thread. To all, a repost of mconsidine's post in links follows here... BillW : thanks for making your tools available. I was goofing around with them last night on a CVS "red" that is "fried" (i.e. two beeps when it is plugged into a WinXP USB port, but no LCD screen) and managed to get it to download 2.7MB of data a couple of times. Has anyone else had this happen? I don't think these things are nearly as dead as they initially seem... FWIW, I have an original Ritz Dakota that is happily talking to the SUCR software, this CVS "red" and two, still-in-the-box CVS "blue" cameras. Ideally, I'd like to get a mod to these that allow for a long exposure time, as my hobby is astronomy. If in the exploration of the firmware, anyone stumbles across the means by which the exposure length is determined, I'd like to hear about it. Also (for BillW) : a couple of times I've gotten I/O errors relating to what appear to be overlapping communications on the port. Would it be possible to have a "listen" mode to one of your tools, whereby one can send it some data (either from the console or a file) and then it just listens for some defined period of time, writing whatever it hears to a file? Or perhaps the user could define a data sequence to be a "ping" that would be sent to the camera at a certain frequency, during which time the s/f would listen and record? I ask, only after having tried and failed to find some simple source code to compile that would do this. Matt 04-05-2005 15:39:20

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile No problem about the tools Matt - I think we'd all like to see someone take the "firmware restoration" ball and run with it. > I was goofing around with them last night on a CVS "red" > that is "fried" (i.e. two beeps when it is plugged into > a WinXP USB port, but no LCD screen) and managed to get > it to download 2.7MB of data a couple of times. Has anyone > else had this happen? On morcheeba's USB page http://www.maushammer.com/systems/dakotadigital/lcd-usb.html at the $51 command info states that he got it to download ~16K worth of FIRMWARE.BIN (with the first 16 bytes being different than the usual FIRMWARE.BIN). How does your 2.7MB compare to the real FIRMWARE.BIN. (if you don't have a comparison tool, on Windows I use the freeware hex editor from http://www.hhdsoftware.com/ which has a fairly good byte-for-byte comparison feature.) > a couple of times I've gotten I/O errors relating to what > appear to be overlapping communications on the port. Would > it be possible to have a "listen" mode to one of your tools, > whereby one can send it some data (either from the console > or a file) and then it just listens for some defined period > of time, writing whatever it hears to a file? I actually don't have enough knowledge of USB/libusb to answer that with any certainty. Maybe Drmn4ea, who wrote the poker, or possibly Forkboy, who wrote PV2Tool, might be able to answer this better. I do think there errors you're getting are due to the fault-intollerant USB implementation on the camera. If you send it something it's not expecting (or too much of what it's expecting) it hangs the camera and then you get the I/O errors. Generally you have to unplug, reconnect, and reopen the camera to fix them. 04-05-2005 15:40:59

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile Bill >to download ~16K worth of FIRMWARE.BIN (with the first 16 bytes being different than the usual FIRMWARE.BIN). How does >your 2.7MB compare to the real FIRMWARE.BIN. (if you don't have a comparison tool, on Windows I use the freeware hex >editor from I will try to check that this evening, using the hex editor you suggest. On a different note, has anyone experimented with any of the drivers/software available for the Logitech and Creative Labs implementations of the SMaL chipset? Would it be possible to find a firmware uploader for the CPU to make it think that it's another device, and then use that software's capabilities to reload the original firmware for the camera? I'll be the first in line to say that this would be a massive kludge, but you never know... For example, is there an MP3 player with updateable firmware running off the same CPU that could be used? I'm no EE, so apologies if this is manifestly stupid ... Matt 04-06-2005 09:41:19

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile I've rerun the experiment I did the other night with billws tools. When I first plugged in the "dead" CVS-Red, I got the two loud beeps followed by 1 shorter beep. The command sequence with usbpoker was bulk-out: Browse:80_getkey, send bulk-in: wLength=999, send bulk-out: Browse: 80_sendkey, send bulk-out: (second half of previous command) Browse:key_unreset_camera/key_reset_camera, send bulk-in: wLength=999, send bulk-out: Browse:send 52_readlarge.bin, send bulk-in: wLength=9999999, send However, after the first command was entered, I got an IO error (see below). So on a lark I switched all the "bulk" modes to "control" modes, but didn't change any of the fields other than the file used in "Browse". (This may make no difference - I'm just saying what I did). The text that showed up in the log window was Looking at device \.\libusb0-0001--0x8086-0x2484 This device has 1 possible configuration(s). Looking at configuration 0...This configuration has 1 interfaces. Looking at interface 0...This interface has 1 altsettings. Looking at altsetting 0...This altsetting has 1 endpoints. Endpoint 00: Address 81h, attributes 03h (Interrupt) (In) Looking at device \.\libusb0-0003--0x0dca-0x0027 This device has 1 possible configuration(s). Looking at configuration 0...This configuration has 1 interfaces. Looking at interface 0...This interface has 1 altsettings. Looking at altsetting 0...This altsetting has 2 endpoints. Endpoint 00: Address 81h, attributes 02h (Bulk) (In) Endpoint 01: Address 01h, attributes 02h (Bulk) (Out) Opening device: \.\libusb0-0003--0x0dca-0x0027 Opened device. Set configuration 00. Claimed interface 00. Set alternate interface 00. Wrote 31 bytes to bulk endpoint. Read -1 bytes from bulk endpoint. (ERROR!) timeout error reading from bulk endpoint 0x81: win error: Overlapped I/O operation is in progress. Sent/received control transfer of 20 bytes. Sent/received control transfer of 20 bytes. Sent/received control transfer of 20 bytes. Sent/received control transfer of 20 bytes. Sent/received control transfer of 20 bytes. Sent/received control transfer of 20 bytes. Wrote 31 bytes to bulk endpoint. Read 2752511 bytes from bulk endpoint. At one point, the field in wLength changed to 128, for what it's worth. Now I've got a big file in angrRcvd. While I can't do a hex compare yet, it is definitely code/"stuff" of some sort, as the following shows up inside : ÈU:i6123D�عRAW followed by entries such as MENU.TFT, SHUTDOWN.TFT and other names in the filestructure. For what it's worth... Any thoughts/idea would be welcome. 04-06-2005 18:03:57

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile mconsidine, what version of libusb did you download from sourceforge? Looks like you are reading flash directory to obtain .TFT files (I dont think those are normally embedded in firmware). I wonder if control mode is now enabled under a new version of libusb. Did you get a vulcan pinch before you "fried" CVS red? Is it really fried (wont power on or show anything on lcd) or just knackered as in binaryweavers latest blog. 04-06-2005 19:18:17

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile Hi, I've got libusb 0.1.8.0 installed. The definition of "fried" I'm using is won't power on or show anything on the LCD. Originally when this seem to die, I got three low beeps. I started shorting various pins to ground, but don't know what that accomplished. It did seem that shorting to camera pin 1 and the shield of the USB cable got different beeps, but I didn't document this at the time. Last, if I'm reading a voltmeter correctly, I'm getting 3.3 volts out of pin 4 (?). Anyway, in going through the 2.7M download, I see references to another file HIBERNTE.BIN. Anyone with any thoughts? There seem to be a lot of blocks of 0s, as if there are different files in this downloaded block. The entries I see listed are MENU.TFT SHUTDOWN.TFT SPLASH.TFT PD-09.TFT (through PD-02.TFT) LANG-EN.DAT NVRAM.DAT FWCFG.DAT HIBERNTE.BIN FIRMWARE.BIN DCIM NONE 100_MEGA There is also a reference to RAW and RAWJPG Matt 04-06-2005 19:34:53

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile To be clear, the only thing the camera does when I hit the power button is give two beeps. Is this a different version of "fried" than others have? 04-06-2005 19:39:20

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Ignore my comment about firmware not containing TFT names (of course it does). They are all in morcheeba's firmware comments for 6410 27 and in my firmware dumps. Matt, do you know if your CVS red is a 6520 27, 2B, 30? 04-06-2005 19:46:28

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile It's a 6520 27. Not sure about the last two pieces of info. Somewhere I wrote this down, but d*mned if I can find it at the moment... Matt 04-06-2005 20:00:25

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile Found the info I jotted down on my camera before getting it into it's current state. Data from the info screen was 6520 6 27 27 DA5043203283 Identification on ASIC reads : SMaL AIC0021B C2TWN1504 CM7859.00 Camera was bought in the Philadelphia area about 2 weeks ago. 04-07-2005 06:32:03

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile mconsidine, your camera sounds fried just like everybody else's fried cameras. My 2 dead ones respond exactly the same way you describe. The 3.3 volts on pin 4 is normal. Pin 4 is connected directly to one of the battery terminals. Check out the "recharge hacks" thread for more info. Is your 52_readlarge hacked to use the $51 usb command, or is it the stock 52_readlarge I sent you??? If it's the stock version, you somehow got your "dead" camera to use an unfried camera command!!! BTW, it's normal that 52_readlarge doesn't return 100% of the firmware - you normally need to use multiple $52 read commands to retrieve flash 1 sector at a time. Forkboy's pv2tool automates this for us. Even on an unfried camera, the 52_readlarge (with usbpoker) only returns a portion of the flash. 04-07-2005 10:33:11

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile Bill, The stock "52_readlarge" that you sent me is what was used. I'll try to approach this in some way that other's can duplicate. One thing I do recall is having libusb 0.1.10 installed first, then uninstalling it and reinstalling libusb 0.1.8 But other than touching various pins to ground and each other (ya, I got sparks!), that's the only thing different about what I've done : -Irfanview + Che-ez drivers tell me it's in bootloader mode -PVTool 2.06 comes back with read errors I'm thinking of installing Creative Labs "Card Cam", Oregon Sci., and Logitech drivers to see what else happens. 04-07-2005 10:51:31

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) billw Profile mconsidine, false alarm. Reading through morcheeba's usb docs, it seems that $52 reads work on dead cameras, but $52 writes error out. If you're looking for experimenting, $52 writes are the way to go. 04-07-2005 11:45:40

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile Bill, Thanks. Has anyone else noticed, by the way, the HIBERNTE.BIN reference in their directory structures? Is this a hidden file or did I overlook it somehow the first time? Matt 04-07-2005 12:17:37

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) sailpix Profile From my investigations, the OSI and Logitech drivers are older than Che-ez Foxz2 which is older than the FlatFoto2 driver. You could try them, but... I haven't tried the Creative drivers since they are packaged differently (i.e. not InstallShield) and I can't get to the drivers without going through an actual installation. When I look at a file I usually open it up in a hex editor and search for "libsmal". In the more recent drivers/apps you will find versions for libsmalraw, libsmalprocess, libsmalconfig, libsmalimg, etc. + versions for 3rd party components they use (like zlib or wxWindows). If someone digs the libsmalraw and libsmalprocess versions out of the Creative Labs drivers I'm interested. - sailpix _/) 04-07-2005 12:43:24

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Just thinking out load about some of above - What if one uploaded a FIRMWARZ.BIN to FLASH using winimage and PV2Tool? Would there be any way to write over live firmware constant of FIRMWARE.BIN changing E to Z and then trigger a reload? This could provide a secure testing mechanism since powering down and back up would restore original FIRMWARE. You might not need to trigger reload - if functions are swapped in and out of FLASH as I suspect. Even if that works, we would still need a way to disconnect camera without it powering off. Any ability to modify firmware without risk of a fry is well worth a try. 04-07-2005 16:41:01

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) mconsidine Profile If you could step me through what you're thinking, I'll give it a shot. What's winimage? BTW, you still get beeps from the unit if you hook it up to the PC and take the batteries out, I believe. 04-07-2005 17:46:52

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 1 times) billw Profile mconsidine, what brite_eye is proposing is a method of immunizing cameras with good firmware against bad firmware uploads. It's not a method to restore bad flash/firmware. Winimage is software for modifying .iso images. Some of us use it to update the flash memory image we get from the camera. With it, you can add/modify/remove files from the image. brite_eye, I don't think what you're proposing is possible, at least, not as you proposed it. The usual firmware bootstrap as I understand it is... 1. Camera initially runs bootloader, probably from on-ASIC memory. 2. Bootloader accesses the firmware from flash and loads it into SDRAM. 3. Bootloader loads first bit of firmware into SRAM. Probably via an SDRAM->SRAM transfer. 4. Bootloader toggles some hardware flag that changes the cpu from looking at ASIC-Memory to SRAM. This is why morcheeba couldn't find a copy of the bootloader in adressable memory. (his conclusion, not mine) 5. When the firmware needs another bit of itself (SRAM is only 64k large) it loads it in via a SDRAM->SRAM transfers. To affect firmware, you'd have to execute a program that loads FIRMWARZ.BIN a little piece at a time, and does SRAM->SDRAM transfers overtop of the SDRAM memory that stores FIRMWARE.BIN. And yes, you'd somehow have to disable the USB plugin/out reset - you might get lucky and find it's an interrupt that can be disabled. All of this is pretty non-trivial though. I'm not ready to take it on, from both technical and free-time perspectives. 04-07-2005 19:21:49

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) brite_eye Profile Non-trivial! Probably, But there are several references to "FIRMWARE.BIN" string in 6410 disassembly. If changes were kept on same boundaries, the software may just overlay itself with "Z" version as different pieces are swapped in and out. Another thought for flatfoto with SD card is to load alternate FIRMWARE.BIN on removable flash and somehow point to it instead. I'd really like a way to test major changes to firmware without risking a permanent fry. 04-07-2005 19:40:55

RE:Bits Bytes & Beyond - 1 10 many 100 all (modified 0 times) kiram Profile Could we move the bootloader discussion to another thread? I would like to see more about it because i think its really important and could be really useful to get working. then we could completly fry the camera and reflash it back to health to start making our entirely own firmware (with lotsa more features) 04-08-2005 15:30:25

Reply to Thread | Printer | All times are PST Powered by UltraBoard v1.62

I-Appliance BBS General - NEWS, Breaking NEWS - linux-hacker.net BBS on CD Questions - User Groups in Your Town - E-Bay, Yahoo Auction LINKS ONLY (MODERATED) - Jokes & Humor - usdtv box I-Opener Areas - I-Opener General Posts - I-Opener Technical Stuff - I-Opener Technical Info Reference (MODERATED) WebSurfer Areas - WebSurfer General Posts - WebSurfer Technical Stuff - WebSurfer Technical Info Reference (MODERATED) Other I-Appliances - Virgin Webplayer - WebPal - MailStation - 3Com Audrey - ThinkNIC / Oracle NIC - Gateway/AOL Connected Touch Pad - Philips/AOL-TV - ACER NT-150 STB - MSN Companion - Compaq IA - Emachines IA - IBM NetVista IA - Intel dot.station - MSNTV2 Network Computers - Fujitsu-Siemens Scovery Linux Net Computers - GallantWeb Server Consoles - Dreamcast - xbox hacking Web Pads - Epods One General Post - Panasonic CF-01 - Fujitsu Stylistic 1200 - Cybiko Thin Clients - Thin Clients DigitalVideoRecorders - DTV Recorders, Replay, TiVo, Etc... - Tivo Hacks Linux - Midori Linux General Board - ITX MotherBoards Single Board Computers - Earth Computers mARMalade Elite Member Area MISC Areas - The Swap Meet WE TAKE NO RESPONSIBILITY FOR ANY TRANSACTION HERE AND NO COMMERCIAL POST PERIOD !!! - Wireless Net - Cameras - Robotics - Routers/Gateways - Mattel JuiceBox