exxos's Atari, Amiga & retro forum

Capture done. I let it run for 30 seconds and you can clearly see two resets.


Now here is the problem part the capture is 2GB in size. Am going to zip it up and put it on a server somewhere so it can be downloaded.

Icky wrote: 02 Dec 2018 21:22 Now here is the problem part the capture is 2GB in size. Am going to zip it up and put it on a server somewhere so it can be downloaded.

Compression on capture file is huge gone from 2GB down to 354MB. Now to find server to put it on.

Icky wrote: 02 Dec 2018 21:30 Compression on capture file is huge gone from 2GB down to 354MB. Now to find server to put it on.

I have a FTP server you could transfer the file over on if it helps...

Icky wrote: 02 Dec 2018 21:22 Capture done. I let it run for 30 seconds and you can clearly see two resets.

Fabulous! To be honest, something seems wrong on that capture, but may be it is just an artifact of the far zoom out.

Compression on capture file is huge gone from 2GB down to 354MB. Now to find server to put it on.

You should be able to upload the file to any cloud host. Google Drive, OneDrive, DropBox, Mega, whatever. It is even only temporarily if Exxos can put the file on an ftp server.

ijor wrote: 03 Dec 2018 01:38 Fabulous! To be honest, something seems wrong on that capture, but may be it is just an artifact of the far zoom out.

The signals just have the wrong labels, that's all. I've checked it out in detail and it shows that the F_BUS_DIR signal is working perfectly at the time of the bad reads that caused resets, but the D9 line remains in a high-voltage state: Based on this, I'm consulting with Troed to run another test FPGA config file for me (thanks Troed) which outputs zero on all data lines whenever F_BUS_DIR is asserted (i.e. a shifter register read). This should narrow it down to either an electrical problem with signals propagating through the bidirectional buffer (if the test doesn't work); or a verilog bug (if the test does work).

I tested this on my machine and TOS boots up fine (as long as it's in resolution 0, obviously).

I've made a space on smonson.com for Icky to upload the LA file for the time being - is it OK to post the link Icky?

Smonson wrote: 03 Dec 2018 10:31 The signals just have the wrong labels, that's all. I've checked it out in detail and it shows that the F_BUS_DIR signal is working perfectly at the time of the bad reads that caused resets, but the D9 line remains in a high-voltage state:

Based on this, I'm consulting with Troed to run another test FPGA config file for me (thanks Troed) which outputs zero on all data lines whenever F_BUS_DIR is asserted (i.e. a shifter register read). This should narrow it down to either an electrical problem with signals propagating through the bidirectional buffer (if the test doesn't work); or a verilog bug (if the test does work).

Does the capture shows that reading works at all? I mean, do you see any reading where D9 was high before CS was asserted, and then it lowers? Or in all other cases D9 was just low before?

A functional bug might make a lot of sense to explain what we see here. But I'm not sure how a functional bug would depend on the specific ST computer. But let's see the results of that test. Did Troed test reading paletter registers?

I've made a space on smonson.com for Icky to upload the LA file for the time being - is it OK to post the link Icky?

Please do it. Thanks.

Smonson wrote: 03 Dec 2018 10:31 I've made a space on smonson.com for Icky to upload the LA file for the time being - is it OK to post the link Icky?

Thanks Smonson - Just cleaned it up with labelling.

http://smonson.com/unmanaged/icky/st-hdmi-capture.zip

It decompresses to just over 2 GB and you will require Logic to view.

Icky wrote: 03 Dec 2018 14:34 Thanks Smonson - Just cleaned it up with labelling.
http://smonson.com/unmanaged/icky/st-hdmi-capture.zip
It decompresses to just over 2 GB and you will require Logic to view.

Thanks a lot Icky!

Unfortunately the capture frequency is too low, just at 16 MHz. I know it is not your fault, that's the limitation of your logic analyzer. The capture does show that there is definitely a F_BUS_DIR pulse at the failing cycle, and that's very valuable information. But that's pretty much all that can be concluded from the capture. It is not possible to make any conclusions about the timing. And it is very difficult to be sure and answer my own question regarding if reading from Shifter works at all.

Icky, if you don't mind telling us, which TOS version are you using?

ijor wrote: 03 Dec 2018 16:13

Icky wrote: 03 Dec 2018 14:34 Thanks Smonson - Just cleaned it up with labelling.
http://smonson.com/unmanaged/icky/st-hdmi-capture.zip
It decompresses to just over 2 GB and you will require Logic to view.

Thanks a lot Icky!

Unfortunately the capture frequency is too low, just at 16 MHz. I know it is not your fault, that's the limitation of your logic analyzer. The capture does show that there is definitely a F_BUS_DIR pulse at the failing cycle, and that's very valuable information. But that's pretty much all that can be concluded from the capture. It is not possible to make any conclusions about the timing. And it is very difficult to be sure and answer my own question regarding if reading from Shifter works at all.

Icky, if you don't mind telling us, which TOS version are you using?

Yep the LA is a cheap one so suspected there might be a limitation. May be a Xmas present to myself of a pro LA coming up :).

TOS is 1.04

Icky wrote: 03 Dec 2018 17:56 TOS is 1.04

Thanks. I just noted something interesting on the traces. It might be relevant or not ... People, those that tested the HDMI board, can you please tell us which TOS version you used on those system. Troed, Smonson, Exxos?