Ah ok, some translation
I also want to have a TFT in DPI mode
The usual way everyone is connecting their screens up uses the composite out of the pi. the screens then convert this mushy, lossy, analogue signal into the native pixel format of the LCD. However the Pi has the capability to drive screens directly without the double conversion, giving the best possible image quality. See @Kite's AIO board as he's doing this (which is one of the reasons why a kite AIO build is so tasty as it removes yet another PCB from the project) I was originally going to use an Adafruit PiTFT connected via SPI (another digital serial bus) and the image quality is great, but the lag is terrible. HOWEVER the Pi can drive the PiTFT directly but it comes with a downside of using nearly every single GPIO pin available.
takes I2C bus pins away
I2C is a digital serial bus that the GPIO port expanders use in this cart reader project, but if I enable DPI on the Pi, then the pins for I2C are re-appropriated
use SPI as the MCP23017
MCP23017 is the port expander chip I'm using in this project. lets me effectively have 16 extra GPIO pins per chip to play with. I'm using 2 so get an extra 32 pins which is great since to do cart reading I need 27. I already mentioned SPI and there's a variant of the 23017 called the MCP23
S17that uses SPI instead of I2C. SPI is significantly faster than I2C.
I2C ends up being a bottleneck
In testing on my breadboard lash up I've been hitting the speed limitations of doing this on an ultra gnarly loose-wire setup and the larger cartridges take an age to download. it's entirely possible I'll hit the limitation of the I2C bus when I go to a PCB prototype, in which case I can switch up to SPI.
even in RGB565 mode.
back to talking about DPI mode - to use the full range of DPI - 24 bit colour - you need 8 bits per colour channel or RGB888 (8 bits Red, 8 bits Green, 8 bits Blue) but most emulated systems don't have that kind of colour depth so we can reduce the fidelity to RGB666 or even RGB565. what we lose in colour depth, we gain in GPIO pins being available. Unfortunately there's only so much tweaking you can do to configure which pins on the GPIO header are substituted and in every instance it seems that the pins I'm interested in are unavailable, which is a bit of a bugger!
