LCD screen for your dockstar (cheap! <$5)

That looks like the packaging of the Innovage Generic I have (yup I've got one as well :-) Mine was so old that the battery couldn't hold a charge and I had to write it up a different battery so I could flash it.

-PG

psk Wrote:
-------------------------------------------------------
> i almost swear that's the right packaging, but i
> don't remember it being that big... like i said
> though, it was a gift many years ago.. and yes, i
> did luck out, i've been holding on to this thing
> for what seems like forever (in my hacks/projects
> drawer) thanks to all you guys it finally has a
> use :D

The best part of being an electronics packrat. Having that one thing you (annoyingly) kept through several moves only to find the most perfect use for it. ;)

petergunn Wrote:
-------------------------------------------------------
> That looks like the packaging of the Innovage
> Generic I have (yup I've got one as well :-) Mine
> was so old that the battery couldn't hold a charge
> and I had to write it up a different battery so I
> could flash it.

That seems to answer that. I'm curious though, that means you have a(n unhackable) DP151, the DP152 you have in your pics and an Innovage Generic which is SUPPOSED to be identical to the Shift3 as far as parts go. Any real differences to how the screens look to you? The DP151 I have here has a kind of gloss/overlit effect that is indicative of cheaper LCDs. Reminds me a lot of the older Candybar Nokia cellphones that were among the first to have color screens... Not something I see with the Shift3 I have. (Refresh sucks but it's a lot more crisp) Main reason I'm looking at the Innovage Generic there as I prefer the screen in my Shift3. Can you confirm if the screens on your DP151 and Innovage Generic are the same?

rat Wrote:
-------------------------------------------------------
> From apcupsd.status line 12:
> LOADPCT : 14.0 Percent Load Capacity
> ...
> Wish I had a way to help rather than making more
> work for you. ;)

Why not create a patch? Its not hard (really :-)

To add a 'built-in' statistic called "ups" you would modify stats.c ...

char *builtin_statistic(char *name,int name_len)
{
    switch (*name)
    {
        case 'u': /* 'u' is first letter of "ups" */
        {
            if (name_len==3 && strncmp(name,"ups",3)==0) /* check statistics name matches "ups" */
            {
                /* this is where the code goes to read in the statistic */

                FILE *f=fopen("/var/log/apcupsd.status","r");
                if (f)
                {
                    static char value[64]; /* some space to hold the value we're going to read */
                    char char line[4096]; /* some space to hold each line of the file we read */
                    /* read to the 12th line... */
                    int i;
                    for (i=1;i<12;i++) fgets(line,sizeof(line),f);
                    fclose(f);
                    /* extract the statistic from starting column 12 and null terminate */
                    strncpy(value,line+12,4); value[4]=0;
                    return value;
                }
            }
        }
        break;
...

Disclaimer: I haven't tried any of this and I don't have a UPS :-)

Then recompile, add $ups somewhere in your template.txt, and run stats -t=./template.txt (no need to run st2205term). Then fiddle until it works and send me a patch :-)

You can also try running "./stats -t=./template.txt -v > /dev/null". This starts stats in verbose mode and shows all the statistics that are available (with the specified dstat arguments).

-PG

peter - been a busy end of year, and i just got a chance to install this. not pretty, but it works great! i need to play around with dstat to get a better idea of what this thing can do, but it definitely works.

thanks!

After reading this I am really exited, but as always you cant get the cool stuff in the EU -.-
On page 1 someone mentioned a unit from DealExtreme - but in their comments someone said it isnt hackable anymore ...
Anyone know a solution for such a product to get in the EU (mainly germany) but also from DealExtreme or Ebay or other ways from China (I mean for 4€ I could take the risk of not getting the thing ;) ).

Hello Petergunn and thanks for your generate-hack.pl script!

I got a keypix picframe with USB Ven:Id=1403:0001.

At this point, i (nearly) managed to create a hack for this device. At some points, the .pl script got stuck, but following its code line by line with newhack.txt next to it, it gave me the needed hints.

But there are a couple of questions and the test image is not shown properly.

