#side discussion of picodvi + RP2350 TMDS

1 messages · Page 1 of 1 (latest)

undone zinc
#

@hollow badger Have you looked at the picodvi implementation that CircuitPython uses? Do you have maybe a rough order of magnitude impression of how efficient it is compared to what might be possible with a different TMDS setup? From glancing at the TMDS register docs in that pdf, I'm wondering if it might be possible to use ulab/numpy to write about 1 byte per pixel to a bytearray, then have the hardware unpack that. I wonder how much faster that might be able to go compared to the normal CircuitPython method of adding a TileGrid(Bitmap(...), Palette(...), ...) object to a Group.

undone zinc
#

I'm speaking of things I barely understand here, but... do you suppose the HSTX bit crossbar might be configurable to either do bit extension of the low bit or perhaps to do 1-fill by turning on inversion and pre-inverting the color bits? (RP2350 datasheet section 12.11.3. Bit Crossbar)

hollow badger
#

Unfortunately the bit crossbar inversion is PHYS-level signal inversion, it's used to implement the differential-pair signaling pin pairs so it happens after the TMDS encoding not before. 😦

The PicoDVI approach allows for more flexibility (half/quarter-size high-color modes by changing the DMA transfer size during pixel data to get free 16:32 or 8:32 data duplication), and on the RP2350 at least neither approach has a specific bottleneck.

PicoDVI assembles the full list of DMAs to use and uses two DMA channels, one DMA feeding 'gather' commands to the second, the second does all the HSTX work, then a tiny CPU call to restart the 'gather' DMA.

Mine has the restriction of not supporting RP2040 or pixel-doubling so it's only a single DMA channel doing the whole frame, and the second DMA only exists to re-trigger the first DMA channel when it completes since the buffer is larger than the maximum 'ring buffer' size RP2350 supports.

Both are efficient, mine just was simpler to understand and it's an easier framework while I'm experimenting with getting the HSTX to output more fully valid HDMI including audio as a goal. It'll be limited to 8bpp mono audio (HUGELY simplifies HDMI audio encoding because bits all align into nibbles so there's less values to calculate) but if I can get it stable it'll be helpful to folks doing games and stuff on the RP2350 and in theory the audio packets can be back-ported to the existing PicoDVI structure too.

#

And yes, 8bpp mono audio still covers 99% of the emulators we're all wanting to run on our RP2350's. >_>

undone zinc
#

Very interesting. Dunno if you follow CircuitPython dev stuff much on GitHub, but I wonder if you might be interested in this issue: https://github.com/adafruit/circuitpython/issues/10242 "Metro RP2350 DVI output defaults to 72Hz refresh (capture cards like 60Hz) #10242"

hollow badger
#

Oh that's because they're using 'official' 640x480 timings but at the RP2350 default clock rate it needs things tuned for 30Mhz/300Mhz HDMI clock rate (the split due to the 'clock' pin running 1:10 versus the pixel clocks on HDMI).

For the RP2350 at stock CPU speeds it needs an hblank total of 160 pixels and vblank of 145 lines, so it ends up being 800x625 sent pixels, which at 60hz is exactly 30,000,000 clockrate, which is 300,000,000 pixel bitrate, which is double the 150,000,000 default CPU speed on the RP2350.

hollow badger
#

Put a comment regarding more video-timing signal specifics with a suggested 'fix' option that should be easily doable inside the existing code framework in CircuitPython, if they bump up to 800x625 total pixels that's exactly 500k pixels per frame, so at 30Mhz pixel clock that's 60Hz refresh for the RP2350.