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

Mon Jun 26 12:07:17 CDT 2006

The port number(s) for the (GP)IO pins will have been defined by 
Actions when they made the chip.
You will not find that information in a Z80 manual ...so it wasn't a 
stupid question after all ;)

The way that the GPIO pins are used by "the company which turned the 
chip into a fully-fledged player" can (and probably do) vary.

So the PORT will remain fixed by the 20xx
and the way the PINS are used will be fixed by the player manufacturer

Each BIT will be one of the GPIO pins

BC

>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
>
>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>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
>>><mailto:a.j.buxton at gmail.com>a.j.buxton at gmail.com
>>>
>>>
>>>_______________________________________________
>>>s1mp3-dev mailing list
>>><mailto:s1mp3-dev at s1mp3.org>s1mp3-dev at s1mp3.org
>>>http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
>>>
>>
>>
>>
>>
>>_______________________________________________
>>s1mp3-dev mailing list
>><mailto:s1mp3-dev at s1mp3.org>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://s1mp3.org/pipermail/s1mp3-dev_s1mp3.org/attachments/20060626/99762415/attachment.htm