Stealing RAM For A Microcontroller From A TFT Display

PC users with long memories will recall the days when the one-megabyte barrier was  a significant problem, and the various tricks of extended and expanded memory used to mitigate it. One of them was to install a driver that mapped surplus graphics card memory as system memory when the display was in DOS text mode, and it was this that was brought to mind when we read about [Frank D]’s microcontroller implementation of Conway’s Game Of Life.

The components were those he had to hand; an STM32F030F4P6 and an RM68130 176 × 220 TFT board. The STM is not the most powerful of chips, with only 16 kB of Flash and 4 kB of RAM. The display has enough on-board memory to support 18 bits of colour information, but when it is running in eight-colour mode it only uses three of them. The 15 bits that remain are thus available to be used for other purposes, and though the arcane format in which they are read required some understanding they could be used to provide a very useful extra 38720 bytes of RAM for the microcontroller just as once happened with those DOS PC graphics cards of old. Interestingly, the same technique should work with other similar displays.

Though this isn’t a new technique by any means we can’t recall seeing it used in a microcontroller project such as this one before. We’ve brought you many Games of Life though, as well as marking John Conway’s passing earlier this year.

12 thoughts on “Stealing RAM For A Microcontroller From A TFT Display

  1. A french 80ies computer (exelvision exl100) used a similar technique. In basic programs were stored in the vram and not directly in processor (small) address space

  2. Kind of like using the 64 byte character font RAM in the ubiquitous HD44780 LCD controller for storage, but on a much grander scale.

    The LCD in the TRS80 Model 100 also had some spare bytes available for general-purpose use (240 pixel wide display, but 256 bits actually in memory, times 64 rows = 128 bytes available). Really just a party trick though, since you usually had kilobytes of normal memory to play with on that machine, but useful as a sort of inter-process communication without involving the filesystem, as long as the data didn’t have to survive a power cycle.

    1. On modern computers, yes, that is how it works. GPU ram on dedicated cards have ram that is far faster than system ram.
      For integrated graphics, it has no choice but to use system ram

    2. They are, though the GPU does not know too much about it, drivers take care of it.
      Basically the driver attempts to fit the most often used resources in GPU RAM, whatever does not fit, stays only in main system memory, and is then transferred to the GPU as needed, degrading performance. Which is why it is advisable to have enough GPU RAM.

    3. It can be done as games loads textures from the filesystem during loading levels (or dynamically but that’s a lot of work). The PCIe bus is painfully slow vs onboard graphic memory to do it live and non-deterministic latency.

      AMD had a nonconsumer GPU with on-board SSD for working with large amount of data.

Leave a Reply

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