LCDInfo.com

hy all,
nobody know me but this don't make me a newbee...
my little brain just got an fabulous
actually the ks0108b capacities aren't fully used: the read/write pin isn't used, so the LCD is use in delay more instead of busy mode.
With the actual wiring it is impossible to connect the rw pin to the lpt port.
So we need a little tweak...
Ok, lets play...
CS1 & CS2 select the chip you want to talk to BUT you can talk only to one chip at a time (LCDInfo do this, I have read the source).
So when CS1 is active, CS2 is inactive and CS2=ON => CS1=OFF
=> two states: CS1 CS2
state 1: 1 0
2: 0 1
we don't need of two LPT pin to control this: just one is enought BUT we need an inverter on one of the CS pin.
this inverter could be anything, a transistor should work (2n2222 ?)

LPT: LCD:
16-Init-------------------------------------CS1
|
| 5V
| |
/ /
1K \ \ 4.7K
/ /
\ \
| |--------------CS2
| ___| c
| b / | /\
|__|_|/ | 2N2222
\ |\_/
``| e
_|_
/////

14 -------------------------------------------------------RW

Ok this look like very bad... I have got a better draw on a my floppy but someone have put something in this ù*$^* floppy drive.

I will put something better after.
What do you think of this

Driving CS1 and CS2 with only one input is something I've also thought. I just haven't had the need to try that yet. I think you can see this used in some schematic linked at the KS0108 page.

What would be the benefits of using the busy mode instead of delay ? I'm asking this because I've no idea how it would behave with that. Any chance for a speed up ? I think reliability could be improved, but this could also slow things down.

Something I've thought to try is that would it be possible to drive both controllers at the same time ? This could be used to speed up the display clear and in other situations where same data can be written to both controllers. Although driving 128x64 KS0108 displays is pretty fast even with the current code so I haven't had the need to try this.

In any case driving CS1 and CS2 with only one output is a good idea - I'm just not aware of the pros and cons of it. And supporting this wiring in LCDInfo shouldn't be very hard.

This kind of idea shuold be great !! , one other tha would be interesting would be the implemen of some kind of GPO's like the matrix Orbital displays , one idea was to use a demultiplexer , and spilt one entrance to 8 or something , but with that we nedded 4 pins , one for the 4 entrances in alternating and 3 for the 3 select entrance gates , not the on foo circuitry woul allow if it was possilbe to route all this entrances to have 4 or 5 gpo's , tha coul be activated by a very simple on / off logic switch , tell me if i'm dreaming too much

SAmtech

_________________
The Power is Within your Hands ,use it wisely...

XP 2000+
A7N8X Dlx
256 Mb DDR PC3200 OCZ
GF 4 Ti 4200 128 DDR
180 Gb
Studio PCTV Pro

First I'll have to admit that I didn't understand everything in the previous post.

One GPO would be easy if the CS pins were controller using 1 line. But increasing them after that isn't so easy anymore and would need more work on the software. But I think everything could be done.

utility of this?
one of them:
well in the last available source code you directly send datas to lcd, there is no virtual screen between the data & the lcd.
Using the read function could permit to read datas of the lcd and to do an OR function between the data & what the lcd already have. (Ok this will slow up the write process: setcolomn;setpage;read;setpage;or_calc;writedata; instead of setcolomn;setpage;writedata;)

I am looking at what you said: use of both chips...
The diagram of my doc isn't very explicit, I think this should be tried, but who will try it? And is there is a risk?

You are right, a buffer in software would be much faster. Something that can be found in the next LCDInfo

I'm not sure if there's any risk in settings both controllers on at the same time. I have a feeling that I've already done this by mistake earlier while coding the KS0108 driver.

I tried to make my own program, but stopped on the buffer to lcd algorithm (still searching):
take a lcd like mine: ks0108b, 128x64
the easier way of stocking data into the buffer is one byte for 8 pixels (a char) so 128x64 / 8 => 1024 bytes
so we make a
each byte is 8 horizontal pixel:
1st byte: 8 first pixel 1st line
2nd byte: 8 next 1st line
...
17 byte: 8 first pixel 2nd line
....
until end
easy easy...
now the transmission to the lcd:
data are sent to the lcd by group of 8 pixel, but these pixel are vertical

The only algorythm I found is something like this:

This THING (is there is any other appelation?) is horrible. but i didn't tried it it may work or not,
In fact I just wrote here what I have in my brain for 1 week, it is less horrible that I tought.

_________________
Shadows move where light should be

This is how I've done it:

It reads 8 bytes and then swaps the bits in this 8x8 bit block to the lcd format and writes them and then reads the next 8 bytes and so on... I'm sure it can be done better.

here is my code corrected... I made a mistake in how lcd work & corrected it...

_________________
Shadows move where light should be

again wrong...
this one the fully working code with full test
(it work fine becaus i use it for my wmp plugin with a beautifull spectrum analyser)


yeppe

_________________
Shadows move where light should be

Good to see you getting it right