TFT display module prototypes for P2 Eval headers
Rayman
Posts: 14,762
Going to see if can get rid of closet full of TFT displays by making boards for them that plug directly into P2 Eval board style headers...
Just ordered prototypes of 4 different styles for these displays.
Just got a few of each and not with ENIG because pretty sure something will be off.
Hopefully, can get them right on second try.
Added a nunchuck and grove i2c connection on all of them. Might regret that, we'll see...
For the 3.5 and 4.3" displays using two octal latches (SN74AHC573) to expand 8-bit bus to 24 bits..
Tested this out already: https://forums.parallax.com/discussion/169596/24-bit-color-on-4-3-tft-using-just-16-pins
704 x 788 - 687K
Comments
Here's the layout and specs for the 2.4" LCD.
product page: https://newhavendisplay.com/2-4-inch-standard-resistive-tft-display-with-screen-printed-icons/
The buttons make the touch code a bit complicated, but P2 has lots of memory, so shouldn't be a problem.
Think have about 100 of these and you can still buy them...
The connector solders directly to the top layer and conveniently tucks under the display.
Driver would run in 8-bit 8080 mode for fast updates. This one also has a frame marker output that is connected to P2 that would allow you to avoid tearing.
Here's the layout and datasheet for the 3.5" LCD. This one is very high quality, should be perfect for retro games.
Only real problem is that it doesn't include a power supply circuit, so need to provide that on this board, making it difficult to assemble...
On the plus side, have hundreds of new ones of these in the closet...
The connector is on the back of this board and the cable and connector are tucked under the display.
For this and the 4.3 displays, using a trick to expand 8-bit bus to 24 bits using two octal latches SN74AHC573.
Another issue with this one is the need for an SPI interface for initialization. Going to try sharing i2c pins to make this work.
Also, running in DE only mode with no hsync or vsync to save pins.
Have to remember to init LCD before using I2C.
Here's the layout for the 4.3" display with no touchscreen (makes it brighter). This one is easy to assemble.
Product page: https://newhavendisplay.com/4-3-inch-standard-tft-without-touchscreen-no-controller/
Have several new ones and they can still be bought.
The connector on this one easily folds over the edge of the board, so don't need a cut out in the board for it.
Here's the layout for the 4.3" display with resistive touchscreen.
Pretty sure this is the right datasheet for it...
Got several new and lots of slightly used ones of these.
The connector on this one is very rigid and wouldn't like to be folded over the board, so made a cut out in the board for it to go over.
Fixed up the 2.4” pcb with the Parallax style bottom feed headers. Trying to port some old P1 code to P2 for this now. If there’s trouble, looks like @Cluso99 already has a driver for this type of display chip:
https://www.parallax.com/320x240-lcd-driver-for-ili9341-controller-and-xpt2046-touch-screen/
I see now that the above driver is spi and not 8 bit. Still could be adapted though.
It's slow as hell compared to what it could be, as there's no PASM, or smart-pin I/O, or streamer code - all SPIN2 (surely someone else could do better), but I wrote an 8-bit parallel engine mainly for LCDs - I use it in an ILI9341 driver. If nothing else, it could be used as a reference to get up and running.
Cheers
@avsa242 your code looks much nicer than mine! I’ll give it a shot.
Thanks! Of course, looking at it right after I posted that, I find a bug
. In
DeInit(), I clear out 109 longs of VAR space, but there're only actually 86 longs worth of variables declared. When I first wrote it, I think I started with more stack for the engine, and just forgot to change it when reducing it. Will push a fix shortly...EDIT: Fixed
@avsa242 Seems to be working. Added a read block function so can check ID:
BLKDATRD: ' Read bytes ptr_buff := _ptr_buff ' cache local copy of ptr xcnt := _xfer_cnt-1 ' and number of bytes pinf(D7_0) pinh(DC) pint(RDX) 'read dummy byte pint(RDX) repeat i from 0 to xcnt ' write data to ptr_buff pint(RDX) byte[ptr_buff][i]:= pinr(D7_0) pint(RDX) _io_cmd := IDLECool thanks! Will try that out. I wanted to add read support eventually for things like that but hadn't gotten around to it...
Cheers
Got the 2.4" TFT resistive touch working with P2 Eval.
Testing so far with this Spin2 only driver.
This paint app uses left side of screen to select foreground color and the buttons to clear the screen with choice of 5 background colors.
I'm hoping to get this working with the Sega Genesis emulator, MegaYume.
It's a tough choice, deciding between 18-bit and 16-bit color. 18-bit takes 3 bytes per transfer for one pixel whereas 16-bit takes only 2.
Doing 16-bit for the Spin2 driver, to be as fast as easily possible.
Guess it's going to come down to how fast the assembly driver can be. If it can do >60 Hz screen updates in 18-bit, it's an easy choice.
Otherwise, not so easy...
It probably needs rubber feet on the right side, but I 3d-printed a little support and it seems to work OK.
16bpp should be fine-ish, esp. over 18bpp. Maybe there's finally a use for RGBSQZ. Then again, might aswell. If you're doing 320x240 you get some 50+ cycles per pixel, way enough.
Bigger issue with these is that they're portrait mode and only have one internal buffer, so horizontal scanline rendering will always have ugly tearing.
Other thing: The MegaVGA driver is rather particular. It supports dynamic switching between H32 and H40 (256x224 vs 320x224) and progressive/interlace modes. It also has to update the line counter in rather specific ways. Getting that to work with a non-streamer display, good luck (though you can just ignore interlace for 240p display).
(NeoVGA is mostly the same thing with minor edits, but neither interlace nor H32 is actually used)
Ok, portrait scan mode would be a problem. I need to see if that can be changed...
Ok, doesn't look like I can change scan direction. But, can change the way info is sent to the LCD, right?
Can send data in vertical lines instead of horizontal lines?
Might require additional buffering of the screen?
I think you can change the direction data is written to the screen.
But unless you can somehow find 140k free (320x224x16bpp), the graphics will have constant tearing because the lines render horizontally.
(And of course if you do theoretically buffer a frame, that's an additional latency frame)
Very nice 👍