IDE (PATA) LCD... insanity commences...

[LyosNorezel]

Greetings...
I recently acquired a few 82C55A chips... the same chips used by the, so-called, IDEFlasher (for flashing BIOS/ROM chips).

After looking at these chips for awhile... I decided to try to use these chips as a means of interfacing more LCDs to the computer than is currently feasible.

So far... I've managed to put together a rough sketch of a schematic. Using a single chip and the standard 8bit "winamp" style connection for these LCDs... I've drawn a schematic to acommodate 4 LCDs.

This schematic, I suspect, could be further modified to allow the use of 16 LCDs... though, I believe, this will require the use of a second 82C55A attached to the unused DB8-DB15 pins of the IDE bus... and some mux/demux magic on the WR, RD, CS, A0, and A1 pins in this schematic.

http://www.oslb.net/PATA-LCD.bmp

I would be very interested in hearing ya'll's thoughts and opinions on this.

And yes... I know I'm insane .

Lyos Gemini Norezel

Edit: For those who are interested... here's the Eagle CAD .sch (schematic) file: http://www.oslb.net/PATA-LCD.sch

[caesar]

Nice project! Go for it, do not hesitate, if you have the means!

I am using now a display that has 16 rows x 40 columns (8 2x40 or 4 4x40 displays size).

But if you consider that a graphical display with 16x40 columns is cheaper than 4 4x40 displays or 8 2x40 displays than why not use it? You could use those controllers to emulate a normal display using less space and can look better too!

PS: for graph displays you can use all 255 as custom characters

[LyosNorezel]

Nice project! Go for it, do not hesitate, if you have the means!

I am using now a display that has 16 rows x 40 columns (8 2x40 or 4 4x40 displays size).

Kool.

But if you consider that a graphical display with 16x40 columns is cheaper than 4 4x40 displays or 8 2x40 displays than why not use it?

Heh... if I had one... I'd use the graphical version. I have a whole ton of old 2x16 and 2x20 LCDs... so I'm just gonna use that. Also... if this project were to be combined with the "Wireless LCD" project already/previously in progress... then you can just imagine the possibilities of this project.

You could use those controllers to emulate a normal display using less space and can look better too!

LOL... probably.

PS: for graph displays you can use all 255 as custom characters Twisted Evil

LOL... true dat.
Lyos Gemini Norezel

[caesar]

So you have all the parts it takes, you are good to go.

Then I would suggest using that controller to emulate a MatrixOrbital protocol as it is serial, simple to implement and you won't need to write a display driver for it.

PM me when you have built it and you are able to test some funky resolutions! Also keep us posted with your progress!

[LyosNorezel]

So you have all the parts it takes, you are good to go.

Yep.

Then I would suggest using that controller to emulate a MatrixOrbital protocol as it is serial, simple to implement and you won't need to write a display driver for it.

That would require an 8bit parallel to serial adapter chip... which I don't have, and I would still have to write the serial driver code. Honestly... I do not have the programming skills to even attempt to write a driver for this adapter. I was hoping, by putting the schematic here... that some of ya'll would be willing/able to write the driver... and, also, help me to improve the schematic.

PM me when you have built it and you are able to test some funky resolutions! Also keep us posted with your progress!

Will do. Do you, by chance, know enough electronics to help me with this adapter?

Lyos Gemini Norezel[/quote]

[caesar]

Hmm... I am more than happy to help you, but I have to insist on going serial or USB! It is easier to hook up and faster, doesn't consume CPU power like the parallel setups.

I'll sketch something later and will post it here.

[LyosNorezel]

Hmm... I am more than happy to help you, but I have to insist on going serial or USB! It is easier to hook up and faster, doesn't consume CPU power like the parallel setups.

I suspect you're missing the point of using the IDE/PATA interface...

1.) IDE/PATA/ATAPI interface (using the 82C55A controller) has the ability to host up to 16 LCDs per IDE/PATA/ATAPI connector (meaning upto 32 LCDs in a computer with 2 PATA/IDE/ATAPI connectors).
2.) With USB you could (theoretically) achieve 128 LCDs... but the bandwidth just ain't there. The most you could realistically achieve, with a decent enough connection for each display, would be roughly 10 to 15 LCDs (Character LCDs... NOT GRAPHICAL LCDs).
3.) With standard 9 pin serial ports you run into many, many problems...
a.) lack of speed
b.) 1 display per port
c.) limited number of ports
d.) legacy free "modern" PCs lacking said port
4.) SATA is utterly untouchable at this point... primarily due to the lack of ICs for a reasonable price.

