Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post 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
User avatar
exxos
Site Admin
Site Admin
Posts: 23500
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post 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...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post 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.
User avatar
exxos
Site Admin
Site Admin
Posts: 23500
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post 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...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post 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.
czietz
Posts: 548
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post 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?
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post 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
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: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post 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
User avatar
Icky
Site Admin
Site Admin
Posts: 3986
Joined: Sun Sep 03, 2017 10:57 am
Location: UK

Re: Project: HDMI/DVI out for STFM

Post 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.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

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

Return to “FPGA DEVELOPMENT”