Just bought some displays at a amateur radio show; 2*40 VFD and some (Korg like) SEIKO 320*200 Pixel LCD’s.
Am wondering how much hassle it will be to get the SEIKO G321DX1R1AC displays working on MIOS …they are based around a SED1330 chipset. ?
Also have some very large VFD displays here too …they are 12" by 2" ! …and is based on two OKI c1162 chips + a 80c318h PIC …darn :] …hope its compatable with standard (-serial-) protocol …they were made by telesincro of spain. …not as fussed about getting these working ..though would look awfully nice in a large form midibox sequencer
…is there a possability of getting those SEIKO’s on the go ?
…can get a ton more of these bligthers soon ..should anyone else want any. They are Cold cathode backlit …and have a ‘white’ pixels on black configuration …will fire one up soon and check out the actual colour ..most likely to be blue.
Should be able to do them for around £15 if they’re of any intrest…:]
No, there is no driver available for this display yet. The data interface is similar to T6963C (the appr. driver can be found in the MIOS download section), but the commands are different and the datasheet doesn’t make clear, if the pixels are oriented in a horizontal or vertical line. On horizontal oriantation the display will be very slow - unless the drivers gets use of the inbuild character generator. But the generator doesn’t support customized fonts with any size (e.g. 5x8 or 24x16) - so, not a good choice for MIOS fonts
Datasheet seems to suggest horizontal ‘refresh’; and mentions that there is a standard 8*8 rom charset & space for 32 custom chars.
Also the screen should be addressable pixel by pixel in graphical mode, though that’ll put a dent in cpu cycles.. How about a pic dedicated to rendering the graphics ..probably too time consuming to code ..tho who knowz
"The Seiko G321D LCD was surprisingly easy to work with, thanks to the SED1330F controller. To write a command or data to the LCD, it is written to the data port (Port B) and then a command is written to the control port (Port A) telling the LCD to read the data port. Once the primitive functions (WriteCommand and WriteData) were written and the correct command definitions mapped, working with the LCD just involved address calculations and function calls. "
How about a pic dedicated to rendering the graphics ..probably too time consuming to code ..tho who knowz
This kind of thing is why I’m trying to make a IIC slave driver for the PIC, so in applications which require a little more cycles than one core can handle, a second core could be controlled by the first, and do all the hard work… Or a third core… etc etc…
This is turning out to be rather difficult though, so although I’m sure I’ll finish it, if it is possible, it might be a long time :(
..probably too time consuming to code ..tho who knowz 