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

@superelchi
I test latest firmware and don't work for me
My dpf is very similar for white and pink but is violet
I put my dump of firmware and photos
https://www.dropbox.com/sh/2gmhlc61xftrhz8/owL5FwbiF7/dpf_nofoto_dump.bin
https://www.dropbox.com/s/6xroebmd688ffvi/IMG_20110926_074800.jpg
https://www.dropbox.com/s/c869h10gperul6e/IMG_20110926_074737.jpg

buspirate Wrote:
-------------------------------------------------------
> I will try the new identify.py and report back.

I tried the greatfoto DPF bin file with identify.py

Looking for buildwin firmware....: Found.
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............:
Traceback (most recent call last):
  File "fw/identify.py", line 278, in <module>
    dpf, pm = recognize_dpf(data)
  File "fw/identify.py", line 229, in recognize_dpf
    c = find_initbl(dump, i)
  File "fw/identify.py", line 117, in find_initbl
    i = struct.unpack("B", data[p])[0]
IndexError: string index out of range

Is this abnormal or a known problem?

superelchi Wrote:
-------------------------------------------------------
> Hi buspirate,
>
> you could try the focal firmware from svn or
> precompiled
I tried fw_focal.bin and got a white screen. Any advice?

@prezes_kk
I added a new model based on your dump. Please try attached firmware.
Am I correct - its a 128 x 128 lcd?

@buspirate
Seems to be a problem of identify.py. Worked with all dumps I could grab. Yours seems to be special. :-)
Could you upload a dump?

superelchi

@superelchi

uploaded firmware

Thanks

Hi buspirate,

Good news: commited a new version of identify.py to svn that will work with your dump.
Bad news: your fw does not use the "standard" way of initializing the lcd by a table. Everything seems to be done in LcdInit . This is currently not supported by the svn version of dpf-ax. Working on it. Will be ready in a couple of days.

superelchi

@superelchi
thx for your advice
yes lcd is 128x128
after flash fw_agk_violet.bin firmware screen position is correct and colors is ok
but device usb0 is not created and image is broken
i attached a picture & lsusb log

https://www.dropbox.com/s/6a3ee1gew3zd76r/DSC_0061.JPG
https://www.dropbox.com/s/fiwlykgf4rouovh/lsusb.log

prezes_kk Wrote:
-------------------------------------------------------
> after flash fw_agk_violet.bin firmware screen
> position is correct and colors is ok
> but device usb0 is not created and image is
> broken
Screen fixed.
The term "usb0" ist just used by the dpf-ax lib as a selector for the hacked-fw. If you want a device named /dev/usb0 you have to create your own udev rule.

superelchi

@superelchi
may thx its working ;]
how to create a udev rule ?

prezes_kk Wrote:
-------------------------------------------------------
> may thx its working ;]
Fine. So I will add it to the list of supported models.
BTW: do you have a link to a site where this model is available?

> how to create a udev rule ?
There are many tutorials all over the web how to work with udev. But if you plan to use the display only with existing drivers and/or libdpf there is no need for a specific udev rule. Everything is handled by libdpf.

superelchi

@superelchi
this dpf was buy in polish site allegro.pl and i don't have a link :(
I added to udev rules
BUS=="usb", ACTION=="add",SYSFS{idProduct}=="0102", SYSFS{idVendor}=="1908", SYMLINK+="usb0"
and it works
lcd4linux display corectly
many many thx

@buspirate
Please try attached firmware.
Not sure if I got it right - is it really a 128 x 144 pixel dpf?

superelchi

@superelchi

I tried the firmware but got a white screen. It's a 2.5inch. Thanks.

@superelchi

I tried rev9 of identify.py , it reported the dpf is closest to linkdelight and I tried to flash that and it worked! Thanks a lot! I will try lcd4linux next.

@superelchi
lcd4linux works too, thank you very much for making this possible!

@superelchi