(Please note that i've never done anything with perl or assember before, so i might have done mistakes and/or the information given below is simply wrong..)

I'm using

• st2205tool-1.4.3.tar.gz (28.1.2009 from Neophob Blog)
• cc65 SvnRev 4895 (Last Changed Date: 2010-12-30 20:35:10 +0100)
• libgd2-xpm-dev 2.0.36~rc1~dfsg-5 (debian package)
• crasm 1.4-2 (debian package)

The hack m_keypix provided in st2205tool-1.4.3 did not work, so i tied the script.

My Questions:
Regarding the generate-hack.pl script (Last edit at 11/25/2010 07:38AM by petergunn)

a) I think there is a bug in line 75:

system "dd if=fwimage-seg0.bin of=lookforme.bin bs=1 skip=$x count=12; done";

should be

system "dd if=fwimage-seg0.bin of=lookforme.bin bs=1 skip=$x count=12";

b) The point, where LEN0,LEN1,LEN2,LEN3 are determined:
The searched sequence is found multiple times. The script echoes, that it uses the first occurrence after SEND_CSW location. Is this always right? Here are the disassembled blocks from

../../../cc65/src/da65/da65 -S 0x4000 --cpu 65C02 fwimage-seg0.bin | less

The first one, the script uses this adresses: LEN0=$36c, LEN1=$36d, LEN2=$36e, LEN3=$36f

L6B2B:  lda     $0213
        sta     $037B
        lda     $0214
        sta     $037A
        stz     $036E
        stz     $036F
        lda     $0216
        stz     $036E
        lda     $0217
        sta     $036D
        asl     $036D
        rol     $036E
        rol     $036F

The second occurence: LEN0=$370, LEN1=$371, LEN2=$372, LEN3=$373

L6BA5:  lda     $0214
        sta     $B3
        lda     $0213
        sta     $B4
        stz     $0372
        stz     $0373
        lda     $0216
        stz     $0372
        lda     $0217
        sta     $0371
        asl     $0371
        rol     $0372
        rol     $0373

which finally leads me to question b) :-)
Which addresses should i choose in case of multiple occurrences of the asl, rol, rol block?
The first one, which is chosen by the script?
(I am unsure, because the second one is more simmilar to newhack.txt)

c) CTRTYPE canot be determined. None of the searched sequences are in fwimage-seg0.bin, but

../../../cc65/src/da65/da65 -S 0x4000 --cpu 65C02 fwimage-seg1.bin | less

shows me this:

L430C:  lda     $95
        and     #$F0
        cmp     #$70
        beq     L435B
        lda     #$F4
        sta     $8000
        lda     $0333
        sta     $8000
        lda     #$F6
        sta     $8000
        lda     $0335
        sta     $8000
        lda     #$F5
        sta     $8000
        lda     $032E
        sta     $8000
        lda     #$F7
        sta     $8000
        lda     $0330
        sta     $8000

so CTRTYPE must be 1, right?
At this point, i hardcoded the CTRTYPE=1 in generate-hack.pl to go on.


d) At the beginning, i said i got it nearly working.. So when using setpic, the previous picture is shown and some rows at the bottom are black. So it seems that the picture data is written to the wrong position? (I think OFFX, OFFY in the spec file are supposed to contain some little values? (If the black stipe at the bottom is the test image, then the values would be somewhere about 10000))


General Information for people who bought a picframe and can't wait to start with st2205tool:
If the frame only activates with usb connection is present, then choose charge and be patient. (approx. 1hour++.)
Reference: I charged for ~15-30min and after ~1hour of use in update mode, it switched off and seemed to be dead! Nothing with or without usb. After a couple of hours (disconnected from usb) it worked again. So i charged for a couple of hours before moving any further with the hack.
I'm not sure if it was the empty battery, which caused it, but i think it can't be wrong to charge the battery..

Quote
Hades
[...] as always you cant get the cool stuff in the EU -.- [...] in the EU (mainly germany) [...]

Hi Hades, i got mine from ebay.de.
I searched for 'keypix'.
From time to time, there is one available from private sellers...

rgtaa Wrote:
-------------------------------------------------------
>
> What is the way to get this program to start on
> start up?
>

I got my DP152 to start lcd4linux at boot or when hot plugged using udev.

create /etc/udev/rules.d/50-udev.rules

in 50-udev.rules is one line:

SUBSYSTEMS=="scsi", ATTRS{vendor}=="SITRONIX", SYMLINK+="DP152", RUN+="/root/lcd4linux-0.11.0-SVN/lcd4linux -F -f /root/lcd4linux-0.11.0-SVN/lcd4linux.conf.2"

