6502.org

Depends on the size screen Greener - in terms of smaller screens, 128x64, they are cheaper then some, more expensive then others. Same size screen from mouser costs like $28/29, where it's only $25/26 from crystalfontz, for single orders.

Now for color, that hantronix is the first I've seen for color in a small size that a person could obtain... Little expensive, but very cool.

I'm afraid this LCD module greatly exceeds the bandwidth capabilities of a realistic 6502/6522 combination. Each scan line must be shifted to the LCD module. The vertical refresh rate, from what I read on the datasheet, is 80Hz. With a total of 76800 pixels, sent as 4-bit words per shifter clock, a video bus bandwidth of 1.536MHz is required. While it's theoretically possible to do this with a high-speed 6502 or 65816, it is not technically feasible, as nearly 100% of the CPU's bandwidth will be consumed by dot shifting. (Shades of the Atari 2600 here!)

Maybe a 128x64 LCD module would work. But 320x240 is still quite a bit much for the 6522.

Fortunately, it seems pretty easy to build a video controller for an LCD panel.

> I'm afraid this LCD module greatly exceeds the bandwidth capabilities
> of a realistic 6502/6522 combination. Each scan line must be shifted to
> the LCD module. The vertical refresh rate, from what I read on the
> datasheet, is 80Hz. With a total of 76800 pixels, sent as 4-bit words per
> shifter clock, a video bus bandwidth of 1.536MHz is required.

No, because you only have to shift the data in once, not every time there's a refresh. You don't have to send any more data after that until you want to change what is displayed; so the info does not necessarily need to be fed over the interface very fast. The ICs on the LCD module take that info and put it in their memory and take care of the multiplexing themselves. For as long as you want to view a motionless pictures on the LCD, the interface can be dead; ie, no signals going over it at all. I'm sure if there is motion, you only have to give it info to update the part you want to change. It is my understanding that separate LCD graphics controllers beyond the ICs built into the module just automate the task of figuring out which dots to turn on if, for example, you want to draw a line or put up some text with a specified font and size and at a certain location. They're called LCD modules because they do have the driver circuitry built in. If you just got a raw LCD, then yes, the processor would be very, very busy keeping it going.

Where are you seeing this? I reviewed both the data sheet and the app-note, and they both indicate that a continual refresh is required. If what you say is true, then either I'm sorely missing some important detail, or their datasheets leave a LOT to be desired as far as clarity is concerned.
I don't place much faith in the distinction between a "module" and not a module. I've seen the VGA-resolution displays behave *precisely* like VGA monitors -- if the continuous video feed dies, the display goes blank. Yet, they were still considered "modules."

Obviously, I don't refute the possibility of the LCD maintaining a flip-flop for each pixel. It'd be nice if it did. But in reviewing the data sheets, I apparently skipped over the section that reported its static behavior, because I just didn't see it documented. I only saw reference to its dynamic behavior.

> > No, because you only have to shift the data in once, not every time there's a refresh.
>
> Where are you seeing this? I reviewed both the data sheet and the app-
> note, and they both indicate that a continual refresh is required. If what
> you say is true, then either I'm sorely missing some important detail, or
> their datasheets leave a LOT to be desired as far as clarity is concerned.

Yeah, I'm finding their data is pretty sketchy. Their ap. note at http://www.hantronix.com/down/t6963app.pdf , although it's for a 240x128 graphics module, does however specifically say it has 8K of display RAM, and they show a program for feeding it with an 8051 running 1.3MIPS.

> I don't place much faith in the distinction between a "module" and not a
> module. I've seen the VGA-resolution displays behave *precisely* like
> VGA monitors -- if the continuous video feed dies, the display goes
> blank. Yet, they were still considered "modules."

