✪

A little more testing shows that I have better results using pin 17, not 18. I did not get much time to test it today but I plan to scrap my board and put it on a breadboard instead. It will be more clear if I am missing any connections and I will be able to hit swap components to check other values.

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...

Oh, look at that! Data_Latch also goes flat on occasion...I think you said that...? Nevermind.
Anyhow, that would makes sense if Horizontal sync poops out. It 'may' also explain why my pixels start up again without dropping to the next line. - appearing as a duplicated image.

Thanks for the tip.

Thanks a lot. Where did you find this thing!?
...
So data_latch  runs at 9.195 KHz just like Hsync but does not occur at the same time... that could definitely cause an offset image. I'll modify my eagle library and give it a shot tomorrow. I was busy watching X-Files all night and its bed time now.

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.

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

What pinout are you using? All I can find are documents listing pin 17 as Hsync. I have not tried using pin 18.

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?

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.

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?

I need this.

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.

Great work!

bump. crappy video added.

goodnight

the future is now

Oh boy oh boy oh boy! Mail is waiting at home!