The SUBSYSTEMS=="scsi", and ATTRS{vendor}=="SITRONIX", match the device.

SYMLINK+="DP152", creates /dev/DP152 no matter if it is /dev/sda or /dev/sdb or...

RUN+="/root/lcd4linux-0.11.0-SVN/lcd4linux -F -f /root/lcd4linux-0.11.0-SVN/lcd4linux.conf.2" starts lcd4linux with the config of your choice

In your lcd4linux.conf, change the port:

Display st2205u {
Driver 'st2205'
Port '/dev/DP152'

HTH, Jim

vevoto Wrote:
-------------------------------------------------------
> Hello Petergunn and thanks for your
> generate-hack.pl script!

:-)

> a) I think there is a bug in line 75:
> system "dd if=fwimage-seg0.bin of=lookforme.bin
> bs=1 skip=$x count=12; done";
> should be
> system "dd if=fwimage-seg0.bin of=lookforme.bin
> bs=1 skip=$x count=12";

Yes, this is a bug but it shouldn't stop the script creating a suitable hack

> b) The point, where LEN0,LEN1,LEN2,LEN3 are
> determined:
> The searched sequence is found multiple times. The
> script echoes, that it uses the first occurrence
> after SEND_CSW location. Is this always right?

Not sure - the code is so similar the only sure way to tell would be to
look at the code that calls it. I always went with the first location and
that worked for me. If it doesn't work then try the other one :-)

> c) CTRTYPE canot be determined. None of the
> searched sequences are in fwimage-seg0.bin, but
> ../../../cc65/src/da65/da65 -S 0x4000 --cpu 65C02
> fwimage-seg1.bin | less
> shows me this:
...
> so CTRTYPE must be 1, right?

Certainly looks like it. All my devices are CTRTYPE=0 so the
detection code for type 1 has not really been tested. It wasnt
clear from newhack.txt if there could/would be extra lines in between
the "lda" and "sta $8000" lines - I assumed there wouldn't be which
is why the detection failed.

> d) At the beginning, i said i got it nearly
> working.. So when using setpic, the previous
> picture is shown and some rows at the bottom are
> black. So it seems that the picture data is
> written to the wrong position? (I think OFFX, OFFY
> in the spec file are supposed to contain some
> little values? (If the black stipe at the bottom
> is the test image, then the values would be
> somewhere about 10000))

OFFX and OFFY are normally either 0 or 4. They
certainly shouldn't be higher than ~10.

It sounds like you're almost there. Can you give more detail
(or post a pic) of what the output looks like?

-PG

My conversion is complete and works a treat!

http://forum.doozan.com/read.php?2,2435,3156#msg-3156



Edited 1 time(s). Last edit at 01/05/2011 06:31PM by j10152.

Quote
petergunn
> a) bug/ dd / line 75
Yes, this is a bug but it shouldn't stop the script creating a suitable hack

Yes, the script went on, but i saw the error on the console and did not know if something was going wrong..

Quote
petergunn
> b) The point, where LEN0,LEN1,LEN2,LEN3 are determined. The searched sequence is found multiple times.
Not sure [...] If it doesn't work then try the other one :-)

Oh no.. i tried the second one.. more about it later..
short: Same result regarding the displayed test picture (compared to the other addresses of Len0-3) but additionally the whole device freezes!

Quote
petergunn
> so CTRTYPE must be 1, right?
Certainly looks like it. All my devices are CTRTYPE=0 so the detection code for type 1 has not really been tested.

Ok, i just wanted to be sure. I am very impressed how you managed to put these regex together and that it works for most parts.. for me this is (nearly) a write-only language..

Quote
petergunn
> d) Values of OFFX, OFFY
OFFX and OFFY are normally either 0 or 4. They certainly shouldn't be higher than ~10.

Thats what i thought. Ok.

Quote
petergunn
It sounds like you're almost there. Can you give more detail (or post a pic) of what the output looks like?

Today, i flashed the backup of the original fw, compiled the hack with the other addresses (see b)) and flashed that.

The result is shown in the attached image. The black stripe at the bottom seems to be the beginning of the testimage.
But there is a problem: The picframe hangs. regardless of the usb connected or not, i cannot switch the device off, get to the menu or change the picture. It is not responsive while showing the broken picture.

