No, the display is 8-bit parallel across most of the standard UNO headers, with touch screen on the lower Analog pins (A3/A4?), then the real-time clock is on SDA/SCL at pins 20/21... It’s the SD card that is on the SPI bus, using pins 50,51,52 (cs on 49) to avoid physical conflict with the display’s circuit board. Odd numbered pins are easier to access; even pins can rub a bit on the edge of the board... easily dealt with.
The Mega’s end-header (with pins 22-53, 5v, gnd) is otherwise wide open, so there would be no physical conflicts and limited extra program size to extending the utilization of the SPI bus.
Dipping further into the weeds:
Run-time memory is already pretty tight, with free stack around 500 bytes at some points of my code (so less when calling deep function chains?). My k-line library is the little program that grew and is likely due for refactoring? It has some data duplications, so could give back a few tens of bytes here and there, but the big VRAM user remains the GUISlice library components... the display elements’ major definitions are now up in program flash, but there is still a large heap footprint for their runtime variables. I’m not familiar enough with embedded systems to wrestle with where the compiler is locating everything, so there are likely additional RAM savings available? The inability to directly read the ATMega’s program flash address space complicates any effort to relocate constants, since the read instructions all change for the compiler... there are macros that ease the relocation of C strings, so perhaps it’s possible for other types too but I haven’t looked into that.
-dave