Classic Video Chip Drives A Modern TFT

A lot of us have a soft spot for retrocomputers, and there’s nothing quite like running original hardware. Unfortunately if you’re after the truly original touch then that means carrying along the family TV from 1982, and that’s where life becomes annoying. What if there were a way you could easily drive an LCD panel from a classic video controller? Help is at hand for owners of TI TMS9928A video chips, courtesy of [umaker], with a clever interface board that drives an SPI or parallel TFT.

At its heart is not the FPGA you might expect, but an STM32G4 microcontroller on an STM Nucleo board. This digitizes the R-Y and Y components from the TMS chip which would originally have been destined for an NSC or PAL encoder, does the color conversion through its algorithm, and transfers the result to the screen. This is a task which would back in the day when NTSC or PAL were king have been seen as extremely computationally intensive, so it’s a mark of just how capable an STM can be that a few dollar microcontroller can do it.

We can see this technique proving to be extremely useful across a lot of different retro color graphic applications. We’re not sure whether its lag would be too much for a light gun game, but it would be nice to think that it would result in handheld retro machines.

We encountered this project previously, when as part of its development he needed a sync separator.

11 thoughts on “Classic Video Chip Drives A Modern TFT

  1. Would be interesting to have an FPGA implementation of this chip which includes a good chunk of the display controller but writes the outgoing CRT drive signals to a framebuffer that simulates phosphor excitation and is slowly decayed over time as it gets written out to the LCD over SPI (maybe even in time with the CRT drive signals).

  2. > At its heart is not the FPGA you might expect, but an STM32G4 microcontroller on an STM Nucleo board. This digitises the R-Y and Y components from the TMS chip which would oritinally een destined for an NSC or PAL encoder, does the colour conversion through its algorithm, and transfers the result to the screen. This is a task which would back in the day when NTSC or PAL were king have been seen as extremely computationally intensive, so it’s a mark of just how capable an STM can e that a few dollar microcontroller can do it.

    I think you’re missing a few consonants there. “oritinally een”? NSC? “can e”?

  3. Umaker here. The refresh rate over spi is 30hz so there’s a two frame lag. Using parallel the refresh is 60Hz with a single frame of lag. I actually had it running with 1/4 frame of lag but the DMA injected noise into the ADCs. Once i have a working PCB I’ll try that again.

  4. In the podcast, you referred to the video components R-Y and B-Y as being RED minus YELLOW and BLUE minus YELLOW. Doesn’t Y represent the LUMINANCE component?
    i.e. Y=(0.2126*RED(+(0.7152*GREEN)+(0.0722*BLUE).

    I enjoy your podcast every week.

Leave a Reply to rnjacobsCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.