Maybe it helps, when i describe what happened:
While running hackfw.sh,

• the display showed the Text "yay x" (x=some smiley) and
• after typing 'yes' to proceed, it showed "eeek" for a short time and
• then switched to a black display.
• I disconnected the usb connection, waited for the reboot and plugged the usb back in and chose update mode.
• /var/log/messages showed the usual messages and detected the mass storage.
• i pressed enter and the flash script sent the testpic to the frame.
• freeze

Below an excerpt from /var/log/messages:

Normal behavior before flashing:

Jan  7 12:14:38 xps kernel: [42508.113664] usb 2-3.4: new full speed USB device using ehci_hcd and address 11
Jan  6 12:14:39 xps kernel: [42508.208922] usb 2-3.4: New USB device found, idVendor=1403, idProduct=0001
Jan  6 12:14:39 xps kernel: [42508.208931] usb 2-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jan  6 12:14:39 xps kernel: [42508.208938] usb 2-3.4: Product: Flash Disk      
Jan  6 12:14:39 xps kernel: [42508.208943] usb 2-3.4: Manufacturer: USB     
Jan  6 12:14:39 xps kernel: [42508.209178] usb 2-3.4: configuration #1 chosen from 1 choice
Jan  6 12:14:39 xps kernel: [42508.210416] scsi6 : SCSI emulation for USB Mass Storage devices
Jan  6 12:14:44 xps kernel: [42513.210827] scsi 6:0:0:0: Direct-Access     SITRONIX MULTIMEDIA       0.09 PQ: 0 ANSI: 0 CCS
Jan  6 12:14:44 xps kernel: [42513.212028] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jan  6 12:14:44 xps kernel: [42513.213895] sd 6:0:0:0: [sdb] 4096 512-byte logical blocks: (2.09 MB/2.00 MiB)
Jan  6 12:14:44 xps kernel: [42513.214501] sd 6:0:0:0: [sdb] Write Protect is off
Jan  6 12:14:44 xps kernel: [42513.216384]  sdb: unknown partition table
Jan  6 12:14:44 xps kernel: [42513.252030] sd 6:0:0:0: [sdb] Attached SCSI removable disk

Somewhere around here i started to flash

Jan  6 12:15:22 xps kernel: [42552.064453] usb 2-3.4: reset full speed USB device using ehci_hcd and address 11
Jan  6 12:15:53 xps kernel: [42582.488433] usb 2-3.4: reset full speed USB device using ehci_hcd and address 11
Jan  6 12:16:23 xps kernel: [42612.916412] usb 2-3.4: reset full speed USB device using ehci_hcd and address 11
Jan  6 12:16:34 xps kernel: [42623.233579] usb 2-3.4: reset full speed USB device using ehci_hcd and address 11
Jan  6 12:16:44 xps kernel: [42633.477722] sd 6:0:0:0: Device offlined - not ready after error recovery
Jan  6 12:16:44 xps kernel: [42633.477742] sd 6:0:0:0: [sdb] Unhandled error code
Jan  6 12:16:44 xps kernel: [42633.477748] sd 6:0:0:0: [sdb] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
Jan  6 12:16:44 xps kernel: [42633.477756] sd 6:0:0:0: [sdb] CDB: Write(10): 2a 00 00 00 00 22 00 00 43 00

Now this seems to be the disconnect after flashing (when the display shows the black screen and the flash script prompts to dis- and reconnect)

Jan  6 12:16:44 xps kernel: [42633.481276] usb 2-3.4: USB disconnect, address 11
Jan  6 12:16:44 xps kernel: [42633.565659] usb 2-3.4: new full speed USB device using ehci_hcd and address 12
Jan  6 12:17:14 xps kernel: [42663.992430] usb 2-3.4: new full speed USB device using ehci_hcd and address 13
Jan  6 12:17:45 xps kernel: [42694.208396] usb 2-3.4: new full speed USB device using ehci_hcd and address 14
Jan  6 12:17:55 xps kernel: [42704.524568] usb 2-3.4: new full speed USB device using ehci_hcd and address 15

...and so on. when i keep the device connected to the usb, there are more messages like the last 4 (with increasing address)

In conclusion: With both addresses for LEN0-3 the picture looks like in the attached photograph. The second one freezes the device.
....
help? :-/



Edited 2 time(s). Last edit at 01/06/2011 06:33AM by vevoto.