As I understand it, those are intended to address a market where a VGA output is what's available, and convert it to the signals necessary to drive the LCD on the module. I know virtually nothing about VGA, but I'm sure it is designed to be friendly to the way a CRT works, which is quite different from how an LCD works. The info on the 320x240 I mentioned earlier specifically said its duty cycle was 1/240, which confirms to me that they do an entire row at once and every one of the 320 dots in that row have to be fed at the same time by the column drivers. In the character-only modules, 1/8 and 1/11 duty are common. Even multi-line displays are often addressed as if they were one longer line of up to 11 rows of dots, with more dot columns than you might expect. OTOH, the 1-line, 16-character LCD on my workbench computer uses 1/16 duty, and acts like two lines of 8 characters each but they're stuck end-to-end instead of one on top of the other. The two lines each being eight dots high is where the 1/16 duty comes in. (It's 16 rows of dots.)

Concerning "module" versus "not a module": I have also used an AND brand LCD with four 7-segment digits plus decimal points and colon. This LCD was not a module. It had 34 pins in two rows IIRC, and no electronics at all. I used the National MM5453 40-pin IC which takes the synchronous serial input and generates the necessary AC to keep feeding the LCD so the processor wouldn't have to babysit it. Now that I think about it, I remember also using a similar module that was wrist-watch size. That one was a slight challenge prototyping with by hand since it needed the zebra strips to connect to the circuit board.

Take a look at the NTE 879. Its an RGB to NTSC/PAL encoder, taking R,G,B, and CSYNC as inputs and producing NTSC or PAL composite video out.

Daryl

I picked up an apollo 320x240 momchrome LCd from my local electronics surplus store, brand new, for $25. I just picked up a neat power supply from Jameco for $7 which has the +5v, -26v, and 1000vac need for the display. The +5 runs the logic, the -26v runs the display, and the 100vac runs the CCF backlight.

The connections are just as you described Garth, 4 bit data, a load clock, line clock, and first row clock pin. However, the docs don't mention anything about onboard storage and I figure it requires a continuous refresh. I'm thinking of using the phase 1 period to refresh it transparently and having the CPU dedicated to writing the text fonts or graphics. The whole thing will be quite compact when done!

Daryl

Perhaps this is true for their 240x128 displays; however, their 320x240 displays (which is what I thought we were talking about all this time) require a dedicated external controller chip. Please see http://www.hantronix.com/down/3224app.pdf .
Yes, that is my thinking as well. But I don't see them including a full 10KB of RAM on the LCD module. According to their timing diagrams, you assert the FLM signal to start a new frame, then you clock in parallel data (yes, in a weird hybrid row/column format, as Tancor previously described) with CL1, and CL2 is used to "serialize the data to the display" -- e.g., FLM is analogous to a vertical sync, CL2 is analogous to a horizontal sync, and CL1 is analogous to a dot-clock.
The memory requirements for a 16x1 or even a 40x2 character matrix display isn't anything like a 320x240 display, especially one that is color. Also, the pixel change time seems to be so slow that a direct drive from a microcontroller is quite economical.

I don't know. I'm not saying it's impossible; perhaps they physically include one flip-flop per pixel, placed right where the pixel is located (made with transparent semiconductor material; I remember reading about this technology back when super-twist displays first made their debut in laptops in Radio-Electronics magazine). But I do not recall seeing mention of this in their datasheets, and therefore assume that it doesn't have it.

At any rate, I don't think we should continue along these lines. Continual refresh versus transparent storage appears to change on a module-by-module basis, and also with time (e.g., I wouldn't be surprised if the 128x64 LCDs of 5 years ago were continual refresh, while today they're not). I'm just glad their prices are coming down.

$25 for a 320x240 display isn't bad. You can do a lot with a 320x240 display, even if it is monochrome. Still, monochrome, non-interlaced NTSC isn't hard to produce -- it's only when you introduce color that it becomes a nightmare. 8bit mentioned a chip that could assist in the production of color NTSC. I envision PAL as basically the same as NTSC electrically speaking, with only minor timing changes and a different number of total lines displayed.

Still, driving a VGA monitor is almost as easy as driving a continual refresh LCD panel -- all the signals are basically the same. The difference is the addition of the RGB DAC, which can be built using discrete components fairly inexpensively and easily.

