Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Level Shifter not needed? #4

Open
HarukaKaminari opened this issue Dec 9, 2022 · 6 comments
Open

Level Shifter not needed? #4

HarukaKaminari opened this issue Dec 9, 2022 · 6 comments

Comments

@HarukaKaminari
Copy link

No description provided.

@HarukaKaminari
Copy link
Author

HarukaKaminari commented Dec 9, 2022

Greetings, mister! I watched your fantastic video and am trying to follow you. One thing I'm not quite clear: It seems that you did not use level shifters between LCD bus and esp32. As far as I know, the GPIOs of esp32 are not 5V-tolerant. Should I use level shifters for safety?
Thank you!

@HarukaKaminari HarukaKaminari changed the title Level Shifter not Level Shifter not needed? Dec 9, 2022
@kgsws
Copy link
Owner

kgsws commented Dec 9, 2022

You are absolutely correct. You do need level shifter from 5V to 3v3.

I mentioned this in the video. But i realize it's somewhat hard to understand me.
I did not use level shifter because i rewired my gameboy to run on 3v3 directly. Gameboy is capable of running on 3v3 but i would not recommend it as a solution. Game cartridges might have issues and you still need -18V for LCD circuit.

Now, since wiring is so simple, you can just use simple resistor dividers.

@HarukaKaminari
Copy link
Author

I finally built my counterpart of my style, using an authentic sgb cartridge rather than a gameboy handheld. It worked!
But there are some glitches. The display is not stable, it shakes horizontally to a fixed position, as if it loses some Hsync.
I uploaded 2 videos on my forked repository. (https://github.com/HarukaKaminari/gameboy_lcd/blob/main/10397418327191855990053214813.mp4 and https://github.com/HarukaKaminari/gameboy_lcd/blob/main/20230226_223554_5756.mp4) If it doesn't bother you much, could you please give me some hint why this happens and how to solve this problem?
Here are some details on my counterpart:
The sgb cartridge is charged on 5V. I used 74LVC245 between sgb's LCD bus and ESP32 as a level shifter.
I didn't use an OR gate to combine Hsync and CLK into a single signal. My chip is in shipping. Currently I just use CLK directly.
I also used a tiny spi LCD to display the image captured by ESP32, which has the same effect compared to WIFI, which proved the glitch is not related to network.

@kgsws
Copy link
Owner

kgsws commented Mar 6, 2023

I can't quite recognize what could be wrong. Hsync is actually not used as i only count pixel clock starting from VSync.
Only first pixel of each line is wrong if you don't use OR gate, so this is different issue.
It might be software issue but i can't explain that either.
I would check signal integrity, maybe there's some noise causing issues.

@HarukaKaminari
Copy link
Author

I finally guessed out the reason why my display shakes horizontally, and, I got a solution. It is the horrible GPIO interrupt latency that caused the esp32 losing vsync from the gameboy. Let's just imagine, that the gameboy sends out vsync signal regularly, but due to the latency of GPIO interrupt, esp32 receives it long after it is sent. What if esp32 receives it too late that gameboy already sends out clk and pixel data? I2S will be started late, some pixels will be missed! The display will move left horizontally for a whole frame! What if worse, esp32 missed one or more vsync?
I have no logic analyzer nor oscilloscope, so I can't view the true latency. I then set up the pulse counter of esp32 to count the vsync, once counted, an interrupt is triggered. Then I2S is started to capture the data. GPIO interrupt for vsync is completely abandoned in this way. And it worked! I got a very stable display, which proved my theory.

@kgsws
Copy link
Owner

kgsws commented Nov 18, 2023

I wonder why i did not have this issue but you did. Why does GPIO IRQ latency not matter in my case but it does in your case.
And how does pulse counter IRQ not have the same latency as GPIO IRQ ... this is just weird.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants