BBB and 4DCAPE-43Tor SPI based LCD interfacing

A number of years ago I bought the 4DCAPE-43T. I have an SD card with Wheezy 7.11 that can display the desktop. I believe Jesse and subsequent releases no longer supported this cape and 4D System in Australia doesn’t either.

So here’s the thing. I realize that with this cape installed I cannot run the HDMI. And with this cape installed I really don’t want the graphical desktop. What I expect I’d be able to do with this is create an SD with the Rev 10 Buster version of Debian Console version.

But I’d like to access the the display in much the same way as if I connected say an SPI based LCD display like which is the 4D Cape or even the . And there are others. Generally SPI but the Beagle Cape is mapped to the Beagle pins.

So using something like Lazarus (Free Pascal) a call to the paint method to render a frame that is essentially 480x272 for example by 16 or 24bits colour is the general idea. Trouble is I don’t know what I don’t know and I’m not even sure where to start looking. I would imagine the source code for the Debian Driver for the 4DCAPE-43T would be a good starting point but searching for that has been fruitless.

Any suggestions? The starting point would be the Debian Buster Command line install and a simple program (Python or C) that perhaps just reads a BMP image that is 480x272 and renders it onto the display Or the first 480 pixels of a larger image. The image could be as simple as a screen grab that is 480x272 saved as a BMP file.

I do have some smaller graphical displays that are SPI based instead of the actual beagle cape but I’d rather use this cape.

Suggestions on where to start?

Based upon the documentation I looked at (apologies for the Google
tracking overhead)
this display /requires/ the LCD pins on the board -- which means it is a
parallel LCD driver using the same graphics system as the HDMI framer.

  That document also implies it uses the same drivers as the CircuitCo

  The biggest problem is likely to be that the Wheezy time frame was
still relying upon the kernel to load the device tree during start-up. That
scheme was discontinued sometime in the Jessie time frame, and it is now
u-boot that loads device trees. So, presuming the driver is still in the
archive, you likely need to have a DT overlay for the display AND specify
that overlay in /boot/uEnv.txt so that it gets loaded before the kernel
starts up.