Unfortunately, I didn't get a substantial level of interest for my proposal to justify the expense of a programmable chip development environment, the R&D costs associated with each project, and documentation costs. A total of 3 units from Tancor and a possible 50 units from candle, priced hypothetically at US$30 each, would not even come close to making up for the development costs. It wouldn't even pay for the chip programmer. And I got no response back whatsoever on other kinds of support chips; therefore, no other ways to amortize the investment I would have made.

I just sent and E-mail to Hantronix' applications engineers. We'll wait and see what comes back.

8bit: 1000VAC???! wow-- that's enough to scare me off! not for safety reasons, but just thinking about the electrical noise getting into nearby circuits through capacitive coupling, etc.. I guess some good shielding is in order. I picked the particular 320x240 module I mentioned because that one had the LED backlight option, not EL or CCFL.

BTW, they have them with touch screens too, but I hate those things! They just put them in at the ATMs at our bank, and you have to look through the grime left by other people's fingers from the french fries they were just finishing up. Then with the paralax (or just bad design or programming), I've gotten wrong selections when I thought I pressed exactly on what I wanted. Sometimes it wouldn't respond until I pushed hard enough that it seemed like I was about the break the glass (or my finger) even though it was a brand new installation.

I should have said, the open circuit voltage is 1000v, the voltage with the CCF is 340vac @4mA. And yes, it has its own separate wiring harness to go directly to the power supply. I would have prefered an LED lighting option, but the price was right. The jameco power supply also supports dimming options in 10% increments, all controlled by 5v logic levels.
I could have gotten the touchscreen version for $30, but I wasn't looking for that. I think they still have about 10 of those models left.

Daryl

Touch-screens would probably be a good choice for benchtop diagnostic equipment, as it'd replace all those buttons that would normally be there otherwise. Other than that, I agree completely with your assessment. Unless you're working with pen input, touch-screen LCDs really aren't all that great.

I just thought of something really, really crazy though. If you drove a 6502 at 8MHz and at least one VIA chip at 8MHz, you could drive its serial port at 4MHz. That can be used to feed a video circuit the dot data. OK, yes, the CPU would have to babysit the serial port -- since the max usable output speed on the VIA is Phase2 / 2, the CPU will have 16 clock cycles until the serial port empties, thus giving it some amount of time to fetch the next byte to output. When driving an NTSC signal, you can get up to 200 pixels or so across that way. VGA would be about half that resolution -- either way you look at it, it's still better than a 2600. It'd be good enough for a simple game system. The color "palette" would come from ports A and B; the serial output just controls octal 2:1 MUX, and the output of the MUX drives the RGB-to-YIV encoder chip (which you can do without if driving VGA directly). The serial clock output on the VIA chip can even be used to drive a sprite engine add-on.

I think it's slightly better this way than the Atari 2600 way anyway; for NTSC, you can create an interlaced display, with the odd field containing graphics, and the even field containing just black (so the CPU has about 16ms of time to do game mechanics work). For VGA, you just leave every other line black.

Anyway, I just thought of it on the drive home from school today. I'm tired. I'm going to take a nap. But you can't argue, that would be the simplest, cheapest video solution I personally can think of.

Monday I E-mailed my question about refreshing LCD data to Hantronix. Wednesday, after still not having gotten a response, I called and got their applications engineer. Unfortunately he didn't speak much English. He apologized that he had so many customers he couldn't keep up with the E-mail, although I doubt that would be a problem if they had someone who could speak English and type. He took my name and number and promised to get back to me. Today (Friday) after still not having heard back from him, I E-mailed the local Hantronix rep early in the day, and have not gotten a response from them either. Maybe Monday. I didn't have this trouble with them before because I've only used their intelligent character LCD modules which interface the same as everyone else's I had used, so I didn't need technical help. Maybe I should try Optrex, another favorite of mine.

