New chip day (well a few days ago now)! And of all the chips it could be, there’s finally a successor to Raspberry Pi’s RP2040 microcontroller - the RP235x line.
While initial reactions appear mixed, with questions on whether the chip stands out from the competition (much like when the RP2040 was launched), I am firmly excited by the prospects the RP2350 offers - to the point I’m considering completely redesigning RetroMedleyCard around this chip…

So what makes this chip so enticing that I would throw away much of the design effort that’s gone into RetroMedleyCard so far? After briefly reading through the datasheet, I’m convinced the RP2350 could stand as a single-processor solution for RetroMedleyCard, rather than the mixed ESP32-S3 application processor + RP2040 video coprocessor currently implemented, thanks to several upgrades bestowed upon the RP2350 compared to its predecessor:

• Each CPU has been bumped up from Cortex M0+’s @133MHz to Cortex M33’s @150MHz. While the clock speed has only seen a moderate bump, the new M33 cores should offer an appreciable increase in performance-per-clock cycle. Plus, according to dmitry.gr, the chip readily overclocks to 300MHz, so should give it plenty of grunt to run many of the same emulators which run on the ESP32-S3’s 240MHz LX7 cores at present.
• A second chip select on the QSPI memory bus allows an external PSRAM chip to be used alongside external flash, giving plenty of storage and memory for Retro-Go to work with.
• Increased on-chip SRAM to 520kB should allow double buffering of the entire display (153.6kB per 320x240 frame in RGB565)
• New peripherals which practically appear to be designed to enable DVI display output: Hardware TDMS encoders specifically designed to the DVI 1.0 specification - currently the RP2040 does this in software with help of the programmable IO’s; and a new High-Speed serial transmit (HSTX) peripheral, which can output up to 300MT/s @150MHz core frequency, on up to 8 pins, with controlled output delay to aid it’s use to implement differential drivers - which sounds perfect to output a DVI video signal from the TDMS encoded stream!
• The USB peripheral appears to be essentially backwards compatible with that of the RP2040. This will hopefully mean TinyUSB support will arrive shortly, which would be more portable than the USB Host Stack/Library in the ESP-IDF.

All of this is enticing as reducing RetroMedleyCard to a single processor-chip design will greatly simplify both hardware and software fronts. There will be no need to transfer frame data between processors, or to lay out multi-bit wide buses between chips, no need to store and upload code to the video adapter processor at runtime, no need to perform tight synchronisation between transferring pixel data and active region selection commands. Keeping all of this functionality contained in one chip, in one set of addressable memory, should just be easier.

That said, such a shift will still require a substantial amount of work. Aside from the fact the the PCB layout will essentially be reworked from scratch, I would also need to consider the difficulty of porting Retro-Go from the ESP-32 to the RP2350. At the very least, anything dependant on the ESP-32’s peripherals via the ESP-IDF will need to be rewritten for the chip. Additionally, the RP2350 requires PSRAM to be added to the QSPI bus, whereas the ESP32-S3 is available with internal PSRAM attached to an Octal SPI bus, potentially offering more memory bandwidth, which may end up bottlenecking emulator performance. There’s also a handful of minor issues that will need to be considered:

• The RP2350 lacks wireless support. While RetroMedleyCard theoretically support WiFi and Bluetooth, it is not supported in Retro-Go when using later builds of the ESP-IDF, but Netplay support and Bluetooth controller functionality would still be nice to have.
• Only a single USB Host port. Currently RetroMedleyCard exposes the USB peripherals of both the ESP32-S3 and RP2040, with the aim of implementing support for the ESP32 to control the RP2040’s USB peripheral at some point in the future for multiple controller/USB audio support. Since I’m betting on TinyUSB support for the RP2350, I’m hoping I can make up for this with robust USB hub support?
• Buck topology core regulator will require an additional inductor. A discrete chip inductor could potentially increase overall board thickness, while PCB inductors take substantial board area. However, since the core voltage can be regulated directly down from 5V, only the peripheral supplies will be dependent on the 3V3 rail, so the existing 3V3 buck regulator could be replaced with a linear, low dropout type?

I could go on and on about what I think of this new chip, but that would quickly get off-topic from its applicability to RetroMedleyCard. A sensible next step would be to put an RP2350 development board on order and grab the latest version of the SDK to see just how much work porting Retro-Go to the chip will entail, I could then decide from there whether a total redesign around an RP2350 is a viable approach going forward.