Created an alternate implementation of the DVIGFX8 class

[smischny]

I barely got the DVIGFX8 class working in my env. I was getting a lot of red lines when I could get it to work at all. I dove into the code and realized that it was just taking too many cycles to generate the tmds scan lines. So I implemented a TMDS palette and wrote a new main loop that was faster than the dvi_scanbuf_main_16bpp loop. Give it a look/try and see if it is worth including. I also implemented an interlaced mode to get the full 480 scan lines generated... It looks like monitors from the 80/90s on an LCD, but doesn't work on usb hmdi capture dongles.

Thanks,

Toby

[PaintYourDragon]

Very grateful for the contribution. I’m neither approving nor requesting changes to this PR right now…actually, I’m surprised anyone’s in here, haven’t done a proper Arduino library release and the code is in a super early state and subject to continuous upheaval (e.g. just changed all the constructors) while we sort out just what we’re trying to create here.
Curious what could be causing the difference that dvi_scanbuf_main_16bpp falls short in your environment, but has been pretty solid here?

[smischny]

Yea, I had my pcbs being made when I saw your show-n-tell, so interesting timing. I went looking for your code once they arrived. What I saw was that the amount of time that the DVIGFX8 class took to convert the 8 bit palette entries to the RGB565 entries for the dvi_scanbuf_main_16bpp loop was sometimes just over the limit and red lines would display. The DVIGFX16 class worked all the time for me, it was only the DVIGFX8 one that I would get red lines (and at times nothing). So the flow is that the dvi_dma_irq_handler calls back the DVIGFX8 scanline_callback method which has to convert the scanline to RGB565 and queue it for the dvi_scanbuf_main_16bpp loop to then convert it to tmds. That should all be happening on the second core, so I'm not sure why you are not seeing any issues. I just tried your 8bit_single_buffer example again and it was a black screen until I changed the resolution down to 320x240 from 400x240. Initially I was selecting the "Raspberry Pi Pico" but changed to the Generic RP2040 w/ Boot Stage 2: "W25Q080 QSPI/2". I am using the USB serial console. BTW, my board does work with Wren6991's examples... So I don't think there is a hardware issue on the boards...