In the meantime, I remembered I had bought some LCDs years ago at Timeline Inc., a little surplus company that majors in LCDs. I looked them up again tonight and found they still sell LCDs of many kinds, from $4 to $40, including some 640x480 VGAs for $15. It won't cost you much to experiment. See http://www.timeline-inc.com/lcd.html7

Garth

Anyone here ever heard of the 6578? It's a single-chip clone of the custom parts from Nintendo's NES. So it's code compatible with the 6502, plus it has video and sound.

If I was going to build a computer (which I haven't, I might try it eventually) I'd go for one of these. But that's just me (I already know how to work with the NES, I'm biased), I don't know much about hardware so I'm simply offering a suggestion. Maybe it's an easy way to get video output to TV, or maybe not. Any opinions?

It's on this site: http://www.ntkhk.com.hk/ under "Sino Wealth / products / datasheets / TV game".

I have a pinout on my site, also.
http://nesdev.parodius.com/6578_pinout.pdf

Now after 8 days of trying, I think I finally got some of the information I was looking for. It was mostly on Hantronix' website, but not obvious. The answer is that specifically the 320x240 and 640x480 LCDs are most often used where a VGA output is already available, so most variations of these LCD sizes are not provided with the types of controllers we were looking for like other graphics LCDs are. There are exeptions though.

http://www.hantronix.com/down/3224n-1.pdf is the short data sheet on HDM3224N-1 320x240 graphics LCD, which does have such a controller, signified by the "N" in the model number. The fuller specification is at http://www.hantronix.com/down/s3224n-1.pdf . The block diagram on page 9 shows the integrated SED1335 controller and the 32Kx8 RAM. The HDM3224NL-1 (with the "L") has LED backlighting that does not need the high voltages and I expect makes a lot less electrical noise. They also have an HDM3224LN-1 which has the controller and LED backlight in the same module, but I haven't found that on their website. I have the spec here because the applications engineer E-mailed me the .pdf file.

Interfacing a 320 x 240 Graphics Module http://www.hantronix.com/down/3224app.pdf (mentioned by kc5tja) describes a possible interfacing environment and then details an application with an 8-bit microcontroller driving an Epson/SMOS SED1335 LCD controller (which is built into some of the graphics LCD modules). This note includes schematic, flow chart and sample software in 8051 assembly language. (59k)

The ap. note at http://www.hantronix.com/down/acontrollers.pdf is an LCD Controller Selection Guide that suggests compatible controllers to be used with 320 x 240 and 640 x 480 panels. (25k) This is the one that says that specifically the 320x240 and 640x480 LCDs are most often used where a VGA output is already available so which variations of these LCDs are not provided with the types of controllers we were looking for like other graphics LCDs are.

Again, there are loads of LCD manufacturers. I looked at Hantronix' website because that's one brand I've used before, and I didn't want to spend hours and hours and hours looking at websites and long data sheets that download at 28.8kbps on my dial-up connection.

This isn't quite the right topic - but, as I'm working on video, I'll post it here.

A quick update - I was going to work with serial communications. I came across a little "glitch" in my design, and since my final setup will actually be more of a parallel solution, I'm not going to pursue it. My glitch? Two interrupt levels - the high priority interrupt is for video, the low priority interrupt is for the serial communication. Lots of garbled bits later, I'm just going to leave it where it lies.

My 3rd generation design of video should support a full 320x200x256. But, the wiring will be getting fairly complex. (Well, for me. 2 32K SRAM, 2 8-bit counters, 2 8-bit flip-flops, 2 PIC microcontrollers. Lots of wires.)

Up to now, I've been breadboarding everything. When will that not be good enough? If nothing else, I'll need a more "permanent" solution for the video when it works. (I need to build the EEPROM programmer, after all, and then add a 6502 to test the video interface. I've only got so much breadboard space.)

I had the thought that I'd solder everything together, but that'll be a mess. I don't think I want to print up a board - that is something I'll do when I get a functional computer (er, 2005 or so ). Any suggestions? I'll bumble along either way, but I'd appreciate suggestions...