OK, Update:

• Opened the case to cut the power line from the battery.
• Took some pictures from the board
• pressed reset button.
• some screen flicker, display complained about low battery and switched device off.
• frame works again!
• no battery disconnect necessary.

so there was no need to open the case :(
(I tried to press the reset button before, but it seems i did not reach the button with the bent paper clip ...)

Compiled with the first values for LEN0-3 (the same, which were used by the script) and the result is the same as shown in the picture of my last post: Some lines at the bottom get black. (this time without freezing the frame ;) )

What to do now?

( First of all: Sorry for my tripplepost. )

Update2:

• Downloaded the fw dumps from neophob's keypix picframe from here.
• Disassembled the whole thing according to newhack.txt and came exactly to the same results as given by neophob.

Interesting facts compared with my disassembly:

• The asl, rol, rol part occurs 2 times in neophob's fw dump, too. He used the first occurrence like the generate-hack.pl script does!
• The sequence LDA #$2a[...]LDA #$2b[...], which identifies the PCF8833 (CTRTYPE=0) exists in seg1 in neophob's dump

Status of my hack:

• I used the first occurrence of the asl, rol, rol part like the script (as written in my last post - the one which does NOT freeze the frame ;-) ).
• I used CTRTYPE=1, because the exact sequence for the PCF8833 is not in my firmware segments 0-3, but the other part exists in seg1.
• I modified the test-png from folder setpic and added labels in the 4 edges (see attachment 'test_WithMarks.png'): UL=UpperLeft, UR=UpperRight, DL=DownLeft, DR=DownRight.
• The Attached Photo 'keypix_FirstAdrBlock_PicAtWrongPosition.jpg' shows the result from command:
  

  LD_LIBRARY_PATH=./libst2205 ./setpic/setpic /dev/sdb setpic/test_WithMarks.png

• when using setpic with parameter "-test", i can move up and down, but not left right and can't get the pic in the right position.
• compiled with bpp=24. just garbage. The same when switching to 12bpp in setpic -test (when compiled with 12 or 16bpp).

The last attachment is the firmware dump of MY picframe. Is there somebody who can help me? sha1sum:

7161dc162554cada3c0ea9ffd6bce79a2c592a35  fwimage_keypix_vevoto.bin

Edited 1 time(s). Last edit at 01/06/2011 12:46PM by vevoto.

Havent seen that before but it looks like you are almost there.

I would try reflashing with OFFX=112 and OFFY=112 in the spec file.

I don't think you can reflash without the battery connected though - at least that is the case with the Innovage and the Coby picframes.

-PG

petergunn Wrote:
-------------------------------------------------------
> I don't think you can reflash without the battery
> connected though - at least that is the case with
> the Innovage and the Coby picframes.

Interesting. I was able to flash my Shift3 without the battery connected. I was getting annoyed by the blinking status of the icon because it would never come out of "low battery warning" state. ;)

Hi there,

Quote
petergunn
I don't think you can reflash without the battery connected though - at least that is the case with the Innovage and the Coby picframes.

Quote
rat
Interesting. I was able to flash my Shift3 without the battery connected.

Hm. It seems, that the keypix needs its battery, too.

Quote
petergunn
I would try reflashing with OFFX=112 and OFFY=112 in the spec file.

Done. Result in the two attached images.

The first one 'keypix_Offx112Offy112_ItWorksImageAfterFlash.jpg' shows the display directly after flashing, "showing" the Image from the hackfw script (Dark blue 'It works' Text on black background). As you can see, only one little line makes it to the display.

Attachment two, 'keypix_Offx112Offy112_SetpicTestImage.jpg' shows the output of the setpic program after 1xkeypress 'd' and then 1x 'u'. (Display gets only refreshed when pressing 'u' (move image up).)

