Shifter LOAD behaviour

[Badwolf]

Right. But why would you care about HSYNC at all? At least for a standard ST screen (no fullscreen), HSYNC is completely irrelevant for you. What matters here is that MMU increases the address counter on every LOAD pulse, and it is reset to Video Base at VSYNC. For a frame buffer, you don't need anything else, well, expect the current resolution.

I shouldn't. At least in theory.

But it's not working, so I could reduce the problem to one scanline at a time to make debugging simpler.

I see. Probably that's not your problem, or at least not currently you main problem, but note that there are some potential synchronization issues here.

Thanks. What sort of issues? VSYNC appears to happen quite far away from any LOAD edges, but perhaps I've not seen the full picture?

Am am confused by the shifting start point, though.

Not sure I understand what is confusing.

What's confusing me is that about half my captured frames don't seem to start at offset zero, but part-way down my framebuffer. I can't see how that's happening and was worried my inferrence of the workings of the LOAD signal was wrong.

The first LOAD after VSYNC is the first word at the screen memory. It's as simple as that. And for a standard ST screen, it even doesn't matter for your purposes if you use the VSYNC raising or falling edge.

That's great. Perfect. And what I was asking.

Which means the issue lies in my offset counting, in my data transfer off-chip or in my interpretation of that data subsequently. But it doesn't lie in my understanding of the LOAD and VSYNC signals.

Cheers,

BW

[exxos]

@Badwolf I may be wrong, but load wouldn't happen during the screen borders ?

[Badwolf]

@Badwolf I may be wrong, but load wouldn't happen during the screen borders ?

Doesn't seem to from the various traces I've picked up on the forums.

Providing it's not happening right at the VSYNC negative edge I don't think it [ought to] matter to me, though.

BW

[ijor]

Thanks. What sort of issues? VSYNC appears to happen quite far away from any LOAD edges, but perhaps I've not seen the full picture?

Yes, the borders for a standard screen are very large. But you should always be careful when working with asynchronous signal. You are capturing the data using LOAD as the clock (and you probably have no choice here), but your main clock is probably completely asynchronous to LOAD. And even if it's not, say you are using the computer 16 MHz clock, it would still have a significant clock skew.

@Badwolf I may be wrong, but load wouldn't happen during the screen borders ?

Doesn't seem to from the various traces I've picked up on the forums.

Again, not on a standard ST screen. Or to be more precise, on a standard ST screen the borders are very far from VSYNC.

[Badwolf]

Not sure I understand what is confusing.

What's confusing me is that about half my captured frames don't seem to start at offset zero, but part-way down my framebuffer.

Here's an example of what I mean (rendered from data received).

Sometimes it seems to line up rather well (with the occasional dropped word):

IMG_8761.jpeg (152.07 KiB) Viewed 168 times

But other times it's oddly offset, although still clearly visible as to what it is. Note it's not simply wrapped around, however:

IMG_8760.jpeg (216.41 KiB) Viewed 168 times

But thanks to all I now know the concept is fine (reset address at VSYNC), so it must be in the implementation & I can keep going.

BW

[Badwolf]

Current theory: I'm missing VSYNC edges. Or at least my counter reset logic is faulty.

I presently have a (fairly simple) verilog clause like this [from memory as I don't have the code to hand]:

Code: Select all

always @( posedge LOAD or negedge VSYNC ) begin

	if( !VSYNC )
		scrcounter <= 'd0;
	else begin
		d_in <= D;
		a_in <= scrcounter;
		trigger <= ~trigger;
		scrcounter <= scrcounter + 'd2;
	end
end

Now if I replace the data with the scrcounter value I get a lovely stable representation of the sort of thing you expect to see from a counter in memory. The sort of thing you see during memory tests. So that says to me that the address and data transmission is working, but the inferred address during screen sniffing is simply getting out of alignment -- possibly rolling over or simply triggering at the wrong time.

I could come up with a more convoluted way of resetting the screen counter above, but I thought the above syntax was a perfectly cromulent way of defining the flip-flop. Am I being stupid?

Cheers,

BW

[exxos]

Vsync likely has a very slow edge which could upset the pld ? Maybe don't look for edges and look for 2 samples of vsync high or low to make sure it's stable ?

[Badwolf]

Vsync likely has a very slow edge which could upset the pld ? Maybe don't look for edges and look for 2 samples of vsync high or low to make sure it's stable ?

I did worry about that before and tried a four-bit vsync-history buffer which only asserted when all four bits were low, but it didn't make any odds.

I'm keen to keep the LOAD-edge-triggered logic (rather than sampling LOAD at my OSC speed, say) so my next approach might be to monitor VSYNC in its own flipflop and set a flag for the counter to reset the next time the LOAD edge flipflop runs.

Something like

Code: Select all

reg vreset;
reg vresetack;

always @( negedge VSYNC ) begin
	vreset <= ~vreset;
end

always @( posedge LOAD ) begin

	if( vreset ^ vresetack ) begin
		scrcounter <= 'd0;
		a_in <= 'd0;
		vresetack <= vreset;
	end
	else begin
		a_in <= scrcounter;
		scrcounter <= scrcounter + 'd2;
	end

	d_in <= D;
	trigger <= ~trigger;
end

Not sure if that would make any difference, but keeps the edge detections separated.

BW

[ijor]

Current theory: I'm missing VSYNC edges. Or at least my counter reset logic is faulty.

This should be relatively easily to confirm at the MCU. The MCU should receive 16,000 words for a standard ST screen. If it doesn't, something is wrong.

I presently have a (fairly simple) verilog clause like this [from memory as I don't have the code to hand]:

Code: Select all

always @( posedge LOAD or negedge VSYNC ) begin

	if( !VSYNC )
		scrcounter <= 'd0;
	else begin
		d_in <= D;
		a_in <= scrcounter;
		trigger <= ~trigger;
		scrcounter <= scrcounter + 'd2;
	end
end

I'm not sure I understand why you need a counter at the PLD in the first place. Shifter doesn't need a counter, why would you? All you need is to record which word is the first one on screen, that's all. The framebuffer might need a counter (or not), but it can maintain the counter itself, if it needs it. Transmitting a counter from the PLD to the framebuffer seems like a waste of bandwidth.

[ijor]

Vsync likely has a very slow edge which could upset the pld ? Maybe don't look for edges and look for 2 samples of vsync high or low to make sure it's stable ?

He is not using VSYNC as a clock (or at least he wasn't). He is using VSYNC as an async reset. Slow edges shouldn't matter. Glitches shouldn't matter either as long as they don't happen when the signal is stable high (when the screen is active).

I'm keen to keep the LOAD-edge-triggered logic (rather than sampling LOAD at my OSC speed, say)

Sampling LOAD with your own clock it would be much better in terms of signal synchronization. But unless you use a very high frequency, you would probably be too late to sample the data bus. If you have no choice, which could be the case if you happen to have glitches on LOAD, you would need to maintain some kind of data bus buffering so that you could use data as it was at the original LOAD trailing edge.

... so my next approach might be to monitor VSYNC in its own flipflop and set a flag for the counter to reset the next time the LOAD edge flipflop runs.

That sounds like even worse. You would be mixing three asyncrhonous clocks, and also using a signal directly as a clock (when it is not needed), makes it much more sensitive to glitches.

If you think that you might be getting VSYNC glitches, use some kind of glitch filter. Note again that glitches at the edges are harmless here. Much more critical are spurious glitches at LOAD. Again, you could use the MCU to debug spurious LOAD pulses.