My Projects

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

electronic:lcd:m299 [2024/09/03 11:47]
tony
electronic:lcd:m299 [2024/09/03 12:09] (current)
tony
Line 66: Line 66:
 Markus confirms FS0 is connect to Vss, 6x8 font => 192 dots wide.  But there are not enough driver chips to handle more than 160 columns, so the above analysis is wrong. ​ From the t6963 datasheet the scanning frequency is independent of font width. Markus confirms FS0 is connect to Vss, 6x8 font => 192 dots wide.  But there are not enough driver chips to handle more than 160 columns, so the above analysis is wrong. ​ From the t6963 datasheet the scanning frequency is independent of font width.
 So I must conclude that we have only 160 dots across to play with as the driver chips can't handle more. So I must conclude that we have only 160 dots across to play with as the driver chips can't handle more.
 +
 A photo of a similar display in a Wayfarer TGX150 shows a text display of 27 columns by 16 rows of 7×8 characters. Actually 26 columns plus 4 pixels wide, so we have a 160 x 128 pixel display. ​ A photo of a similar display in a Wayfarer TGX150 shows a text display of 27 columns by 16 rows of 7×8 characters. Actually 26 columns plus 4 pixels wide, so we have a 160 x 128 pixel display. ​
-  * [[https://web.archive.org/​web/​20210119204556/​https://​www.picclickimg.com/​d/​w1600/​pict/​154290931017_/​Wayfarer-TGX150-Standalone-Bus-Ticket-Machine-Printing-Tickets.jpg|Example of similar display installed in a TGX150]]+  
 +{{electronic:lcd:​wayfarer-tgx150-standalone-bus-ticket-machine-printing-tickets-a.jpg|Example of similar display installed in a TGX150}} 
 +|web.archive.org/​web/​20210119204556/​https://​www.picclickimg.com/​d/​w1600/​pict/​154290931017_/​Wayfarer-TGX150-Standalone-Bus-Ticket-Machine-Printing-Tickets.jpg
  
 It turns out, that with the T6963C controller, the graphics pixel addressing mirrors the text rendering display buffer addressing. ​ A side effect is that in graphics mode it is also only displaying the same number of bits per byte as for displaying text.  So if the display is set to 6 bit (pixel) wide characters, it also only displays 6 bits of every byte in graphics mode.  Anyway the U8G2Lib expects T6963C based displays to have 8x8 font set, so short of re-writing the appropriate U8G2 Library, we need to switch this to 8x8 fonts by tying FS1 to ground. ​ Markus informs me that we need to lift this pin, rather than just cutting tracks, and then connect it to Vss (to Pin 8, FS0).  It turns out, that with the T6963C controller, the graphics pixel addressing mirrors the text rendering display buffer addressing. ​ A side effect is that in graphics mode it is also only displaying the same number of bits per byte as for displaying text.  So if the display is set to 6 bit (pixel) wide characters, it also only displays 6 bits of every byte in graphics mode.  Anyway the U8G2Lib expects T6963C based displays to have 8x8 font set, so short of re-writing the appropriate U8G2 Library, we need to switch this to 8x8 fonts by tying FS1 to ground. ​ Markus informs me that we need to lift this pin, rather than just cutting tracks, and then connect it to Vss (to Pin 8, FS0).