When calling setpic without the -test parameter, noting can be seen on the display, it seems that it is not redrawn then.
When using setpic -test, i can move the image up and down, but left and right don't move the image, instead of that, i can move an "edge" (picture is misplaced 1 pixel up/down at this edge). (sorry, hard to explain..)
When switching to another bpp, the image is mostly grey and garbaged.
But when i press 't' 2 times (16bpp -> 12bpp -> 16bpp) and refresh the display (with pressing 'u'), the whole image gets a left/right offset of ~(1/3)*DisplayWidth. But no matter which combination i try, i can't bring it to the right position.
Yesterday, i tried many different values for OFFX and OFFY. for example all combinations of 0,2,4 like they are used in the available hacks in st2205tool and some random values like 16, 32, 64 for OFFY. This way, i could get the 'It Works' Image nearly centered (y position), but the text is cut on the right side and pasted at the left border of the screen. But no matter which value i use for OFFX, it does not work. (I tried to count the offset from the photo and tried some values around 13, 19, (combinations with +-(128-13)), etc. )
(I also tried 24bpp(garbage) and 8bpp(error from libst2205))
And regarding Question c): I have to use CTRTYPE=1, i tried with CTRTYPE=0, Result: black screen after sending a pic to the screen.

..got no idea, what i can do now..

btw, my spec:

CMP_VAR1=$037A
CMP_VAR2=$037B
PATCH_AT=$2B9A
EMPTY_AT=$2D40
SEND_CSW=$2A62
LEN0=$36C
LEN1=$36D
LEN2=$36E
LEN3=$36F
CONF_XRES=128
CONF_YRES=128

CONF_BPP=16
CONF_PROTO=0
CTRTYPE=1
OFFX=112
OFFY=112

DP152 alert!

http://www.adorama.com/CYDP152RD.html

Has these in red for $6.95 free shipping, $5.95 ea for 2 or more!

HTH, Jim

vevoto Wrote:
-------------------------------------------------------
> ..got no idea, what i can do now..

Looks to me like you can write to every pixel on the screen and the image is just offset a bit. At this stage I would suggest leaving the configuration the way it is and just modify libst2205 to render the output so it looks correct.

