[s1mp3-dev] HOWTO: figure out your LCD/OLED display

[seventh guardian]

On 6/26/06, Rembrand van Lakwijk <rembrand at lakwijk.com> wrote:
>
>  Er wait, nevermind, that was stupid. Obviously F4 is the GPIO. Could you be
> a bit more specific as to how to control this line though? Is port F4 always
> GPIO? Or is it just the bit number (2 in this case) that's different on each
> player model? Or should i read a z80 manual before asking more stupid
> questions? :P

Lol.. GPIO stands for "general purpose input/output". Basically all
pins that don't have any special function (or those whose special
function is deactivated) are GPIOs. Since they are all GPIOs, every
board manufacturer has the ability to choose which one is connected
where in order to keep the board tidy. He then configures the software
to use some GPIO pin to some function, like that on the LCD. So each
different player probably has a different pin assigned to that task..

It's a matter of using symbols in the code instead of the real
addresses, and having those symbols defined on a header file for a
particular player..

>
>  Rembrand van Lakwijk schreef:
>  Also note that the first (command-writing) routine clears bit 2 on port F4,
> and the data-writing routine sets it, leaving the rest of the bits
> untouched. Does anyone have any clues as to what's on this port? (Also, it
> would be useful to actually write this as %11111011 and %00000100 so that
> it's clear it's not just another magic number)
>  just my $.02
>
>  Alistair Buxton schreef:
> Okay, some people have been having trouble getting the loadram samples to
> display anything on their screen. I've been investigating, and this is what
> I found:
>
>  I had one player that worked perfectly and one that would only draw in a
> thin band (actually it turns out this is a page.)
>
>  I looked in to the programming method for LCD displays, and learned they
> have two modes: data mode, where you write the raw data to the screen, and
> command mode, where you do things like position the cursor. The mode is
> controlled by a GPIO line which must be turned on or off. Since we know that
> manufacturers like to rewire the GPIO different in every player, I guessed
> that this was the cause of the problem.
>
>  The first thing i found while playing around is that writing to any address
> 0x8000-0xFFFF ends up at the LCD data input. So it looks like the ATJ's CE3
> line (also known as "LCD enable" in some docs) is wired directly to the
> internal address bus highest bit.
>
>  So I disassembled every file in my player's firmware ( for i in `ls`; do
> echo $i; z80dasm $i > $i.asm; done) and looked for writes (ld) to any
> address above 0x8000 (inclusive.) (Using grep, of course.) Obviously there
> were a lot. From looking at the examples I noticed that 0x8000 and 0x8001 is
> normally used for accessing the LCD, so I narrowed the search to these
> addresses. Only a few firmware modules actually had these addresses, most
> notable the files UI_xxxx.DRV.
>
>  I looked more closely at the UI_L0724.DRV disassembly (L=latin?), and found
> this:
>
>      push   bc              ; 000805 C5
>      in     a,($f4)         ; 000806 DB F4
>      and    $fb             ; 000808 E6 FB
>      out    ($f4),a         ; 00080A D3 F4
>      ld     a,c             ; 00080C 79
>      ld     ($8000),a       ; 00080D 32 00 80
>      pop    bc              ; 000810 C1
>      ret                    ; 000811 C9
>
>      in     a,($f4)         ; 000812 DB F4
>      or     $04             ; 000814 F6 04
>      out    ($f4),a         ; 000816 D3 F4
>      ld     a,(hl)          ; 000818 7E
>      ld     ($8001),a       ; 000819 32 01 80
>      inc    hl              ; 00081C 23
>      djnz   $0818           ; 00081D 10 F9
>      ret                    ; 00081F C9
>
>  These are clearly subroutines!
>
>  The first subroutine turns off a GPIO line, and the second turns one on...
> just what we are looking for. Also, they both write to the LCD. The second
> one writes the data from (hl) to (hl+b) so it looks like a routine to copy
> graphics to the LCD. The first one only ever writes one byte, so it looks
> like it's passing a command. It seems like a convention to use 0x8000 when
> sending a command, and 0x8001 when sending data, although these addresses
> are interchangable.
>
>  After googling for 8080 lcd programming commands for a while, I found this
> PDF with some LCD commands:
>
>  http://serdisplib.sourceforge.net/ser/doc/sed1560.pdf
>
>  Sure enough, once I had the correct port and bit, these commands worked on
> my display, at least the simple ones did.
>
>  BTW the display I was using is not actually LCD, but mono OLED. I just used
> the term "LCD" cos I'm too lazy to type "display." I'm 99% certain all
> display types will use exactly the same commands - although the pixels will
> be packed differently on colour displays - you will still see something,
> even if it looks like garbage...
>
>  I hope this is of some help to the people who were asking about LCD
> programming in the IRC. Hopefully others will be able to follow my steps and
> discover the gpio mapping of their display, and then we can get more people
> coding :)
>
>  --
>  Alistair Buxton
>  a.j.buxton at gmail.com ________________________________
>
> _______________________________________________
> s1mp3-dev mailing list
> s1mp3-dev at s1mp3.org
> http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
>
>  ________________________________
>
> _______________________________________________
> s1mp3-dev mailing list
> s1mp3-dev at s1mp3.org
> http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
>
>
>
> _______________________________________________
> s1mp3-dev mailing list
> s1mp3-dev at s1mp3.org
> http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
>
>
>