exxos's Atari, Amiga & retro forum

ijor wrote: 03 Dec 2018 19:11 Thanks. I just noted something interesting on the traces. It might be relevant or not ... People, those that tested the HDMI board, can you please tell us which TOS version you used on those system. Troed, Smonson, Exxos?

TOS104.

Also 1.04.

ijor wrote: 03 Dec 2018 16:13 It is not possible to make any conclusions about the timing.

Well we can see from the earlier scope investigation what it normally looks like, I don't think it's very likely that the timing changed somehow. Even if it did, D9 is a problem that will have caused the exact symptoms that have been observed, so the chances are very good that F_BUS_DIR is fine.

ijor wrote: 03 Dec 2018 13:10
Does the capture shows that reading works at all? I mean, do you see any reading where D9 was high before CS was asserted, and then it lowers? Or in all other cases D9 was just low before?

You probably saw the answer to this yourself by now, but yes. There are cases where D9 is high at the start of the read, and goes low concurrently (within the sampling frequency error size) with F_BUS_DIR.

This if for Troed, can you count the cycles it took here to access Shifter? :)

exxos wrote: 03 Dec 2018 20:03TOS104.

Oh, thanks, then probably the TOS version is not relevant as I thought it might be.

Smonson wrote: 03 Dec 2018 20:18 Well we can see from the earlier scope investigation what it normally looks like, I don't think it's very likely that the timing changed somehow. Even if it did, D9 is a problem that will have caused the exact symptoms that have been observed, so the chances are very good that F_BUS_DIR is fine.

But the scope captures didn't include the F_BUS_DIR signal. And more important, we don't know if any of those captures was performed on a "bad" cycle. I am not saying it is a timing issue, probably it is not, but it would have been good to confirm with more accurate captures. The problem is that all other alternatives don't seem to be very likely either.

ijor wrote: 03 Dec 2018 20:54 But the scope captures didn't include the F_BUS_DIR signal.

Ah, sorry, I didn't post that screenshot (we had so many already) but I did measure it myself, on good reads only. It's pretty much the exact inverse of CS but with a negligible delay. I will post it tonight when I get home.

I agree we're now looking for one of several unlikely scenarios.

Analogue characteristics of F_BUS_DIR during normal reads: And D9:

Smonson wrote: 04 Dec 2018 10:01 Analogue characteristics of F_BUS_DIR during normal reads:

Thanks Smonson, but this is on your system, not on one of the systems that fails, right? And again, more important, all the scope captures might be on a good read, not on a "bad" one. You cannot take for granted they would be the same. Yeah, they are not likely to be different. But as you agree, all the options are unlikely, so you have no choice but to consider the unlikely.

I was wondering if, once this all works flawlessly, it would be possible to have the FPGA optionally output the video using a "scanline look" filter. You know, like the OSSC and the Framemeister do.

ijor wrote: 04 Dec 2018 10:24 Thanks Smonson, but this is on your system, not on one of the systems that fails, right? And again, more important, all the scope captures might be on a good read, not on a "bad" one. You cannot take for granted they would be the same. Yeah, they are not likely to be different. But as you agree, all the options are unlikely, so you have no choice but to consider the unlikely.

Yes, but the chances of it being different on Icky's machine are now billions to one, because Icky's board worked fine on my machine, and we've already confirmed that it resembles this scope observation on Icky's machine on his LA, and the verilog for generating this signal is straightforward, and we've already observed a different phenomena that can explain all of the symptoms (D9 being high).

I'm open to the possibility that there's something wrong with F_BUS_DIR, but the chances seem to be about as low as if aliens were doing it.