This project wouldn't be a medley if it didn't draw inspiration from a number of other projects to solve niche problems raised only due to self-imposed restrictions, so here I "briefly" present a plan which forms the backbone of the design, and try to credit those sources of inspiration that make this project possible/plausible(?).

As mentioned previously, I would like to be able to run a number of emulators with support for external gamepads on a host microcontroller. I have chosen to use the ESP32-S3FH4R2, as it provides common connectivity options for gamepads (USB host, bluetooth), comes with flash and PSRAM on package, saving the difficulty of trying to fit these on a small PCB, and is proven to have sufficient performance to run several emulators such as via Retro-Go,  which I would like to port onto this board to save the effort of writing firmware from scratch. To keep the form-factor as thin as possible, system-on-modules such as the ESP32-S3-WROOM are out of the question, so I will have to figure out how to integrate the WiFi antenna directly onto the board.

The RP2040 video adaptor will work using the PicoDVI library to bit-bang a DVI interface, which many projects and products have demonstrated before. The specific application of the RP2040 as a video adaptor for a host processor can be seen in Pimoroni's PicoVision development board (referring to the humble RP2040 as the 'GPU', heh), which appears to program the 'GPU' from a host Pi Pico using 2 GPIOs to emulate an SWD interface. I intend for my ESP32 host to do much the same, so seeing how the PicoVision firmware handles this should make things much easier.

While the PicoVision switches between two external banks of PSRAM as framebuffers, this sounds pricey and requires extra board space. Instead I aim to use the ESP32-S3's QSPI interface to shuffle data to the RP2040 as quickly as possible. Using a 4-bit bus in double data rate mode @40MHz gives a throughput of 320Mb/s, which should be more than enough to transfer a 320x240 framebuffer @60Hz (assuming the PIO on the RP2040 can handle it)?

To keep the form factor thin, I sought out some 'alternative' connector solutions that other have tried, and the findings are fairly hopeful!

USB-C 'ports' have been implemented a few times as PCB edge connectors, seen in Chris' CRAPi2040 (0.6mm thick PCB) and Dmitry Grinberg's Linux Business Card (0.8mm thick PCB), while picoDVIEdge by peterburk (0.8mm thick PCB) does the same to a 'DMI (the H is silent)' socket

While the 'DMI' connector appears to work well on a 0.8mm board, comments online seem to suggest 0.6mm would be more suitable for USB-C, so I plan to use a 0.8mm thick PCB as the 'base' of the card (as the 0.8mm option is cheaper), with small 0.6mm thick USB-C adapter boards soldered on.

A final big source of inspiration came from Dennis Kaandorp's PCB business card, which uses flexible prongs in a 0.8mm thick PCB to create a 2032 coin cell holder. With some creativity, I think this could be adapted create sockets for a 3.5mm TRRS connector and some form of external memory card (SD card or MMC)

Since the ESP32-S3 is quite power hungry and the RP2040 will need to be overclocked, a 5V-3.3V buck converter seems more appropriate than a linear regulator, especially in low profile packages which tend to have poorer thermal conductivity. This does mean finding a sufficiently low-profile inductor (e.g. chip inductors), or I could try designing the inductor coil directly in the PCB traces... for fun of course :) .

So summing this all up, the plan boils down to:

• use an ESP32-S3 chip (not a complete module!) as the application processor
• connect to the RP2040 video adapter through the QSPI bus, program from ESP32 via bit-banged SWD
• use a 0.8mm base PCB as it is economical and appears to fit into a HDMI connector
• use smaller, directly soldered 0.6mm PCBs to create 'sockets' for USB-C connections
• figure out ways that flexible PCB prongs can be used to support an audio connector and external memory card
• use a buck converter rather than linear regulator to reduce likelihood of overheating the chip due to need for a low-profile package