Talk:Phackv1.4
From Picframe
Contents |
More ideas
[Michu] I guess this would be a nice feature: when i connect the USB cable to the device, it enters automatically the upload modus. else this step needs to be done manually each time i connect the device...
With my fw, I can hardwire the middle button to always-on for the same effect. Perhaps it works on yours too. -Sprite tm
[Luca] My device (the dealextreme one) can be powered either by aaa batteries or by usb alone. In neither mode keeping any of the 3 buttons pushed automatically enters upload mode.
When I plug the usb cable (without batteries):
- Powers on
- Shows "Photo viewer" on a blue background
- Transitions to the first photo
- Shows the menu "USB Charge"/"USB Update"
- If you don't select any option, after a while it goes to photo mode
I'd prefer to go straight to "USB Update" (i.e. upload mode)
Backlight
[Michu] I just saw, that you use gpio port 3 to turn the backlight on or off:
;Command 2: turn backlight on blon lda $03 and #($ff-$04) sta $03 bra packetend ;Command 3: turn backlight off bloff lda $03 ora #$04 sta $03 bra packetend
according to the doc, there are 56 gpio ports available... how did you find out, that its port 3? maybe this value should be "outsourced" to the spec file?
Coby DP-151
Using setpic, test image is displayed twice at quarter-size, in top-left and top-right quadrants of screen. Whatever was on the screen to begin with remains on the bottom half of the screen. The black background in the test image is displayed properly, but the blue text is displayed in green. Unlike last version, Coby remains connected to PC and responsive after setpic is run. --r0tw4ng
- Ahrg, and I told myself to make sure I changed that :X Simple oversight, please re-download and flash and it should work. --Sprite tm
- Fantastic! Images are now displayed properly on the Coby!. --r0tw4ng
Using setpic's backlight on/off switches don't seem to do anything to the Coby - setpic displays the line where it recognizes the device, but nothing happens on the LCD. --r0tw4ng
Works great :) Screen draw time appears noticably faster.
In the hackfw.sh I think -z "$1" should be -z "$2"
The Coby DP-151SX is now on PCB revision 7 (at least) which is incompatible with the default spec (V5?). Distinguishing external packaging characteristics (vs V5) are: The OS support line on the back is "Windows 2000/XP Or Newer" (it is shorter than the File Format line). Barcode: 7 16829 61151 7 Here's the new spec for V7: CMP_VAR1=$0389 CMP_VAR2=$038a PATCH_AT=$2f4d EMPTY_AT=$3b60 SEND_CSW=$2e15 LEN0=$37b LEN1=$37c LEN2=$37d LEN3=$37e CONF_XRES=128 CONF_YRES=128 CONF_BPP=16 CONF_PROTO=0
CTRTYPE=0 ;PCF8833 OFFX=4 OFFY=4 Can someone point me to where I could upload my hacked firmware folder?
Moved some discussion to new page Button Reading.
Syaik -- Issue connecting to device in Ubuntu 8.04
I'm having some trouble connecting to my DP-151SX in order to back up and patch the firmware before running phack. I still have some wiki reading to do, but was hoping someone could get me going in the right direction. I receive the following error message:
No photoframe found there. Sorry, there doesn't seem to be a device using the ST2205U chipset at /dev/sdg
dmesg output:
[60850.763946] scsi 6:0:0:0: Direct-Access SITRONIX MULTIMEDIA 0.09 PQ: 0 ANSI: 0 CCS [60850.768924] sd 6:0:0:0: [sdg] 4096 512-byte hardware sectors (2 MB) [60850.771914] sd 6:0:0:0: [sdg] Write Protect is off [60850.771916] sd 6:0:0:0: [sdg] Mode Sense: 0b 00 00 08 [60850.771917] sd 6:0:0:0: [sdg] Assuming drive cache: write through [60850.780921] sd 6:0:0:0: [sdg] 4096 512-byte hardware sectors (2 MB) [60850.783915] sd 6:0:0:0: [sdg] Write Protect is off [60850.783918] sd 6:0:0:0: [sdg] Mode Sense: 0b 00 00 08 [60850.783919] sd 6:0:0:0: [sdg] Assuming drive cache: write through [60850.783922] sdg: unknown partition table [60850.812922] sd 6:0:0:0: [sdg] Attached SCSI removable disk [60850.812958] sd 6:0:0:0: Attached scsi generic sg8 type 0
I'm suspicious of the "unknown partition table" message -- is this normal? -> yes it is
ODYS Pocket Frame
I bought a device at the German electronics supplier CONRAD with the name "ODYS - Pocket Frame". It seems to have the same chipset. I already managed to modify the specs file to my own needs, but there are two problems:
- There is not enough space left in the first segment (fwimage-seg0.bin). So I looked at the second segment (fwimage-seg1.bin) and located some free FF-space there. So the adress is something like "EMPTY_AT=$73d3". After going through the whole procedure hackfw.sh recognizes the device and updates the firmware. Thankfully the device is not bricked and still works as advertised under windows.
- However: When I try "setpic /dev/sda testpic.png" it gives me a SEGFAULT.
Are those two issues related? Any ideas --allesblinkt
- Sorry, jumping segments isn't possible yet; all code has to be in segment 0. At the moment, you only need 220 bytes of free space for the hack (yes, i know the textfile exaggerates stuff by talking about 512 bytes): there's not even that tiny an amount free?
- No, I guess not. I found like 70bytes of FF. I can upload the binary dumps and the specs file when I get back from work.
- Ok, here is the firmware and the spec files: <snip> . Btw. thanks for this great hacking effort. --allesblinkt
- I olso had this segfaut trying to do setpic on my pixika (the hacked fw was not loaded) --Ben
--
NB: will get a segfault if hackfw fails and get_parm_block returns NULL. Try adding the following to libst2205/main.c:
b=get_parm_block(r->fd,r->buff);
if (b == NULL)
{
printf("Can't find param block\n");
close(r->fd);
free_aligned(r->buff, BUFF_SIZE);
free(r);
return(0);
}
Development platform
What are you guys using for a development platform? I use DSL as my main linux distro, but do to its usefulness as a all around standard use distro, it has failed me for developing this (Too many packages needed and won't install). I have gone to use a Knoppix 3.4 live cd for now, but was wondering what you guys are using. cde
- Debian here, but I guess any mainstream distro (Ubuntu, Fedora) would work just as good. -Sprite tm
When I try to install under debian, this happens:
debian:/home/ty/Desktop/st2205tool# ./configure bash: ./configure: No such file or directory debian:/home/ty/Desktop/st2205tool# make make -C libst2205 make[1]: Entering directory `/home/ty/Desktop/st2205tool/libst2205' cc -c -o main.o main.c make[1]: cc: Command not found make[1]: *** [main.o] Error 127 make[1]: Leaving directory `/home/ty/Desktop/st2205tool/libst2205' make: *** [libst2205/libst2205.so] Error 2] debian:/home/ty/Desktop/st2205tool# make install make -C libst2205 make[1]: Entering directory `/home/ty/Desktop/st2205tool/libst2205' cc -c -o main.o main.c make[1]: cc: Command not found make[1]: *** [main.o] Error 127 make[1]: Leaving directory `/home/ty/Desktop/st2205tool/libst2205' make: *** [libst2205/libst2205.so] Error 2
I'm new to linux but know how to install packages and use bash what am I doing wrong? I also have libgd2.0 & development headers installed - ty_j
- ty_j - It looks like you do not have a C compiler (cc), or the configure program installed. Try installing the build-essential package. This contains a bunch of stuff that you'll certainly want in a development environment. -- Syaik
Ebuyer model
I now have the test image picture-perfect on the ebuyer model, however I had to put together a strange sequence of operations to achieve this. If you send a short first image, the subsequent image displays correctly. The first image must be exactly 3857 bytes long before being encoded. Other values result in it being shifted around by varying amounts. The code here: http://sitronix-dpf.svn.sourceforge.net/viewvc/sitronix-dpf/trunk/windows/ displays the test image correctly. --Bifferos 23:41, 27 January 2008 (CET)
Current 1.4pre doesn't work on arm-linux targets (seg faults) due to a bug in libst2205. For compiling on arm-linux a change in /libst2205/main.c is necessary, change line 172 from
if (offset==0) return;
to
if (offset==0) return(0);.
--Dr.unken 17:45, 1 February 2008 (CET)
- For what it's worth I have added this to the sourceforge SVN. --Bifferos 18:13, 2 February 2008 (CET)
Unknown LCD frame profile
I received a LCD photo frame for Christmas from a friend. It is a model with a 128x128 screen, but also has a smaller black and white LCD below the color one that displays the time and temperature. A similar one can be found here: http://www.dealextreme.com/details.dx/sku.5806
I followed the newhack instructions and created a new profile for the device, and I was just wondering where I could send it for it to be included. I also have fw and memory dumps to send if it will help anyone. Right now it is happily serving as my server status display on my desk :)
Let me know here if it would be helpful for me to provide any of the above, and let me know where to send it.
Thanks, Jordan
- Jordan, send me a message with your sourceforge account name if you want to be given SVN access --Bifferos 10:02, 20 February 2008 (CET)
~ This is also sold at Circuit City as the Royal Travel Clock / Digital Photo Frame Model #: ROY PF141. As most of these things are the same.
Tom-Tec 3 button device with datecode 200712
This is also a 128x128 px device.
After creating a new hack the device shows the pictures, but only with V1.4.
The hack can be found here
Original firmware here.
Images:Front Back
Using ./setpic /dev/sdx -upload picture.png does show the picture, but the console freezes for one or two minutes.
Dmesg shows this:
[13189.096000] scsi 8:0:0:0: Direct-Access SITRONIX MULTIMEDIA 0.09 PQ: 0 ANSI: 0 CCS
[13189.116000] sd 8:0:0:0: [sdc] 4096 512-byte hardware sectors (2 MB)
[13189.124000] sd 8:0:0:0: [sdc] Write Protect is off
[13189.124000] sd 8:0:0:0: [sdc] Mode Sense: 0b 00 00 08
[13189.124000] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[13189.144000] sd 8:0:0:0: [sdc] 4096 512-byte hardware sectors (2 MB)
[13189.152000] sd 8:0:0:0: [sdc] Write Protect is off
[13189.152000] sd 8:0:0:0: [sdc] Mode Sense: 0b 00 00 08
[13189.152000] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[13189.152000] sdc: unknown partition table
[13189.196000] sd 8:0:0:0: [sdc] Attached SCSI removable disk
[13189.196000] sd 8:0:0:0: Attached scsi generic sg2 type 0
[14651.900000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14682.300000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14712.692000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14743.080000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14748.276000] usb 5-1: device descriptor read/all, error -110
[14748.452000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14778.840000] usb 5-1: reset full speed USB device using ohci_hcd and address 8
[14809.436000] sd 8:0:0:0: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
[14809.436000] end_request: I/O error, dev sdc, sector 34
The first lines are after attaching the device, the last lines are after submitting a picture.
I think this system try's to access the device as mass-storage, but fails.
Unfortunately you can't show multiple pictures without waiting about 2 minutes between each picture.
Lcdforlinux only shows a black screen, dmesg shows a lot of these:
[24676.836000] scsi 13:0:0:0: rejecting I/O to dead device
bugs
Hi! There are some bugs I've found while playing with coby dp151 frame on 64-bit gentoo system:
1) The -fPIC doesn't seems to be passed to main.c compilation in libst2205 directory. Thus typing make in root dir fails. compiling first main.c whit -fPIC and then typing make works.
2) In hackfw.sh on line 42 should be $2 instead of $1
3) setpic binary segfaults in st2205_open()
The problem is on line 160 in "return (fw_descriptor*)((int)buff+a);" when the cast to int is removed and you get "return (fw_descriptor*)(buff+a);" it suddenly works.
4) Despite coby frame has offy set to 4, my red coby frame works with offy 0.
5) I also suggest change in Makefile to build libraries with libtool and I can provide patch for it.
And also I got messages that there is no compatible st2205 device when simply I don't have rights to open /dev/sdX, that's quite confusing.
New Device and Subpixel Rendering
I have a Nextar N1-506 (heart shape) I got from woot.com that did not work with the supplied hacks. After some debugging, I found it was similar to the m_nextg hack, but off by 5 bytes in some places. Here is the working hack for this device:
http://www.ccs.neu.edu/home/bchafy/n1_506_newhack.tgz
I am also experimenting with subpixel rendering on these tiny screens. I have written a renderer in C that can render at 2x or 3x horizontal resolution. I can get readable text at 48x15, and unreadable (but accurate to the subpixel) text at 96x25 using the most tiny 3x4 font that renders down to 1x3. You need a magnifying glass and good eyes to see it (or hack up a projector from the LCD panel.. 96x25 on a 1.5" screen is too small, but at least proves the concept works.. It also works with images and some limited color support. Here are some test PNG files:
http://www.ccs.neu.edu/home/bchafy/subpixel_png.tgz
I will post the renderer shortly, there's still some work to do.
I've also updated the newhack.txt file. A 68c02 is much different than a 65c02. That caused me some grief at first :P ..
Bryan (bchafy at ccs dot neu dot edu)