IDE/PATA/ATAPI will, likely, be around for many more years to come... and has the added benefit of being entirely internal to the computer case (which you can get with USB as well... provided you tap the headers)... meaning Media Center PCs will no longer be required to deal with ugly wires exposed to the world *cough* parallel port LCDs *cough*. Coupling this approach with the previously discussed Wireless LCD project on this forum... you could (theoretically) have 16 to 32 LCDs placed throughout the house (ie., bathroom, kitchen, basement)... making the Media Center accessible throughout the house.

BTW... IDE data transfers are many, many times the speed of USB data transfers... even using 'Nominal' usb transfer specs.

Lyos Gemini Norezel

Edit: I'm not even sure you can do what you suggest with this controller chip... this is a very simple and very old 8bit CMOS Programmable Peripheral Interface. I suppose it may be possible to do a bit-bang SPI interface... but that would be incredibly CPU intensive.

[caesar]

Ok, got it, you want it to be on PATA/IDE.
If you are determined to build this, I think that you are on your own, it is too hard to do just for fun. (Smartie drivers, windows drivers, controllers etc.)

Also I dont think that it is easy to communicate through an IDE controller, windows will most surely not allow you to send blind data directly to a IDE controller.

All I can say is good luck, this insane project really needs it!



Just a few more side thoughts:
USB can output 480Mbits/s, that should be more than enough and it is quite easy to do with just one microcontroller for up to 26 displays in 8 bit mode. I am thinking here at a PIC18F4550 with 36 I/O pins.

If you want to put the lcd's throughout the house than only serial communication over RS485 can help you out! It's the only easy standard to implement for long distances (more than 2 meters that is). Ethernet and radio transmitters are very expensive.
You can have 100m on ethernet without a repeater and up to 4km on RS485.

[LyosNorezel]

Ok, got it, you want it to be on PATA/IDE.
If you are determined to build this, I think that you are on your own, it is too hard to do just for fun. (Smartie drivers, windows drivers, controllers etc.)

I don't think you'd need a windows driver... would ye?

Also I dont think that it is easy to communicate through an IDE controller, windows will most surely not allow you to send blind data directly to a IDE controller.

Hmmm... that would be something worth investigating.

All I can say is good luck, this insane project really needs it!

Hehe... I never could, nor will I ever be able to, claim I'm sane.

Just a few more side thoughts:
USB can output 480Mbits/s,

Under perfectly ideal circumstances (ie., lab conditions), yes. For real world conditions you'll never achieve that speed (I should know... I'm a Computer Repair Technician @ WPAFB).

that should be more than enough and it is quite easy to do with just one microcontroller for up to 26 displays in 8 bit mode. I am thinking here at a PIC18F4550 with 36 I/O pins.

26?!?! at what speed? 2400bps each? Perhaps the PIC itself can go faster... but USB just does not have that kind of bandwidth. If you really want high bandwidth serial connections... you should look into using Firewire. Which, btw... ALL, PROFESSIONAL, audiophile grade equipment with computer connections use... and the most recent version of Firewire has speeds upto 800Mbps with a much higher bandwidth than USB could ever achieve.

If you want to put the lcd's throughout the house than only serial communication over RS485 can help you out! It's the only easy standard to implement for long distances (more than 2 meters that is). Ethernet and radio transmitters are very expensive.

I was thinking more along the lines of a 800-900MHz transmitter/receiver setup. I'd hate to have to run Ethernet cables throughout this ancient house.

Lyos Gemini Norezel


P.S.- Is it even possible to adapt my chosen controller to USB/Serial? I don't have access to a/any microcontroller at the moment... and I cannot think of any other method of conversion. Maybe you can?

[caesar]

You would need a windows driver most surely! In linux something easier could be made, but still unpractical!


Ok, you are also a speed freak (do not take it as a bad thing, I meant well).

