Shifter LOAD behaviour

[Badwolf]

Me again!

I've been going through the old shifter threads to try to get a bit of a handle on how the actual job of pushing screen data to the shifter works. I'm hoping to actually use my design faux pas (listening to the wrong data bus) to my favour, but it's not working for me just yet.

As I understand it, when LOAD is asserted a word of data is loaded into the shifter (specifically the data will be valid at the deassertion edge) and, for ST Low say, 80 of these loads occur per raster line.

Now, knowing when VSYNC occurs (even though it's not on the shifter), can one infer the offset from the start of screen of each of these words?

My approach has been:

Code: Select all

offset = 0
loop {
	if( negedge VSYNC )
		offset = 0
	else if( posedge LOAD ) {
		screendata[offset] = D[15:0]
		offset += 2
	}
}

But this results in a framebuffer copy that's jumping around all over the place -- although it's recognisably an ST's framebuffer.

Have I missed something obvious?

BW

[exxos]

Don't know much about it personally, but you probably checked the suska sources as it will have the chip timings in them ?

[Badwolf]

Don't know much about it personally, but you probably checked the suska sources as it will have the chip timings in them ?

I haven't. I'll try to dig them out & have a look.

I'm not sure that's what I need anyway, TBH. I'm trying to work out which LOAD assertion corresponds to which bit of the screen (so a logical mapping of transfers to memory) rather than the inter-chip timing thresholds per se.

BW

[ijor]

As I understand it, when LOAD is asserted a word of data is loaded into the shifter (specifically the data will be valid at the deassertion edge) and, for ST Low say, 80 of these loads occur per raster line.
Now, knowing when VSYNC occurs (even though it's not on the shifter), can one infer the offset from the start of screen of each of these words?

You have the basic idea right. Yes, this is how MMU works. I say MMU and not Shifter, because Shifter doesn't know, neither care, about video addressing or vsync. Shifter only knows about individual scan lines.

But this results in a framebuffer copy that's jumping around all over the place -- although it's recognisably an ST's framebuffer.
Have I missed something obvious?

Well, you missed to give us more context and info, at least if you want us to help you.

From what you said I don't have a clue about how you are doing this. I assume the code you posted is some kind of seudo code. But are you using a PLD, a fast Micocontroller like a Pico, or may be both? If it's a PLD, how you actually implement this? Are you using a flip flop clocked by LOAD?

How do you know the problem is on that (seudo) code you posted and not on whatever post processing you do to actually display the screen?

May be you have a timing issue. May be you are processing the planes wrong, or may be you forgot the ST screen is planar? Again, without more info I'm just shooting in the dark.

Code: Select all

	screendata[offset] = D[15:0]
	offset += 2

Offset += 2 is probably wrong. I assume this is seudocode and this is just a typo when you transcribed the actual code into seudo code. But once again, without more info we just keep wondering.

[Badwolf]

You have the basic idea right. Yes, this is how MMU works. I say MMU and not Shifter, because Shifter doesn't know, neither care, about video addressing or vsync. Shifter only knows about individual scan lines.

Thanks. That's a start -- so each individual burst of LOADs between HSYNCs is indeed a full scanline rather than part of one and part of another?

Perhaps I can work per-scanline rather than per-frame to narrow down my issue.

Well, you missed to give us more context and info, at least if you want us to help you.

From what you said I don't have a clue about how you are doing this. I assume the code you posted is some kind of seudo code. But are you using a PLD, a fast Micocontroller like a Pico, or may be both? If it's a PLD, how you actually implement this? Are you using a flip flop clocked by LOAD?

Yes, it's just dodgy pseudocode. I'm trying to establish if the concept is right. For example, if the data appearing at the shifter is potentially offset (eg. it always loads half a line ahead or something) then I'd need to alter my logic.

A CPLD is monitoring LOAD on the Shifter, plus VSYNC, HSYNC etc from the Glue and sampling the shifter's data lines.

The sampling is clocked by the rising edge of LOAD and the counter is reset at the falling edge of VSYNC. The data is then clocked out to a micro controller for inspection.

The pipe and the decoding has been shown to work when sniffing CPU writes to the screen memory, but it's possible the sheer bandwidth of reading a full screen every 20ms has exposed a limitation. Before I disappear down a rabbit hole, I wanted to be sure the approach wasn't fundamantally flawed based on a misunderstanding on my part.

How do you know the problem is on that (seudo) code you posted and not on whatever post processing you do to actually display the screen?

I don't. Yet. I wanted to make sure I wasn't working under a misapprehension.

Code: Select all

	screendata[offset] = D[15:0]
	offset += 2

Offset += 2 is probably wrong. I assume this is seudocode and this is just a typo when you transcribed the actual code into seudo code. But once again, without more info we just keep wondering.

Yeah, translation error. It is +2 in address space, but should have been +1 in the pseudocode.

The symptom I'm seeing is is that probably around 50% of the frames are aligned as expected, but there's a (memory) offset to the rest. Eg. the 0,0 position might start a third of the way across the screen and wrap around. Or even several scanlines down the screen.

If that's just a problem in my CPLD-to-micro data transfer, great: I'll work on it. If it's caused by my naivety then I'd rather know now.

Thanks,

BW

[alexh]

@Smonson made an FPGA based HDMI output adapter that clipped onto the shifter. I believe there is some technical information in that thread?

viewtopic.php?f=29&t=330

@Icky is active a lot in that thread with his Pheonix Shifter re-implementation.

I don't think either is open source but I may be wrong.

[Badwolf]

@Smonson made an FPGA based HDMI output adapter that clipped onto the shifter. I believe there is some technical information in that thread?

viewtopic.php?f=29&t=330

@Icky is active a lot in that thread with his Pheonix Shifter re-implementation.

I don't think either is open source but I may be wrong.

Thanks. Looks like he had a lot of joy inferring the start of frame from DE timing alone, so that's positive.

Fingers crossed it's just my data transfer, in that case.

I may have a go at counting scanlines and perhaps doing something silly like transmitting only one scanline per frame to slow down the data rate enough for checking.

BW

[exxos]

There was some problems detecting the start of a frame. We ended up using vsync in the end. I don't think that issue was ever fixed.

[Badwolf]

There was some problems detecting the start of a frame. We ended up using vsync in the end. I don't think that issue was ever fixed.

Thanks. Working my way through it. My needs are nowhere near as complex as I'm not emulating shifter, merely sniffing it. And I only aim to handle handle stock colour resolutions.

Really I'm just trying to assign an address to each word I read.

Am am confused by the shifting start point, though. Will try to get some example images tomorrow.

BW

[ijor]

Thanks. That's a start -- so each individual burst of LOADs between HSYNCs is indeed a full scanline rather than part of one and part of another?

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.

The sampling is clocked by the rising edge of LOAD and the counter is reset at the falling edge of VSYNC. The data is then clocked out to a micro controller for inspection.

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.

Looks like he had a lot of joy inferring the start of frame from DE timing alone, so that's positive.

But, IIRC, that was mainly because he wanted to support fullscreen and both 50 and 60 Hz. For a standard ST screen, inferring VSYNC from DE is rather simple. Especially in your case that you don't need exact accuracy.

Am am confused by the shifting start point, though.

Not sure I understand what is confusing. 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.