Project: HDMI/DVI out for STFM

General discussions or ideas about hardware.
Gunstick
Posts: 56
Joined: Tue Aug 22, 2017 12:42 pm

Re: Project: HDMI/DVI out for STFM

Post by Gunstick » Tue Dec 04, 2018 11:04 am

For testing shifter accuracy with the bus capacitance remanance, you can use this and compare if it looks like that.
(at minute 54)
:D

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

Re: Project: HDMI/DVI out for STFM

Post by ijor » Tue Dec 04, 2018 11:16 am

Gunstick wrote:
Tue Dec 04, 2018 11:04 am
For testing shifter accuracy with the bus capacitance remanance, you can use this and compare if it looks like that.
It you are relying on the unused bits, it won't work on this board. I mean, you won't get the same effects because all the data lines goes through a single transceiver.

Btw, did you try that with all the Shifter versions? I didn't test, but I suspect the behavior would be different with an IMP shifter. There are also minor differences when using an IMP MMU as well.
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 » Tue Dec 04, 2018 11:37 am

Smonson wrote:
Tue Dec 04, 2018 10:51 am
...by the way Ijor, have you tried your HDMI mod to see if it works on your machine(s)?
Sorry, not yet. It's not easy for me.

Btw, Gunstick's post reminded me. You shouldn't drive the data bits that Shifter doesn't use. A real shifter never drives those bits. Well, at least the gate array versions. Can't say for sure about IMP Shifter.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

czietz
Posts: 138
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post by czietz » Tue Dec 04, 2018 5:51 pm

Sorry, I missed a lot of posts in this thread the last few days. But iirc Smonson made a test program that generates a trigger signal upon faulty reads. Wouldn't the best way forward be to use that test program and to probe (with a scope) e.g. D9 at every buffer, level shifter or latch it passes through. Somewhere it must get corrupted. Then look at the direction and/or output enable signal of the IC where D9 is not passed through correctly.

Gunstick
Posts: 56
Joined: Tue Aug 22, 2017 12:42 pm

Re: Project: HDMI/DVI out for STFM

Post by Gunstick » Tue Dec 04, 2018 11:50 pm

ijor wrote:
Tue Dec 04, 2018 11:16 am
Btw, did you try that with all the Shifter versions? I didn't test, but I suspect the behavior would be different with an IMP shifter. There are also minor differences when using an IMP MMU as well.
Oh, if I knew which STs have an IMP. Looks like I'll need to open them all up. Well the one problem-ST I have currently open only has one IMP chip: C070714-001 (GLUE) and on that one neither closure nor DSOTS run. So I first get to work to make a fullscreen running on this strange hybrid.

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

Re: Project: HDMI/DVI out for STFM

Post by ijor » Wed Dec 05, 2018 1:28 am

czietz wrote:
Tue Dec 04, 2018 5:51 pm
But iirc Smonson made a test program that generates a trigger signal upon faulty reads. Wouldn't the best way forward be to use that test program and to probe (with a scope) e.g. D9 at every buffer, level shifter or latch it passes through. Somewhere it must get corrupted.
Note that it doesn't exactly seem that D9 is corrupted. It seems that at least on some cycles, the bus (the local Shifter-RAM bus) is not driven at all. If this is true, this could only happen at the level shifter or possibly at the FPGA itself.

Probing D9 at the FPGA side on a "bad" read might be interesting. But unless the scope can probe two signals and trigger on a third one, then it might be difficult to match the D9 signal with the Shifter access.
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 » Wed Dec 05, 2018 1:41 am

Gunstick wrote:
Tue Dec 04, 2018 11:50 pm
Oh, if I knew which STs have an IMP. Looks like I'll need to open them all up.
Well, you can try Closure and Aliens' 4-bit sync scroll. If both work then probably it is a "common" 38-A Shifter.
Well the one problem-ST I have currently open only has one IMP chip: C070714-001 (GLUE) and on that one neither closure nor DSOTS run.
Interesting. I think that this is not an officially supported setup. Other people here might know better, but I think Atari never shipped a computer with just an IMP GLUE alone. And actually there are some Atari notes warning about mixing IMP and older chips. Probably some combinations are safer than others though.

You didn't specify how you are reading the bus capacitance. If you are just reading from unpopulated RAM space, then this doesn't depend on Shifter at all.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

czietz
Posts: 138
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post by czietz » Wed Dec 05, 2018 6:35 am

ijor wrote:
Wed Dec 05, 2018 1:28 am
Probing D9 at the FPGA side on a "bad" read might be interesting. But unless the scope can probe two signals and trigger on a third one, then it might be difficult to match the D9 signal with the Shifter access.
That's why (in an earlier post) I wrote to connect the trigger signal of the test program to the external trigger input of the scope, which leaves the two channels for probing signals.

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

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Wed Dec 05, 2018 8:45 am

ijor wrote:
Wed Dec 05, 2018 1:28 am
Note that it doesn't exactly seem that D9 is corrupted. It seems that at least on some cycles, the bus (the local Shifter-RAM bus) is not driven at all. If this is true, this could only happen at the level shifter or possibly at the FPGA itself.
The last test config file I've prepared should be able to indicate which of these two scenarios are occurring.
czietz wrote:
Tue Dec 04, 2018 5:51 pm
Sorry, I missed a lot of posts in this thread the last few days. But iirc Smonson made a test program that generates a trigger signal upon faulty reads. Wouldn't the best way forward be to use that test program and to probe (with a scope) e.g. D9 at every buffer, level shifter or latch it passes through. Somewhere it must get corrupted. Then look at the direction and/or output enable signal of the IC where D9 is not passed through correctly.
Yes, it only remains for a generous person to have time to do this test, which is another in a series of tests that has been very time-consuming for those volunteers so far. Let's not rush them :)

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

Re: Project: HDMI/DVI out for STFM

Post by ijor » Wed Dec 05, 2018 11:33 am

Smonson wrote:
Wed Dec 05, 2018 8:45 am
The last test config file I've prepared should be able to indicate which of these two scenarios are occurring.
...
Yes, it only remains for a generous person to have time to do this test, which is another in a series of tests that has been very time-consuming for those volunteers so far. Let's not rush them :)
I was thinking ... for a change :) ...

I would like to see good scope dumps of both F_DIR and D9 at the FPGA side, both on a "bad" cycle, both on a failing system of course. May be F_DIR is not reaching a voltage high enough for the transceiver to change direction. This might depend a lot on the specific system, and then it might explain why the same board works on one system but not on the other.

Note that in turns this might have damaged the FPGA ports because failing to change direction would create bus contention. Specially when it was tested without the resistors.

But I have a feeling that eventually we won't have much choices but to follow Exxos idea of shipping a failing system to Smonson. I agree with Troed that we don't know if this is related to motherboard revision. So it has to be a full system including at least motherboard and HDMI board, that was tested to fail. If shipping cost is the problem may be we can all share the cost. I wouldn't mind to contribute.
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”