Project: HDMI/DVI out for STFM

General discussions or ideas about hardware.
czietz
Posts: 167
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post by czietz » Fri Nov 30, 2018 4:04 pm

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?

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor » Fri Nov 30, 2018 8:59 pm

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
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

troed
Moderator
Moderator
Posts: 508
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Fri Nov 30, 2018 9:43 pm

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

User avatar
Icky
Moderator
Moderator
Posts: 1720
Joined: Sun Sep 03, 2017 10:57 am
Location: UK

Re: Project: HDMI/DVI out for STFM

Post by Icky » Fri Nov 30, 2018 10:28 pm

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.

User avatar
Smonson
Posts: 318
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Fri Nov 30, 2018 10:33 pm

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
schem-bus-driver.png (23.88 KiB) Viewed 758 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;	

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor » Fri Nov 30, 2018 11:48 pm

Smonson wrote:
Fri Nov 30, 2018 10:33 pm
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.
I'll post more details later, but no, it is not after the shifter read, it is before. This is how the 68000 prefetch works. And if the bus is not driven, and not being any pullups on this bus, it retains the previous value due to capacitance.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

User avatar
Smonson
Posts: 318
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sat Dec 01, 2018 3:54 am

Here are some more captured traces from my test circuit. Please excuse the image spam.

This is the behaviour of the real shifter's CS vs D8 line driving a 1K load to ground (the registers contain 1 on power-up):
shifter-cs-vs-d8.png
shifter-cs-vs-d8.png (5.72 KiB) Viewed 732 times
This is the FPGA board's CS vs F_BUS_DIR pin:
fpga-cs-vs-oe-start.png
fpga-cs-vs-oe-start.png (5.49 KiB) Viewed 732 times
fpga-cs-vs-oe-end.png
fpga-cs-vs-oe-end.png (5.5 KiB) Viewed 732 times


And the behaviour of the FPGA CS vs D8 line driving a 1K load to +5 (the registers contain 0 on power-up):
fpga-cs-vs-d8-start.png
fpga-cs-vs-d8-start.png (5.57 KiB) Viewed 732 times
fpga-cs-vs-d8-end.png
fpga-cs-vs-d8-end.png (5.62 KiB) Viewed 732 times
These are the two D8 diagrams overlaid, in which you can see the real shifter begins to drive later and continue to drive later, a delay of about 12nS:
shifter-fpga-overlaid.png
shifter-fpga-overlaid.png (6.73 KiB) Viewed 732 times

User avatar
Smonson
Posts: 318
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sat Dec 01, 2018 4:15 am

And this is CS vs R/W (on an ST during vblank reads):
cs-vs-rw.png
cs-vs-rw.png (6.08 KiB) Viewed 731 times
The waveform appears stable.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor » Sat Dec 01, 2018 8:14 am

Smonson wrote:
Sat Dec 01, 2018 3:54 am

Code: Select all

    assign oe = (!cs) && rw;
Are all these 3 signals directly connected to the FPGA external pins?
These are the two D8 diagrams overlaid, in which you can see the real shifter begins to drive later and continue to drive later, a delay of about 12nS:
This is expected, but shouldn't be relevant. What really matters is the relation with LATCH, not with CS. And LATCH is deasserted half cycle earlier than CS. Furthermore, even if there would be a hold timing problem, the symptoms should be different. Here seems that the bus is never driven at all on those cycles.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor » Sat Dec 01, 2018 8:25 am

Icky wrote:
Fri Nov 30, 2018 10:28 pm
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.
I would trace these signals:

CLK_16MHZ
CLK_8MHZ
SHIFTER_CS
LS373_LATCH
DIR (at the 74ALVC164245 chip at the HDMI board)
D9
CPU_RW
CPU_UDS

I realize that probing DIR might be difficult, but this seems to be really the most critical signal.

Trigger on CS == LOW, LATCH == FALLING EDGE, D9 == HIGH (and one D9 == LOW).

D9 is not the best trigger. If it is high we know it is a "bad" case, but if it is low we are not really sure. Ideally the test program should be modified. It should compare the value with the known resolution, and assert some signal (say, MFP_CS) depending on the comparison. But in the meantime, getting a trace for the "bad" case is much more interesting.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

Post Reply

Return to “HARDWARE DISCUSSIONS”