I realize now why you said this is a 128 x 144 pixel dpf. I actually have another 1.5inch dpf from focalprice but I have not been working on that for a while. I must have mistakenly named the firmware file wrongly as greatfoto thinking that was for the greatfoto 2.5 and uploaded that. My apologies for the confusion. Nevertheless identify.py works and was able to identify the 2.5 correctly and the 2.5 from greatfoto now definitely works.

I flashed the fw_greatfoto.bin you created to the focalprice dpf and got a scrambled display with white lines and blue dots at the top and botton of the screen.

As I press the menu button, I get vertical bars of blue with black gaps in between. The scrambled white text which cannot be made out will move from top to botton as menu button is pressed.

Can you help please? Thanks once again

1.Is there any volunteer to port st2205term to AX206?
2. Does this alternative firmware support AUTO OFF function?
3. Is there any documentation about this alternative firmware? What does monitor shows, what is USB, PWR, EP0, STL, LOG, ERR, ACK, ALV and Debug?

@superelchi
Could you rewrite HOWTO about reverse engineering? This HOWTO from
https://github.com/makefu/dpfhack_pearl/blob/master/reverse/README
is not very clear. Hackfin is too busy to explain it, any you are the only one skilled person.

@buspirate
Could you please upload the original fw for your 128x144 dpf again? Just to make sure I have the correct one...
BTW: is the original fw portrait (128 hor, 144 vert) or landscape (144 hor, 128 vert)?

@neon
There is no easy "follow-these-steps" way to add a new dpf. I rearranged the sources a little bit and added some helpers (like identify.py) to make it easier. But - you have to know what you are doing.
As hackfin said: Just read the source, duke.

superelchi

@buspirate
Please try this for your 128x144 dpf. Renamed it and fixed bug (screwed hight and width). :-o

superelchi

@superelchi
The screen looked the same as the earlier firmware you posted in #14, with the scrambling of blue and white.
The vertical side looks longer so I assume this is 128 horizontal 144 vertical.

Here's the upload of the original firmware.

I think the blue color suggest the dpf is hacked but the resolution/orientation is still wrong.

Thanks for looking into this.

Okay. What about this?

superelchi

It resulted in the same scrambled display as the 2 earlier versions. Thanks.

buspirate

Sight. Next one.

superelchi

You did it again! Your magical touch on the focalprice144 dpf!

Many thanks for your time and effort.

Happy to report lcd4linux is working too.

You have my gratitude.

buspirate

I started toying with revision 10 of the dpf-ax svn. The src/lcd looked interesting with 3 new displays. With superelchi's hints on identify.py, I messed with the dev mode and set it to value of 2. Two files: lcdinitbl_tmp.bin and openwin_tmp.bin were created. I couldn't figure out openwin relation to the rest of the code and left that alone and went after lcdinitbl_tmp.bin, I hexdumped that.

I compared the lcdinit.s of the 3 displays, there were similiar sequences of

.db	#0x00, #0xb0, #0x64, #0x11, #0xb0, #0x0a, #0x10, #0xb0, #0x64, #0x11, #0xb0, #0xff

in the _custom_initseq. Now I see a match with the beginning hex sequence of lcdinittbl_tmp.bin from my dpf.

Just for kicks, I converted the hexdump sequence into the .db format for lcdinit.s, created a new folder blackfor my dpf. I couldn't figure out what to put in lcdblit.s so I just used one of the existing ones. Edited config.h, extracted the following line from buildall.sh

make TYPE=black clean all

I happily flashed the resulting fw_black.bin and got some white dots, and green and blue lines on the dpf.

Am I on the right track? I have to admit I am acting on a hunch and actually have no clue :P

Hi rotidude,

yes, for your kind of displays thats the way to do it.
Next step is to disassemble openwin_tmp.bin. Get yourself d52 (8052 Disassembler) and do:

d52 -p -b -n openwin_tmp.bin x1280

You will get openwin_tmp.d52. Do some cleanup (identify the blit-coordinates, etc.). Thats the one to go into lcdblit.s.
Following file may help by identifying some often used vars.
Create a file named "openwin_tmp.ctl":

; Common stuff for compiling this for 0.2 up with sdcc
; Routines in ROM:

; Writes a byte to the LCD port p3
l 0f25 otp_lcd_write

; Registers
r 00 ar0

; I/O mappings:
k 94 LCD_A0

; The following registers denote the LCD controller context area
; See lcd_setcontext()

; Converted to 0.2 vars
;
; most dpfs need this mapping..
r 77 _g_blit+x0         ;G_lcd_cxL
r 78 _g_blit+x0+1       ;G_lcd_cxH
r 79 _g_blit+y0         ;G_lcd_cyL
r 7a _g_blit+y0+1       ;G_lcd_cyH
r 7b _g_blit+x1         ;G_lcd_dxL
r 7c _g_blit+x1+1       ;G_lcd_dxH
r 7d _g_blit+y1         ;G_lcd_dyL
r 7e _g_blit+y1+1       ;G_lcd_dyH
; .. some need that mapping
;r 78 _g_blit+x0         ;G_lcd_cxL
;r 79 _g_blit+x0+1       ;G_lcd_cxH
;r 7a _g_blit+y0         ;G_lcd_cyL
;r 7b _g_blit+y0+1       ;G_lcd_cyH
;r 7c _g_blit+x1         ;G_lcd_dxL
;r 7d _g_blit+x1+1       ;G_lcd_dxH
;r 7e _g_blit+y1         ;G_lcd_dyL
;r 7f _g_blit+y1+1       ;G_lcd_dyH

Run d52 again. But beware! Use your brain!

If you get it working, it would be nice if you add a record to fw/knowndps.py (use the CRCs you got from identify.py) and submit you changes at dpd-ax/Tracker/Patches.

A word of warning: this method works only for "standard" buildwin builds (luckily most builds are), not for the ones that do their initialization by LcdInit instead LcdInitTbl (see focalprice144) or do anything special (my dealextreme 2,4" dpf is such a beast - no luck so far).

superelchi

Thanks superelchi, with the help of your hints, I got it working somehow but there are some issues with the contrast. The background is too bright and I can only view the display at an angle.

Here's the output from identify.py

Looking for buildwin firmware....: Found (128x128 px).
Looking for known version info...: None.
Looking for Openwin..............:
OpenWin        at 0x1280 (0x0006a0), len 0x35, CRC = 0xdda9c297
Written to openwin_tmp.bin.
Looking for LcdIniTbl............:
Module 37:
LcdInit (Tbl)   at 0x14b1 (0x04c181)
Module 51:
LcdScheduleTbl  at 0x14c9 (0x04d79f), len 0x00
LcdContrastTbl  at 0x14ca (0x04d7a0), len 0x09
LcdContrastTbl  at 0x14d4 (0x04d7aa), len 0x0b
LcdBacklightTbl at 0x14e0 (0x04d7b6), len 0x16
LcdIniTbl       at 0x14f9 (0x04d7cf), len 0x98, CRC = 0xda6ee4c3
Written to lcdinitbl_tmp.bin.
Looking for known signatures.....:
None.

Sorry, no matching dpf found.

Should I start modifying identify.py to dump module 51 with the aim of running d52 at 0x14ca? I am still messing around and don't really know what I am doing, sorry :P

>Should I start modifying identify.py to dump module 51 with the aim of running d52 at 0x14ca?
No, all Lcd*Tbl are just - tables. Nothing to disassemble here. Dpf-ax fw does not use any of these tables besides LcdIniTbl at the moment.
Maybe I will integrate the contrast/backlight table in the future. Do not ask when. :-)
Is contrast/brightness much better with the original firmware or is it just a poor lcd?
Did you try to adjust the backlight from the menu?

superelchi

Hi superelchi,

The original firmware has a brighter display. The original menu has a contrast setting. Adjusting backlight doesn't help.

Here's the patch applied against dpf-ax revision 10 for my changes, I am too lazy to apply for a sourceforge account just to submit the patch :P

Thanks for your help - I can live with the contrast for now and wait for your changes, otherwise I will try to hack the contrast setting once I figure out what I did - the honest truth is I got lucky and you gave me lots of help along the way