Jeez oh pete, looks like that chip will work, but now i need to slap a DRAM x16 on it. am i being to whiny 
I just dont believe with all the LCD’s out there there is not a small & cheap, easy to implement graphic controller out there. I never would have though that driving this panel took so much silicon to make it work.
Maybe i better look into this original threads idea of the FPGA, or just wait until the ARM7 (LPC2478) comes out. hopefully it will be able to drive the panel.
Just quickly looking the S1D13743 or S1D13742 will both drive this display and available in TQFP package.
There should be a few others as well, just a matter of going through the data.
The S1D13513 is a bit of an overkill, any reason for choosing this?
Cheers
Spen
The S1D13513 is a bit of an overkill, any reason for choosing this?
nope, just saw it would work and stopped there. i will take a look at the other one you showed.
That one was available from mouser, and the first one I found, but looks like the others would work too [and cheaper, which is good!]
Cheers,
–David Carne
Just quickly looking the S1D13743 or S1D13742 will both drive this display and available in TQFP package.
ntfreak, i took a look at the S1D13743, the data sheet says: “Supports resolutions up to 352x440.” the PSP display is 480x272, am i just looking at this all wrong. i suppose if i take 480272=130560, and then 352440 = 154880, which tells me the S1D743 can drive more pixels. but i could be just reaching here. the other one you mentioned S1D13742 says: “Supports resolutions up to 800x480” so i have no problems with this one. and it comes in a QFP20 package as well like you said.
Thanks to all of you who helped me find what i need. Later i will start to make a prototype board of this chip for the PSP screen.
As the display is 480*272 and running full 24bps you will need a frame buffer of 391680bytes - more than enough unless you want double buffered.
((480*272)/8)*24bps = 391680bytes ram required
Generally they spec like that, the thing todo is look in the datasheet and see if all the values fit in the VTOTAL and HTOTAL registers.
This display controller looks suitable to me, unless i have misses something.
They normally have a nice register config tool to download, may have to request direct from epson. This helps greatly in setting up display controller timings etc.
Cheers
Spen
Thanks, i will contact epson for the config tool. i know what your talking about as i have that for a different controller they make.
I am almost done with the circuit board for this LCD. I settled on the S1D13742 IC. One part confusing is the connection of the actual LCD to the GC. on page 20 of the data sheet i dont see how i can connect up the LCD to the IC. the LCD is 8 bit per color but the sheet shows only 5 bits.
I must have missed this thread. The S1D13742 seems the perfect option to drive the PSP LCD 
8)
Is there any chance that sparkfun will ever sell this chip?
hi seulater,
i haven’t used the S1D13742, but just recently finished making a device that uses the SED1375. inituively, if you have 5 bits per pixel of data from the LCD controller, and 8-bits going into the LCD, you could probably just ground the last 3 bits going into the LCD.
144 pins – that’s a lot! 
I wonder if this could be used for Sparkfun’s 3.5" TFT ( http://www.sparkfun.com/commerce/produc … ts_id=8490# ).
thats what i was thinking,. but i think it should be the first 3 bits rather than the last 3 ?
The datasheet says that it supports displays up to 800x480, so it will probably work with that lcd as well :)144 pins – that’s a lot! Smile I wonder if this could be used for Sparkfun’s 3.5" TFT ( http://www.sparkfun.com/commerce/produc … ts_id=8490# ).
Sorry that I can’t be absolutely sure but I haven’t had the time to fully read the datasheet yet.
First I think it's not 5 bit per pixel but 8 bits per subpixel (the R, G and B subpixels)inituively, if you have 5 bits per pixel of data from the LCD controller, and 8-bits going into the LCD, you could probably just ground the last 3 bits going into the LCD.
Anyway I propose a different solution: Connect the 5 bits of the controller to the 5 most significant bits of the PSP LCD, tie together the remaining 3 bits (that are the LSB) and connect them to bit #0 of the controller.
Something like this:
C0…4=Bits of the controller (bit #4=MSB)
L0…7=Bits of the LCD (bit #7=MSB)
L7 ← C4
L6 ← C3
L5 ← C2
L4 ← C1
L3 ← C0
L2 ← C0
L1 ← C0
L0 ← C0
In this way the display can render any color from full black (L0…7 @ 0) to fully lit (L0…7 @ 1). Simply connecting unused bit to ground won’t allow this.
I agree, that seems the way to go, I wonder why epson has all thoes pins for the LCD but they are not used, yet it only gives me 5 bits worth of color data when it clearly has enough for 8
Well, maybe they don’t have enough ram for a 24bit per pixel display…
Anyway, since now sparkfun is selling two LCD displays which will (almost certainly) work with that controller, I hope the’ll sell the controller chip too.
i dont think they will sell it, as you can buy them from mouser.
I know but I can’t buy from mouser, they don’t accept PayPal… 
My usual solution is to connect the lower bits to the higher order bits, aka
L7 C4
L6 C3
L5 C2
L4 C1
L3 C0
L2 C4
L1 C3
L0 C2
For some reason I tend to think that this will be a bit smoother, but I haven’t mapped it out yet. Disadvantage is the color range becomes a bit less linear.
Cheers,
–David Carne
The non linearity might be good in that case. I don’t know exactly but it might cause some sort of dithering effect, and the display might look like it has more colors than what the controller chip can render.
Any hope that this controller chip might be sold by sparkfun?
Well, first there would need to be a publicly available datasheet, and I can’t find one.
Anyone got a link?
Cheers,
–David Carne
it is publicly available