First stop libst2205/st2205.c trying to render partial images by changing...

        if (h->proto == PROTO_PCF8833) {
                if (h->oldpix == NULL) {
                        pcf8833_send_partial(h, pixinfo, 0, 0, h->width - 1, h->height);

to

        if (h->proto == PROTO_PCF8833) {
                if (1) {
                        pcf8833_send_partial(h, pixinfo, 0, 0, h->width - 1, h->height);

Then you need to modify the way libst2205 renders the screen by changing:

    for (y=ys; y<=ye; y++) {
                for (x=xs; x<=xe; x++) {

To...

    int y1,x1,cx=112,cy=112;
    for (y1=ys; y1<=ye; y1++) {
                for (x1=xs; x1<=xe; x1++) {
                     y=(y1+cy)&0x7f; x=(x1+cx)&0x7f;

Try changing cx and cy coordinates and recompiling to move the image around.

Disclaimer: I haven't tried this - but it should work :-)

-PG

Hi Petergunn,
thanks for your detailed help.
I didn't have the time to do extensive tests.. hope i will do soon and answer in a couple of days.

Hi Hades,

Quote
vevoto

Quote
Hades
[...] as always you cant get the cool stuff in the EU -.- [...] in the EU (mainly germany) [...]

Hi Hades, i got mine from ebay.de. I searched for 'keypix'. From time to time, there is one available from private sellers...

ebay.de: Keypix Digitaler Mini Fotorahmen (3,8 cm (1,5 Zoll) D
(But i do not know, if this one is hackable. The description says nothing about a driver CD, so maybe it is one of the unusable picframes..? See here (Picframe wiki) for more information about compatible devices.)

Hi together,

if you search a cheap display you buy for € 3,33 at MM the HAMA Football Photoframe :-)

Jowi

BTW, any news on the Appotech AX20x devices?
I just received a white 2.4" pic frame based on that chipset today, which would fit he dockstar perfectly.

I also have a 2.4" Appotech AX20x (micca) but they don't appear to be hackable at least for now. I'm actually using it to hold pictures - the 2.4" screen is much better than the 1.5" ones.

I also recently received on of those DX frames thats supposed to be hackable - haven't had a chance to try it yet but it is free standing so it can sit on the dockstar shelf.

-PG

petergunn Wrote:
-------------------------------------------------------
> I also have a 2.4" Appotech AX20x (micca) but they
> don't appear to be hackable at least for now. I'm
> actually using it to hold pictures - the 2.4"
> screen is much better than the 1.5" ones.
>
> I also recently received on of those DX frames
> thats supposed to be hackable - haven't had a
> chance to try it yet but it is free standing so it
> can sit on the dockstar shelf.
>
> -PG


Yes, the 2.4" screen is quite nice. That's the one that I got (well, I got it elsewhere and even cheaper, but it's the same piece):

http://www.dealextreme.com/p/2-4-lcd-desktop-digital-photo-frame-and-calendar-27-picture-memory-storage-21334

Had hoped for it to be based on another chipset, but even if it won't be hackable it's quite a nice toy. The beautiful thing about this particular pic frame would be the exactly centered USB-connector on the left side and the white housing. With some minor modifications one could actually directly mount the frame on the dokstar's mini USB port and it would still look good.

Anyway, thank you very much for all your effort so far. The project, as is, is great nonetheless. I originally had ordered 2 1.5" pic frames from DX before christmas, but didn't receive any of them yet. Will see what happens, if I should get those frames eventually.

I actually have a slightly different 2.4 micca although its sure to have the same electronics underneath.

The one I ordered from DX took at least 2 months to arrive. I would have chased it or cancelled it if it had not been over the busy Xmas period.

-PG

Yeah, I was not in a hurry concerning the pic frames, so I just contacted the support recently and am now waiting for what they'll do. I did actually recieve something (a mini spycam shaped like a car keyring). The thing is, I didn't even order that at all. :-D

Anyway, seeing that some people already were successful with these pic frames, I just found the following link and regret not being in the US right now:

http://www.amazon.com/Coby-1-5-Inch-Digital-Cliphanger-DP152BLK/dp/B001EH8KU0/ref=sr_1_12?s=electronics&ie=UTF8&qid=1297341749&sr=1-12

This would probably be a hassle free and REALLY cheap way to get a display for the dockstar. And you can even put them directly onto the mini-USB connector with minor modifications to it (the conector that is).

Frames with an AppoTech AX206 are hackable: http://picframe.spritesserver.nl/wiki/index.php/DPF_with_AppoTech_AX206

Here you can order very cheap AX206 2.4" frames:
http://www.pearl.de/a-HPM1184-5618.shtml
http://www.pearl.de/a-PX1184-5618.shtml
These seem to be the same or very similar models, one for EUR 9,90 and one for EUR 2,90 (only one per order).

I also have one of these but haven't tested that hack myself.



Edited 1 time(s). Last edit at 02/10/2011 01:12PM by twinpeaks.

Very nice find. So it seems that there is hope.

Edit:
Downloaded the files provided with the hack and installed sdcc. Nevertheless I could not compile the needed files. I'm getting some error about a missing rule for target "app_clr.ihx". As I'm not much of a coder, I can't do anything about it, unfortunately.



Edited 1 time(s). Last edit at 02/10/2011 04:34PM by ingmar_k.

Looks like just some unecessary stuff in the Makefile.

The following compiles on my Ubuntu laptop (haven't tried debian):

Install build tools:

apt-get install sdcc python-dev

Compile:

cd /tmp
wget http://tech.section5.ch/files/dpfhack-0.0alpha.tgz
tar xvfz dpfhack-0.0alpha.tgz 
cd dpf/src
perl -pi -e 's/app_clr.ihx jumptbl.ihx//' Makefile # change Makefile
make

I don't have time to test if the hack works right now.

-PG

I tried it right away. After installing python-dev and libusb-dev I was able to compile the hack itself. But when it came to compiling lcd4linux, it stops at

"checking which drivers to compile... configure: error: Unknown driver 'DPF'
make: *** No targets specified and no makefile found. Stop."

Edit:
I tried again today, but I don't seem to be able to get it to work. Either there's still something wrong in the description or the files, or I'm still missing some important. Don't know. Anyway, I can wait. Maybe someone else could try it if he/she finds the time. ;-)
Oh and BTW, you have to install "libtool", too.
Edit2: And you also need to install autoconf.
Edit3: I think I'm getting close. Ran the hack, as it seems without problems. But, I'm still struggling to install the patched lcd4linux. :-(
Edit4: Got it working. Just had the path to the dpflib wong. Will post the step by step and hints later. VERY NICE!



Edited 4 time(s). Last edit at 02/12/2011 02:23PM by ingmar_k.

Any ideas how to add an new hack to profiles.py? I tried copying the other entries and changing a few parameters but I think a new hack might be required - unfortunately there is no new hack instructions like there was for st2205 devices.

I left a comment on the DPF blog.

-PG