First of all my rc time constant is a problem. I think it is causing the sync problems. Secondly I am afraid I have missed some connections. The board is currently such a mess...
On my scope vsync looks good, but vsync was really small after after the resistor. Idk if it is a problem with the ic of if I have a short somewhere. Again, I will breadboard it and find out.
I may also try a previous revision of the circuit to see if a diode on sync helps at all. Typically people use a diode to i next sync to the data but that requires a DC offset which should not be a problem. Simulation showed that the diode method was awfully noisy and introduced high transient spikes on the rising edges of sync. Well see...
]]>Thanks for the tip.
]]>
It looks as though the author 'may' be extending the pulse width of both H and V sync signals. I suspected that I may have to do as much but hoped I could find a way around it.
]]>What pinout are you using? All I can find are documents listing pin 17 as Hsync. I have not tried using pin 18.
From a Slovenian masters thesis (you'll need to click 'I agree' to download the PDF):
http://dk.um.si/Dokument.php?id=69493&lang=eng
on page 26 of 88
]]>Jazzmarazz wrote:That is strange. I probably won't need to fuss with data_Latch until I get a steady image but I appreciate the input.
OK, but what I was trying to say is that it looks like you are already using DATA_LATCH (Pin 17) for horizontal sync?
And you might have more luck using HSYNC (Pin 18) instead?
What pinout are you using? All I can find are documents listing pin 17 as Hsync. I have not tried using pin 18.
]]>That is strange. I probably won't need to fuss with data_Latch until I get a steady image but I appreciate the input.
OK, but what I was trying to say is that it looks like you are already using DATA_LATCH (Pin 17) for horizontal sync?
And you might have more luck using HSYNC (Pin 18) instead?
]]>That is strange. I probably won't need to fuss with data_Latch until I get a steady image but I appreciate the input. Do you know if the pixel data remains at its value between that "short delay" or does it return to blank (00)? I assume I will find a stripe down the left side of the screen once I get a steady image?
Apparently it is to do with the shift register for the LCD only having 159 stages - you'll find more detail at the bottom of this page:
http://blog.kevtris.org/blogfiles/Nitty … Timing.txt
I can't speak to the state of the GameBoy's DATA lines during DATA_LATCH as I've only looked at this from the perspective of controlling the lines independently of the GameBoy CPU for my Arduboy Classic project.
]]>Jazzmarazz wrote:
AWESOME WORK!
A couple of points that may or may not help:
HSYNC is on pin 18 (occurs at the same time as VSYNC). Pin 17 is DATA_LATCH (does not occur at the same time as VSYNC).
The first pixel for each row is clocked out while DATA_LATCH is high, and then there is a short delay before the remaining 159 pixels in that row are clocked out.
That is strange. I probably won't need to fuss with data_Latch until I get a steady image but I appreciate the input. Do you know if the pixel data remains at its value between that "short delay" or does it return to blank (00)? I assume I will find a stripe down the left side of the screen once I get a steady image?
]]>AWESOME WORK! 
A couple of points that may or may not help:
HSYNC is on pin 18 (occurs at the same time as VSYNC). Pin 17 is DATA_LATCH (does not occur at the same time as VSYNC).
The first pixel for each row is clocked out while DATA_LATCH is high, and then there is a short delay before the remaining 159 pixels in that row are clocked out.
]]>goodnight
]]>