Using parallel connections uses host CPU power, a lot! I got the usage up to 14% on a P4 3.8GHz by using a parallel 4x40 display and showing a winamp graph at the best speed possible. The same display wired on serial and USB never jumped at more than 1% CPU usage just for smartie while showing the winamp spectrum!


If you want to use radio for transmission, than what speeds can that achieve? 2400bps, 4000bps? more than 115200bps certainly not and even 33kbps is a fairy dream with these.
50m is the optimal distance without walls etc.

That's why I proposed RS485, you could easily go up to 1Mbps under good conditions.

Either way you won't be able to stick to parallel and send data over long distances. Everything long distance is serial data. Then why bother taking serial data, putting it to parallel, feed it to your chip and then to displays when the serial receiver already can drive more displays?
I don't think that your controller proposal has any use with a USB or serial connection (or any other type of connection).

Your next step depends on the distance between the displays and the speed you want to use.

PS: I got out of a usb PIC without good software optimisation 573,440Bytes/s, that's 4.5 Mbits/s.
Taking into regard that a display uses at most 80bytes that will let you update 7168 displays once a second or 286 displays with 25 updates/second, that's overkill anyway.
As a sidenote, that datastream was used to update 14 times/second a 240x128 BW graphical display.

[LyosNorezel]

You would need a windows driver most surely! In linux something easier could be made, but still unpractical!

Heh... yeah well...

Ok, you are also a speed freak (do not take it as a bad thing, I meant well).

Hehe... yep... speed freak I am.

Using parallel connections uses host CPU power, a lot! I got the usage up to 14% on a P4 3.8GHz by using a parallel 4x40 display and showing a winamp graph at the best speed possible. The same display wired on serial and USB never jumped at more than 1% CPU usage just for smartie while showing the winamp spectrum!

Meh... for my purposes... I have CPU power, aplenty, to spare.

If you want to use radio for transmission, than what speeds can that achieve? 2400bps, 4000bps? more than 115200bps certainly not and even 33kbps is a fairy dream with these.
50m is the optimal distance without walls etc.

Depends on the transmitter/receiver you use.

That's why I proposed RS485, you could easily go up to 1Mbps under good conditions.

That would be nice... but running RJ45 throughout this ancient house is a nightmare I'm not willing to face.

Either way you won't be able to stick to parallel and send data over long distances. Everything long distance is serial data. Then why bother taking serial data, putting it to parallel, feed it to your chip and then to displays when the serial receiver already can drive more displays?

With my application... it'd be parallel data... to controller... to parallel LCDs... to parallel serial adapter... to RF transmitter. Also... using the AM radio band... with ~1watt of radiated power... you should be able to achieve a range of ~1/2 to 3/4 mile (0.804672 to 1.207008 kilometers).

I don't think that your controller proposal has any use with a USB or serial connection (or any other type of connection).

Heh.

PS: I got out of a usb PIC without good software optimisation 573,440Bytes/s, that's 4.5 Mbits/s.
Taking into regard that a display uses at most 80bytes that will let you update 7168 displays once a second or 286 displays with 25 updates/second, that's overkill anyway.
As a sidenote, that datastream was used to update 14 times/second a 240x128 BW graphical display.

Heh... that's very impressive for that crappy USB connection. I'd still go firewire over USB if I needed a serial connection.

BTW... caesar... I hope you're still watching this thread...

Do you know if there is a driver framework or an SDK for developing new LCD display drivers? I've been looking around the forum... but the only thing I'm finding is a framework for plugins. Not very helpful when you need to write a new driver.

Thanks
Lyos Gemini Norezel

[caesar]

Sure I'm watching!

I think that it's only a pain in the "parallel" to get parallel data out of the pc to make it serial then transmit then back to parallel for the displays.
It would be much more easier to just rig the transmitters to a serial output, then transmit data and the receiving side will take care of the LCD.

That way you would only write a display driver with a custom protocol to talk over a serial line (COM or USB) to multiple displays, maybe assign them to different parts of the screen by using more lines, so all can be updated in real-time.

Firewire is too complicated for practical home use and no simple way exists to communicate over it.

The most easiest way of communication in a display driver is over the serial line.
Enough said about serial lines.

You can check the whole Smartie project by visiting the CVS on sourceforge: http://sourceforge.net/cvs/?group_id=122330
The display drivers are (most of them) written in Delphi.

Keep us posted!