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.
https://habr.com/ru/post/412325/
the visible swap area I think would be cool to see in action
That is a brilliant project 😁 totally on fire 🔥🔥🔥
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
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.
It is probably very useful for transferring contents between the RAM banks for the NEC PC8201. Not sure if the Model 100 has memory banks. The LCD access is slow as it relies on I/O port bit banging.
Can it go the other way? Maybe not on a microcontroller, but could excess system ram be harnessed by the gpu in modern components?
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
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.
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.
I just leave it here:
https://habr.com/ru/post/412325/ (Russian)
I should be more attentive to previous comments…