Project: HDMI/DVI out for STFM

General discussions or ideas about hardware.
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 8:57 am

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 708 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: 318
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sat Dec 01, 2018 9:14 am

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 701 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: 167
Joined: Sun Jan 14, 2018 1:02 pm

Re: Project: HDMI/DVI out for STFM

Post by czietz » Sat Dec 01, 2018 9:18 am

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

Re: Project: HDMI/DVI out for STFM

Post by ijor » Sat Dec 01, 2018 9:34 am

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: 318
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sat Dec 01, 2018 10:23 am

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.

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 » Sat Dec 01, 2018 10:59 am

Smonson wrote:
Sat Dec 01, 2018 10:23 am
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.
I have just captured a video of running this. Also wanted to show you the warts and all process of getting to run this with the resetting and sometimes out of phase TOS message screens. Just uploading video so will post shortly.

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 » Sat Dec 01, 2018 11:15 am

Icky wrote:
Sat Dec 01, 2018 10:59 am
Smonson wrote:
Sat Dec 01, 2018 10:23 am
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.
I have just captured a video of running this. Also wanted to show you the warts and all process of getting to run this with the resetting and sometimes out of phase TOS message screens. Just uploading video so will post shortly.
This is a warts and all to show the resetting many times and eventually getting to the program. Only interaction with ST is pressing escape to speed boot process.

It shows reboots with out of phase TOS boot message, running the program and dropping directly to desktop and resetting. Then finally running the program with output around the 1 min 30 sec mark.


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 11:38 am

Thanks Icky. That odd boot screen is probably due to the shifter being in one resolution and TOS in another. I'm sure it will go away when the read issue is resolved.

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 12:27 pm

Smonson wrote:
Sat Dec 01, 2018 11:38 am
Thanks Icky. That odd boot screen is probably due to the shifter being in one resolution and TOS in another. I'm sure it will go away when the read issue is resolved.
It might be better to run the program from the boot sector instead of from the AUTO folder. Much less chances that it would trigger a reset.
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 12:31 pm

Icky wrote:
Sat Dec 01, 2018 10:59 am
I have just captured a video of running this. Also wanted to show you the warts and all process of getting to run this with the resetting and sometimes out of phase TOS message screens. Just uploading video so will post shortly.
Icky, which chipset version you have on that machine? If you don't know, please post a picture of your MMU chip.

PS: Why my posts still need to be approved after so many posts ??? Do I need to make something?
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”