sudomod

Hello sudoers,

having picked this project for my first attempt at building something with the Pi, I am currently debating the options for the display.
While the composite connection featured in wermy's guide (thanks for that one!) seems to be easily accomplished, I felt that it introduced a lot of overhead for convenience.
While reading to make up my mind about the features I want for my build, I stumbled upon kite's GB0 with DPI and thought that it's perfect for my case.
I would have posted there to get answers, but that would get close to hijacking kite's thread and I think this topic deserves its own thread (there hasn't been one yet, has there?).

I only want to emulate Nintendo systems up to GBA/SNES. None of the systems have more than 15 bit of color depth. Also, I don't care about HDMI out. If I ever want to have an Emulator hooked up to a bigger Screen, I'll probably just build a stationary one with a beefier System than the Zero.
These facts are making the natively supported RGB565 mode of the Pi viable. According to the DPI readme this will cost me about 20 GPIOs, leaving half of them for other tasks (Input, Sound?)

Another priority is battery life. I imagine leaving out the driver board, thus cutting consumption and making more room, may help maximizing that.

Lastly, I feel that the image quality of the 'composite' displays is lacking. Some of you are experimenting with 640x420 displays to alleviate that, but these are expensive and there's next to no info about what the use of a higher res screen means for power consumption.
I'm not sure how exactly this works (this is one of the reasons I'm posting this), but the resolutions of the relevant systems are:
GB/GBP/GBC - 160x144
GBA - 240x160
NES - 256x240
SNES - 256x224
So a 320x240 Screen should in theory be perfectly fine.

To wrap things up, these are my main concerns at the moment:
- Am I right in the assumption that this will take 20 GPIOs, given the right LCD?
- Does anyone have experience with this approach (not necessarily with the GB0) and could share it? Maybe know a source of appropriate screens? I'd hate to get one with driver board just to throw it out.
- What to do with the excess pins on a screen that wants 24 bit, in case I can't find one that expects 16? I'm guessing I'll just common them together like this to get 5 effective pins (01)(2)(34)(5)(67) (or 6 in case of the green channel).
- Can I expect near pixel-perfect image quality since I'm effectively setting the Pi's output resolution to the native screen resolution?

Sorry if this reads like incoherent rambling, but as mentioned this is my first project and I'm kind of a noob.

Thanks for all replies

Hey just seen this read through my whole thread on my project you linked, I did go into detail and offered links to my sources so far! Don't forget the Pi only has 28GPIOS, the rest are gnd and power (so 20 pins on gpio leaves you 8 pins for other things). I do plan to make a separate thread or something and detail my board, which I will probabaly make for sale once I have refactored it slightly.. you know how it is with many projects on the go! But soon I will have something to show, I'd encourage you to research it and get your head around it, I linked some other blogs in my post where I got this info from.

The last few pages of Kite's thread has the links with all his source files, read up as I have and all info is there. now for a screen to work you need to look at the datasheets as Kite has already mentioned to figure out how to interface with it, from what I have read and from Kite's explanations just about any screen will work providing that it has the RGB output pins.

Anyways so you don't have to go looking here are the links:

http://blog.reasonablycorrect.com/raw-dpi-raspberry-pi/

https://www.raspberrypi.org/documentati ... /README.md

kite wrote:Hey just seen this read through my whole thread on my project you linked, I did go into detail and offered links to my sources so far! Don't forget the Pi only has 28GPIOS, the rest are gnd and power (so 20 pins on gpio leaves you 8 pins for other things). I do plan to make a separate thread or something and detail my board, which I will probabaly make for sale once I have refactored it slightly.. you know how it is with many projects on the go! But soon I will have something to show, I'd encourage you to research it and get your head around it, I linked some other blogs in my post where I got this info from.

Oops. That's what happens when you don't read the specifications until the hardware is there. I didn't expect there to be 8 Ground Pins in there. That complicates things, but I guess it's manageable.

Helder wrote:The last few pages of Kite's thread has the links with all his source files, read up as I have and all info is there. now for a screen to work you need to look at the datasheets as Kite has already mentioned to figure out how to interface with it, from what I have read and from Kite's explanations just about any screen will work providing that it has the RGB output pins.

Anyways so you don't have to go looking here are the links:

http://blog.reasonablycorrect.com/raw-dpi-raspberry-pi/

https://www.raspberrypi.org/documentati ... /README.md

The second one I actually linked in the OP, but thanks for the second one. I must have missed that in kite's thread.

The author of that blog is recommending letting the least significant bit lines on each color channel float to reduce pin usage. I initially thought that would compress the color range (making the colors look flat), but it's only 7/255 from full white (black? I should look up if a 0->1 transition is making the pixel dimmer or brighter...) with 3 floating lines, and that's hardly noticeable. My initial idea with connecting the lines would've produced some funky results

Quaternion wrote:The author of that blog is recommending letting the least significant bit lines on each color channel float to reduce pin usage. I initially thought that would compress the color range (making the colors look flat), but it's only 7/255 from full white (black? I should look up if a 0->1 transition is making the pixel dimmer or brighter...) with 3 floating lines, and that's hardly noticeable. My initial idea with connecting the lines would've produced some funky results

You shouldn't leave floating, either pull down (you'll get full black, but never full white) or pull up (you'll get full white, but never full black) or you could tie the MSB (Pi side) to the two LSBs (LCD side).. this way that MSB=0 (a colour <127) you can achieve full black, and when MSB=1 (a colour >127) you can get full white.. there will be a tiny band in that you will not get colours somewhere around the middle, but pure white and black are more important!