About 2 pixel wide column on the far left of the frame seemingly taken from the far right hand side of the frame

[dougli1sqrd]

The Problem

There is a 2 pixel width column of pixels on the far left of the frame that seem to be seemingly "rotated" in from the far right column.

Observations

• It's consistent and ever present, so there's something inherent to the hardware that causes this.
• The pixels are from the right side as if it's rotated to the "right". I haven't confirmed, but I suspect that it's actually the the last two pixels of the previous line appearing as the first two pixels of the next line. We could confirm this by making a test pattern showing a sort of "stair step" between the beginning 2 pixels and the rest of the line.

Questions

• What are the first two pixels of the frame? When we start a frame we also reset the FIFOs. If it's something to do with writing into the fifo, then perhaps it's just black? If writing is correct, then I suspect that the first 2 pixels will be correct. A test pattern would confirm this.
• What are the last two pixels of the first line?

Hypotheses

So let's assume for now that somehow the last two pixels of the first line are not being read, and get stuck in the FIFO. At the end of the first line something happens where the FIFO still has two pixels of the first line when VIS goes low, stopping subsequent reads while we're in the horizontal blanking. Then the start of the next line happens and we read once again when VIS goes high and we read the previous line's pixels as the first two pixels of the current line. Then the current line gets read up to the point where VIS goes low again.

If whatever process that causes the 2 pixels to get stuck in the first line occured again in the second line, we would expect to see 2 more pixels stuck in the fifo at the end of the line, increasing it to 4, yeah? But since we don't see an increasing pattern of pixels in the beginning, I think we can conclude that the process that causes the problem only occurs on the first line. Essentially the whole frame is shifted over by 2 pixels to the right, making each line wrap it's end to the beginning of the next line.

So what would cause us to off by two pixels like that?

• If the first line we only read 638 pixels, that would leave 2 left over, pushing everything to the right. Does this mean the last two pixels of the frame just get blown away? Does that happen no matter what?
• Is the mechanism MUST be that we only have 638 reads on the first line? Is there another way to produce extra pixels on the first line?
  • I suppose if there was some kind of spurious write or two at the beginning of the frame, that would make the first line "642" pixels long pushing everything to the right by two pixels? Is there a test pattern that we can use to determine this? A test with the logic analyzer, perhaps?
• Timing? If it took say 40-80 ns to to put the first pixel out on the bus from the FIFO from the moment VIS goes high would that cause the shifted pixels? What is the propogation delay between the NOT gate, FIFO read, and then color lookup? If this were the case, why do we only see that long delay affect the first line, and not every time a new line starts?

[sethp]

I love this write up, thank you!

Timing? If it took say 40-80 ns to to put the first pixel out on the bus from the FIFO from the moment VIS goes high would that cause the shifted pixels? [...] why do we only see that long delay affect the first line, and not every time a new line starts?

I'm wondering if it isn't something to do with the offset introduced between our EEPROM sync signals and the raw 25.175MHz clock that we've got going into the pixel logic; I know we've got VIS coming off the EEPROM itself (through the latch), but that's the (one?) part in the whole jimminy that's got a ~dozens-of-ns delay that might add up to 1-4 pixels maybe.

It might be good to start from what we're (assuming) the VGA side of things is "seeing" (as in: a pixel signal that's offset by some 𝛿 relative to the sync signals) and work backwards to trace where the delay might be coming from? We haven't found a good tool that lets us draw and then iteratively develop a timing diagram yet, have we?

When we start a frame we also reset the FIFOs.

Maybe an aside, but I would dearly love a way to "trap" or something on read from an empty FIFO; as it stands, we've got very little visibility into out-of-bounds behavior.

[dougli1sqrd]

we can absolutely setup an external interrupt on read-on-empty with a little bit of logic! We'd wire up the empty flag AND it with the NOT read signal (so we detect when the read is low) and when that output is high then we're trying to read an empty fifo. Although I don't think that's what's happening.