Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor »

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: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

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 4103 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 4103 times
fpga-cs-vs-oe-end.png
fpga-cs-vs-oe-end.png (5.5 KiB) Viewed 4103 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 4103 times
fpga-cs-vs-d8-end.png
fpga-cs-vs-d8-end.png (5.62 KiB) Viewed 4103 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 4103 times
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 »

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 4102 times
The waveform appears stable.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor »

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

Re: Project: HDMI/DVI out for STFM

Post by ijor »

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
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 »

ijor wrote: Sat Dec 01, 2018 8:14 am Are all these 3 signals directly connected to the FPGA external pins?
Yep. They are all verilog inputs, passed directly to the shifter module.
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.
I guess the next most logical failure mode for this scenario is that R/W is not being driven high enough to be buffered by the '245s on the FPGA board (we have seen Icky's CS and it looks good to me).

That signal goes straight from the shifter socket, through the ribbon cable, and direct to the input on one of the 5v-tolerant buffers, then to the FPGA pin:
schem-rw-buffer.png
schem-rw-buffer.png (9.91 KiB) Viewed 4085 times
That signal is somewhat noisy on my machine, but when it drives low, it really hits the floor. It originates with the 68000 and has a 4.7K pullup to 5v in the schematics I'm looking at.

Troed or Icky, perhaps you could be kind enough to provide a scope shot of R/W when you have time?
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 »

ijor wrote: Sat Dec 01, 2018 8:25 am I realize that probing DIR might be difficult, but this seems to be really the most critical signal.
You can get DIR from the pin that I've extended here:
dir-pin.jpg
dir-pin.jpg (85.72 KiB) Viewed 4079 times
Bottom group, 4th pin from the right, top row. Likewise, The buffered R/W is just to the right of it.
ijor wrote: Sat Dec 01, 2018 8:25 am 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.
I can do that easily enough, except that I can't seem to find any reference to MFP_CS. Is that exposed on the parallel port?
czietz
Posts: 547
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post by czietz »

ijor wrote: Fri Nov 30, 2018 8:59 pm 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.
Two suggestions:
1. Create a trigger signal only when the error occurs, as ijor suggests. I like to use a read access to the cartridge port address space (0xFA0000 - 0xFBFFFF), which will cause a pulse on /ROM4 or /ROM3 depending on the address. It's obviously advisable to connect this signal to the external trigger input of the scope in order not to waste an analog channel for it.
2. Add a delay between each read of the Shifter so that the scope reliably triggers on each read. I.e. the time between individual reads of the Shifter register needs to be larger than the scope's dead time. After reading the "bad" value stop reading. The the last acquisition by the scope will be the bad case.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Project: HDMI/DVI out for STFM

Post by ijor »

Smonson wrote: Sat Dec 01, 2018 8:57 am I guess the next most logical failure mode for this scenario is that R/W is not being driven high enough to be buffered by the '245s on the FPGA board (we have seen Icky's CS and it looks good to me).
Not so sure this is very likely. If you would get a low RW, you would interpret it as a write cycle and you would write random data to the resolution register.

But let's see the traces and we'll hopefully be much wiser :)
I can do that easily enough, except that I can't seem to find any reference to MFP_CS. Is that exposed on the parallel port?
I meant the MFP chip select, which would be asserted when reading any MFP register. Or, if you prefer, and as Christian suggests, you can use a cartridge space address to activate one of the ROM signals. May be even both the MFP and the ROM, so that you could probe either one. It also depends on interrupts being disabled or not.
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: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

Thanks for the good advice czietz.

I've uploaded a new version of the test disk here:
http://smonson.com/unmanaged/atari/shifter-test-2.st
http://smonson.com/unmanaged/atari/shifter-test-2.hfe

On seeing an unexpected shifter value, it reads a word from 0xFA0000. In between shifter reads, it does 15,000 reads of a memory location to add a delay. Also, it will trigger when any bit is set outside the binary mask 0000001100000000.
Post Reply

Return to “FPGA DEVELOPMENT”