I recently purchased a 240x64 LCD based on a T6963C (https://www.sparkfun.com/datasheets/LCD ... T6963C.pdf) which I used as 40x08 text display, and I noticed that there are some even bigger displays out there.

So I bought an even bigger 240x128 LCD (40x16 text mode) with a chip similar to T6963C (seems to be fully comptatible) and was pleasantly surprised that it works (almost) out of the box.



I had to break a jumper (JP3) that connects FS (font select) to ground in order to be able to select a smaller font. This seemed to be a common trait in those displays, as both of mine had this kind of jumpers.



Other than that, all my code that I wrote for 240x64 worked without any changes (except changing row count to 16 in my software). Both my 240x64 & 240x128 support dual text & graphic modes, however I haven't tried drawing graphics yet.

The screen is rather big and is around 11cm tall (1cm taller than my 20x10 cm SBC). It seems to work perfectly @ 2 MHz (I'm underclocking my bus via ATF16V8B when LCD/EN is asserted).




Also, /RD & /WD are separated (as opposed to HD44780).

Finally, potentiometer needs to be wired to GND/V0/VOUT (VOUT is a dedicated -10V pin), as opposed to HD44780 GND/V0/VCC.

I still find 240x64 (40x08 text mode) sufficient for my needs, and it also exposes some important parts of my SBC (like ROM ZIF socket & pin headers). However, this 240x128 display might be nice for some notebook-style build, like mounting it at 45° angle. I really love LCDs, I use them as my primary output device. They also make the SBC more standalone and give it some TRS-80 Model 100 vibes, and they also save me from having to figure out a video interface.

EDIT: There are 44 pins total (actually, 66 if you count the surface pads as well), but they are just same 22 pins repeated. When buying them first time, I was afraid that there wou;d be 2 separate controllers (some LCDs have two controllers for left/right half of the matrix), but this one is actually a single-chip display.

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Wow, that's super cool. Also kind of expensive, compared to the $5 LCDs I'm used to working with. I couldn't find one of these for under $40. Still, it might be worth it, given the time it takes to figure out a video interface!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Actually, the 240x128 I bought cost ~17$ on Ali, even cheaper than my 240x64 (~18$, also Ali):

Here are the ones I have:
240x64: https://a.aliexpress.com/_EzlcWDr
240x128: https://a.aliexpress.com/_EIb0p5b

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Ah great, thanks for the links!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

that still seems pretty expensive for a monochrome screen IMO.
on AliExpress you can get 480x320 @ 65536 color screens (with parallel interface) for <10 USD: https://www.aliexpress.com/item/1005004858242452.html
and there are also SPI variants of those TFT Displays for even cheaper.
though the TFT Displays are physically much smaller than the one from your image, which can either be a good or bad thing depending on your eye sight

TFT displays look really nice and cheap indeed. The main reason why I still use LCDs is because they come with a built-in character ROM, so my '02 doesn't need to do any rendering. Though it really might be a cool idea to try & build a small video circuit with its own character ROM that would render characters onto TFT!

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Not sure that building external hardware to draw characters on a TFT display is really worth it.
I don't know how the LCDs work but the TFTs have built in controllers and you interface it by sending it commands.

So you would need to make up your own command to place a character, have the hardware capture that, and convert it into a small sequence of "write to GRAM" commands.
And at that point it's likely simpler to just have the CPU do it. Plus a simple monochrome character set only takes up 2kB of ROM (or better RAM so its changeable)

I'll have to hook one of those up one day and work on a simple driver, but that might take a while since there are a lot of different controller ICs on those things.

Gosh, I think it might be worth it. You might use a serial connection from the 6502 to a little 8-pin ATTiny85 or PIC16F15313 which would contain the character font tables and be capable of driving a TFT display SPI interface much faster than our 6502's can. Coming up with a command set and protocol to set X and Y coordinates and place a character onto the display shouldn't be too difficult (there's probably a bunch of Arduino libraries available that will do just that).

Ok yea, having a seperate Processor do it is much easier than trying to build something in hardware (which i interpreted as in using 74' logic, CPLD, or FPGA).
but beware the feature creep! it starts with the TFT Display, then you think "might as well use the SPI interface for the SD card too", and bam now your microcontroller draws Graphics, outputs Audio, handles File IO, keeps track of time, and brews you a coffee all at once with a single command from the 6502

anyways i should really look into trying to connect an Arduino to my SBC via SPI (with the arduino being the slave of course, as i only have slow software SPI on the SBC)

I hooked up a TFT display like the one you referenced to my first 6502 computer, it worked quite well. I think it was 320x480 resolution, 16-bit colour, with a fairly easy-to-use parallel interface, even for a complete novice - I'd only just understood how the CPU, ROM, and RAM could work together and share buses.

Although it was a command-based interface, the display I got didn't have much in the way of built-in drawing operations (lines, region copy, etc) - it mostly just let you define a rectangle and stream pixels into it. But it did support hardware scrolling I think.

The main problem I had once it was connected up was the volume of data to send to the display - as each pixel took two bytes, drawing was fairly slow. So as you guys are suggesting, I wanted to add some circuit in the middle to help the CPU out. I came up with a crazy design for allowing the CPU to write an 8-bit RRRGGGBB byte and having the intermediary layer split it into 16 bits RRRRRGGG/GGGBBBBB then send both bytes to the display on consecutive clock cycles while the CPU was busy fetching the next instruction, but it was way beyond my capability at the time, didn't work, and I didn't have the experience to really know how to diagnose it. Looking back, with a better design I think this could be not too complicated to do, and would double the throughput.

The other things I was considering were writing the same pixel four times to the display, to essentially lower the display's resolution to 160x240; or implementing some sort of palette expansion mechanism so the CPU would send one byte, and the circuit would write 8 pixels in a row, substituting definable colours for the 0s and 1s in the byte. There goes that feature-creep! But as it didn't work, I focused my energy on learning how actual 80s video output circuits worked, and replicating those.

You're absolutely correct! For example, when I started to design a PIC based serial LCD backpack many years ago I realized that the HD44780 controller DDRAM (display RAM) memory map included some unused locations and the PIC could easily display data written to those otherwise unused locations on 7-segment displays. And so I designed a simple serial backpack that could support either a 1602 or 2004 LCD display or a 4-digit (addressable) LED display. A mockup of three backpacks on the same serial drop is shown below. Feature creep might include using some of the other unused DDRAM locations for 8-bit input or output ports, an LED PWM brightness level setting, a Real Time Clock, a serial-to-I2C and/or serial-to-SPI interface, etc., all on a single serial connection and using a relatively simple HD44780 control protocol.

yep! they're pretty easy to hook up and use. similar to character LCDs.


oops sorry, i misremembered the capabilities. turns out that most of those commands were implemented in software by the arduino library i was using to test them.
but yea rectangular selecting, writing, and scrolling are hardware features.


hmm, mapping 8-bit colors into the TFT's 16-bit colors seems doable.

using an IDT720x FIFO, and a ROM acting as LUT, all hooked into a CPLD (like an ATF1508) with an SPI Core+Logic, you could have the CPU dump all data into the FIFO, and then go do something else while the SPI core "slowly" chews through it's stockpile.
this not only increases the speed at which the CPU can push data by shrinking the Pixels down to a single byte (or even smaller), but it also makes better use of the bandwidth to the Display.
because the SPI Core feeds itself at maximum speed from the FIFO, instead of having the CPU continuously checking the busy flag, and then waste cycles loading and storing the next byte before going back to checking the flag. (though of course a parallel interface wouldn't have that issue)

though you would need to have 2 write ports to the FIFO, one for pixel data which goes through the LUT first, and one direct connection to the SPI core for everything else (like commands).
plus you would need a second port to the SPI core since you also need to be able to read from it as well, and the FIFO is unidirectional.
or alternatively:
have a write only port (through the FIFO and LUT) for pixel data, and a seperate read/write port for normal SPI operation (and to access some internal status/control register).

godammit now i'm also getting dragged into this idea!

i'm already thinking about the logic design and if i could fit this on an expansion card for my SBC.
i do have some spare ATF1508's, IDT702's, and SPI TFT Displays lying around....

Haha, I can relate. My SBC already has I²C & SPI buses together will all sorts of bells & whistles, including a serial EEPROM, a temperature sensor, an RTC, an uSD card module, and pin headers for even more stuff. That's why I'm on revision 17 already... (But honestly, adding uSD and writing a simple FAT16 driver was probably one of the best decisions I've made with my SBC: It's relatively faster to juggle with an uSD card rather than reprogram my entire ROM every time.)



Yep, that's exactly what I was thinking about, too. Since I already have SPI support through my VIA, might as well use it for TFT "backpack" by dedicating one more pin to screen controller's /CS. I'll likely go with ATtiny85 - I have a thing for small MCUs (both size & capabilities) and other kinds of "underdog" chips (in a good sense), probably for the same reason why I love 6502: to put myself into some limitations and try to see what I can do with them. Also, I have plenty of ATtiny85's. Also, IIRC, ATtiny has hardware SPI which will make things even more easy. However, I'm not sure if 6 pins will be sufficient: ATtiny85 will need to act as both SPI master (for controlling the TFT) & SPI slave (for being controlled by 6502), so there might be issues with sharing MOSI/MISO/SCK lines.

As a last resort, I have few ATtiny28's - I bought them specifically for cases when I need more pins (I originally planned to make it an on-board PS/2 keyboard controller for a built-in keyboard).



You can also do interlacing for some extra retro style points and save roughly half of clock cycles. (Though the effect will probably be barely noticeable.)

// Off-topic: anyone has any ideas on making use of lots of spare PCBs? *cough-cough, jlcpcb*. I even considered using them as base stands for the working boards, sandwitched via standoffs, but it looks kinda ugly. I wish I could get 1 instead of 5 for the same price: at least I wouldn't be polluting the land with my prototypes.

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Unexpected. [ed: this turned out to be a problem with phantom r/w due to some clock timing that I fixed in another thread]



I picked up one of these LCDs on eBay. Got it hooked up with VIA and thought I was nearly there...

Curious how the output order is (slightly) scrambled, and varies a little on each reset. The routine lcd_putc is just writing to the LCD using %1100_0000 for ADP auto-increment after below init sequence. Waiting on required status bits /before/ every write. All the internal routines preserve X (otherwise I'd imagine much more scrambled output).

%0100_0000 + $00 00 ; text base $0000
%0100_0010 + $00 $04 ; gfx base $0400
%0100_0001 + #40 00 ; text area offset 40
%0100_0011 + #40 00 ; gfx area offset 40
%1001_1111 ; gfx (text attr) on, text on, cursor on, blink on
%1010_0000 ; underline cursor
%1000_0100 ; internal CG, text attr mode
auto-write fill $0-$7ff with zero
%0010_0001 + $00 00 ; set cursor pointer $0000
%0010_0100 + $00 00 ; set ADP pointer $0000