• Explanation of approach for porting XORLib to TFT-display

    SHAOS • 11/09/2018 at 05:46 • 0 comments

    If you remember my 2015 project Xorya ( https://hackaday.io/project/5507-xorya-extremely-low-cost-game-console-on-pic32 ) then you should know that it was 640x200 monochrome (black and white) or 160x200 15-color modes (burst NTSC colors like in Apple II or CGA composite). So how could it be ported to 320x240 full-color TFT-display? At that time I started writing a software library XORLib (open sourced under MIT license) with some future graphics modes reservations:

    /* NTSC compatible video modes - 320 bits per line */
#define XOMODE_320x200_MONO    0 /* Black and white 320x200 */
#define XOMODE_160x100_GRAY5   1 /* Pseudo mode on top of mode 0 with 5 shades of gray */
/* NTSC compatible video modes - 640 bits per line */
#define XOMODE_640x200_MONO    2 /* Black and white 640x200 */
#define XOMODE_213x200_GRAY4   3 /* Pseudo mode on top of mode 2 with 4 shades of gray */
#define XOMODE_160x200_COL15   4 /* Color burst mode over 640x200 with 15 unique colors (4 pallets) */
#define XOMODE_160x100_COL120  5 /* Pseudo mode on top of mode 4 with about 120 unique dithered colors */
/* NTSC compatible video modes with additional hardware - 640 bits per line */
#define XOMODE_320x200_COL4    6 /* CGA-like mode with configurable 4-color palette */
#define XOMODE_160x200_COL16   7 /* Color mode with standard 16-color palette */
/* NTSC compatible video modes with additional hardware - 1280 bits per line */
#define XOMODE_320x200_COL16   8 /* EGA-like mode with standard 16-color palette */
#define XOMODE_160x200_COL256  9 /* Predefined 256-color RGB-palette (including 64 shades of gray) */
/* NTSC compatible video modes with additional hardware - 2560 bits per line */
#define XOMODE_640x200_COL16  10 /* EGA-like mode with standard 16-color palette */
#define XOMODE_320x200_COL256 11 /* Predefined 256-color RGB-palette (including 64 shades of gray) */
/* VGA compatible video modes (just a placeholder for future) */
#define XOMODE_640x350_COL16  12 /* EGA-like mode with standard 16-color palette */
#define XOMODE_640x480_COL16  13 /* VGA-like mode with standard 16-color palette */
#define XOMODE_800x600_COL16  14 /* SVGA-like mode with standard 16-color palette */
#define XOMODE_ENHANCED_VGA   15 /* Placeholder for other VGA modes */

    Having full-color TFT 320x240 is actually helping to cover all 320x200 modes (up to 256 colors) and now I'll explain how. If you have ever looked into XORLib examples then you know, that most of the time it works with videomemory directly:

    #include "xorlib.h"

int main()
{
 int y;
 unsigned char *p;

 xoinit(XOMODE_160x200_COL15); /* gray colors 5 and 10 are identical */

 for(y=0;y<200;y++)
 {
   p = xodirectline(y);
   /* do something with pixels of current line (2 pixels per byte) */
 }

 return 0;
}

    Even though XORLib is also allowing to use graphics primitives as xopixel and xoline (but obviously it is a little slower), so this port should support direct videomem access as well. So I decided to have low-res low-color videomemory in the PIC32 RAM - in case of 160x200_COL15 mode it is 160x200/2=16000 bytes (in actual XORLib it is a little bigger because of required color burst in the beginning of every line). And how is content of this videomem in PIC32 RAM transferred to videomem of TFT-display? Easiest way to do that is when next xodirectline function is called:

    int xorlib_curline = -1;

inline unsigned char* xodirectline(short y)
{
   xcopy();
   xorlib_curline = y;
   return &xorlib_screen_buffer[y*80];
}

    where xcopy is a function that does actual copying of programmatically modified line of pixels to TFT:

    union{unsigned long bbytes; unsigned char bbyte[4];}aa;

void xcopy(void)
{
    int i;
    if(xorlib_curline >= 0)
    {
        tft_set_write_area(0,xorlib_curline,320,1);
        TFT_24_7789_Write_Command(0x2C);
        unsigned char *p = &xorlib_screen_buffer[xorlib_curline*80];
        for(i=0;i<80;i++)
        {
            aa.bbytes = actual[(*p)>>4];
            TFT_24_7789_Write_Data3(aa.bbyte[0],aa.bbyte[1],aa.bbyte[2]);   
 TFT_24_7789_Write_Data3(aa.bbyte[...
    Read more »

  • Quick and dirty port of XORLib to the badge

    SHAOS • 11/06/2018 at 03:42 • 0 comments

    This is how far I was able to move during 2 days of the conference in porting my XORlib to the badge - it's definitely slower than original XORLib on PIC32 to TV (because of software color conversion and sending pixels to TFT screen is slower than DMA), but fast enough to be useful :)

    Source code (with everything from the project - I modified user_program.c and removed some demos from the build to free space for my code):

     https://cdn.hackaday.io/files/1621166935970944/badge-supercon18.X.tar.xz (948K)

  • Attempt to re-create badge hardware

    SHAOS • 11/02/2018 at 06:17 • 0 comments

    Because I will get badge only on Saturday morning I needed to start coding on something before that. I've got exactly the same TFT-display, but pad pitch 0.5mm prevents to do anything with it by human hands ( and my 45-year old eyes are not happy either : )

    So I took very similar TFT-display with different controller (but compatible) and with more human-friendly pad pitch 1 mm (on the left is broken one, but I have good one of the same kind too):

    As a reference hardware I took BASYS MX3 board from DIGILENT with PIC32MX370F512L (different package than H):

    to free signals for display I desoldered LCD from BASYS and put 16-pin female header instead (LCD still works if connected back to it):

    then I inserted proto-board with soldered TFT-display and started playing with it:

    2 red wires that go to PMOD A connector are G7 (/RES) and G8 (D/C) - everything else go to that pin-header...

    P.S. I was not able to make it working yet, so further XORLib porting experiments happened on actual 2018 supercon badge on site during November 3-4, 2018