Page 28 of 67
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 12:08 pm
by troed
I've tested on both an STFM with SMT chips (the doubleST machine, xx589 or what that MB revision is) as well as with a 520ST rev.B. I don't recall if I tested on another STF as well (I think I did but can redo).
/Troed
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 12:34 pm
by exxos
Looking at the video, I assume like bit0 is failing all the time as it has "X" ?
I would suggest put a 50pF cap on the HDMI board side of the resistors and see if anything changes.. if not.. try 100pF...
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 1:21 pm
by Smonson
But on the scope, it's showing a solid low level - and the moment that matters is the end of the latch enable pulse (plus 20ns) when it's had time to become steady. By the way, usually it reads a full 16-bit zero - if it reads the same value repeatedly, the test program doesn't output a new line. On the video you can see bit 0 is alternating between 0 and 1.
The resolution appears in bit 8-9 by the way, as it's an 8-bit register in the top half of the word.
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 1:28 pm
by exxos
With noise you can get caught out though, it might not always be there, or your scope might be loading it enough to "lie" to you.. It might not be noise.. but have to start somewhere...
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 1:37 pm
by Smonson
That's true. Probably the best place to install one for a test would be the underside of the pin header for the ribbon cable. And then if that bit becomes quiet, it'll be proven(ish). I will have to leave it to the mercy of any volunteers.
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 4:04 pm
by czietz
If the "OK" case (i.e. 0 is being read) is much more frequent than the "not OK" case (i.e. weird pattern being read): how do you ensure that the scope screenshots are for the "not OK" case? Maybe the capture was from one of the times that 0 was correctly read and that's why you don't see anything out of the ordinary on them?
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 8:59 pm
by ijor
Hi,
Smonson pointed me to this thread asking me if I could help with the problem ...
Smonson wrote: ↑Fri Nov 30, 2018 8:27 am
Icky has generously donated his time to investigate the weird register reading behaviour with his oscilloscope. This image collects the most important signals into one graphic. I cannot, for the life of me, see where the problem is coming from or how it's possible. If anyone has any theories I'd love to hear them.
I'm not sure scope captures are as useful in this case. A logic analyzer trace showing all the relevant signals together, would probably be much better. And yes, the trace should be trigerred when the error happens. Or yet better, one trace with the expected behavior and another with the unexpected one. You might need to modify the program to produce a convenient trigger signaling each case.
But a couple of relevant signals are missing. The most significant ones are the control for the bidirectional transciever. If doing a trace and you have enough channels, I would add RW and (UL)DS as well.
I understand you can't reproduce the problem, and the user might not have a logic analyzer. But IMHO, that's the recommended next step.
Difficult to be sure, but I agree that it doesn't sound like an analog issue. Anyway, you can capture D8 at the latch output instead of at the input. This would rule out the scope probe interferring, at least on this signal.
For each scope screen, the top trace is /CS, and is the common factor keeping all these screenshots synchronised with each other.
The pattern of bits is also very uniform, e.g. 0xb479 comes up a lot (see video and screenshot posted by Icky above)
This is too suspicious, and it smells like an opcode, let's see ... This is a dissasemble of your test:
Code: Select all
00a36e : 3439 00ff 8260 : move.w $ff8260,d2
00a374 : b479 0001 4e68 : cmp.w $14e68,d2
See the $B479 right after the instruction that read the rez register! So what you are actually reading in those cases is the prefetch of the next instruction. And I would bet that the other values are from video ram. $B479 is read at the border when video read is not active. Seems that for some reason you are not driving the bus, and then the CPU reads the value left from the previous cycle.
If you don't mind, I would like to see the relevant section of the schematics, and also relevant snippets of the Verilog source.
Hope this helps anyway
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 9:43 pm
by troed
Thanks Ijor - perfect insight. I should've caught that - I spent quite some time looking into "snooping the bus" on ST and STE (different methods, but reading Shifter palette register values is one).
I can reproduce the problem and I do have a 16 channel LA.
/Troed
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 10:28 pm
by Icky
Bit late to the party today - not an Atari Friday.
I too have a LA not as many channels as troed. However I just need pointing in the right direction to help. So just point and click and I’ll see how I can help as with troed I can reproduce the problem.
Re: Project: HDMI/DVI out for STFM
Posted: Fri Nov 30, 2018 10:33 pm
by Smonson
This is amazing, thanks Ijor! I'm sure this is a smoking gun that will unravel the whole thing, although I don't yet understand how the shifter's bus driving behaviour can be influenced by a RAM read that comes *after* the shifter read cycle should have finished... I look forward to investigating.
Here's the bus driver schematic section and verilog code:
- schem-bus-driver.png (23.88 KiB) Viewed 4261 times
Code: Select all
// (relevant lines only)
// in top-level module:
output oe; // F_BUS_DIR on schematic
inout [15:0] data;
// shifter implementation
wire [15:0] shifter_data_out;
shifter shifter_model(CLOCK_32, de, cs, load, data, shifter_data_out, rw, addr, oe, shifter_r, shifter_g, shifter_b);
assign data = oe ? shifter_data_out : 16'hz;
// in shifter.v:
module shifter(CLOCK_32, de, cs, load, data, data_out, rw, addr, oe, r, g, b);
input de, cs, load, rw;
input [15:0] data;
output [15:0] data_out;
input [4:0] addr;
output oe;
// data bus
assign oe = (!cs) && rw;
assign data_out = addr[4] == 1 ? {5'b0, resolution, 8'b0} : pal_read;