Hi, the KS0107 and KS0108 chipset are both drivers and controllers in one, they have the IO's and shift registers to control each pixel - but also the field memory (RAM) to refresh the display. So whilst any micro attached to these has to 'draw' text, essentially the LCD has an inbuilt controller - albeit with limited functionality. It stores the bitmap in memory, and constantly refreshes the display without intervention from whatever is controlling it. Draw a pixel at one address location - and it'll stay there. The micro controlling it treats the LCD is memory, writing to address locations.
The larger LCD you posted has no such controller. It requires clock and data lines to 'scan' across the display and refresh the image frame from memory. Much like a raster scan on a TV. That is pretty much the main purpose of an LCD controller - character generation, cursors, and scrolling/rotation are just handy extra's. So, clocking in data across a line, then moving to next line before flying back to the top, if you draw a pixel in one location, unless you draw it again on every frame, it fades, so it require constant refreshing, usually at around 60-80Hz. Doing this with a microcontroller, a few numbers to show it *is* possible, but no-where near as straight foward as dealing with the KS108.
320 x 240. 4-bit interface (writing to 4 pixels at a time). Refresh rate 70Hz.
320 horizontal pixels /4 = 80 writes per line. Often some delay is required before a 'end of line' sync pulse, so say this is 82.
240 lines - again, some 'dummy' lines are added as a delay, so call it 244 lines.
number of writes per second = frame rate * lines * writes per line = 70 * 244 * 82 = 1400560. So you'll need to provide a new 4-bit nibble at 1.4MHz. Given that data must be read from a memory (internal or external) you can see that it'll take a good 4 cycles per 4-bit write. So, even without drawing anything on screen, printing fonts, your micro will be too busy just taking data from memory, and sending it to the display. Fast micro's, like AVR's (20MIPS) and perhaps the PIC18F series might be able to do this.
Also, memory, 320x240 is 40bytes 240 = 9600bytes = ~9.4Kbytes.
It is such a mundane task, moving data, doesn't require intelligence, just counters, but at a speed beyond that of most 8-bit devices. And it seems like a waste to have all the goodies of a fast PIC or AVR just to read from ram and send to a port.
Sorry for the pesimistic 'numbers' post. I'm not trying to discourage folk from using the display, 320x240's are awesome! (smaller pixels, finer detail, lots of text and cool symbols) just that without a dedicated controller IC, or perhaps programmable logic (just counters and memory really) it can be very difficult to drive.
All that said, despite the cost of a controller IC, they don't actually require much in the way of external circuitry. SRAM (usually 256k, 32k x 8, very cheap and common) a crystal oscillator, and thats pretty much it. The VEE LCD drive voltage for 320x240's is usually around -22V @ ~2mA (usually negative, sometimes positive!) which can also be a source of headaches. The 128x64 displays which only require -8V often have this DC-DC converter built in as cascaded ICL7660's.
Again, sorry for the long post, I got a bit obsessed with LCD's back in the days of sticking them on ones PC to display pointless information and my mind is stil full of crap about em
Edit: nice scale on that LCD! Even graphic LCD's with controllers can be a ***** to drive, but the ability to address individual pixels makes them so versatile for displaying information in different ways I tend to use the 128x64's over character LCD's these days. Bargraphs, custom fonts, always makes projects/prototypes look sweeet!