Or, 3 days in dependency hell.

Hi guys, I just got back from visiting the late '90s, where I tried to build a project in Slackware linux... wait, that's not right. Actually, I just spent the weekend trying to install SIGROK on my 10 year old MacBook pro. The short answer is, this cannot be done.

Both Ed (BigEd) and George (gfoot) have advised me to acquire an inexpensive logic analyzer board and come to grips with Hoglet's decoder for the 6502. I figured it was about time to do that. If you are, like me, a relative newcomer to electronics and have only a hazy concept of why a logic analyzer is different from a logic probe and how what you use it for is different from what you use your oscilloscope for, have I got a great video for you: https://www.youtube.com/watch?v=dobU-b0_L1I

This video is from the author of the SIGROK "Pulseview" software and covers all kinds of important stuff, including what a logic analyzer is for, which inexpensive hardware boards you might want, where to buy them, and the difference between good and bad probes. Towards the end there's even a circuit simulation showing the effect of probe inductance on a transmission line that made me think about posting this to the "high speed digital circuits" thread. Anyway, it's a great video. If you're not already an expert, go watch it!

I picked up two inexpensive logic analyzers from Amazon. An 8 channel one, and a 16 channel one. Both of these boards use the open-source Fx2lafw firmware. The 16-channel one is the same board recommended for use with Hoglet's decoder, since you really need 12 channels to get the best results with it. The 8-channel board came with a USB cable and some female/female Dupont wires. The 16-channel board came with... the 16-channel board. Neither board had any kind of manual so I had to dig around through a whole pile of excessively bad documentation to figure out some basic things. In particular, the Lcsoft Mini Board is just a devboard with all of its microcontroller pins broken out into headers. It's not immediately obvious which of those pins are used by the FX2lafw firmware as the logic analyzer channels. At long last I found what I needed buried in this guide:In order to capture data for Hoglet's decoder to decode you need some software such as sigrok-cli or PulseView to communicate with the logic analyzer hardware. This is where things get sticky. The SIGROK project appears to have been all but abandoned. The SIGROK wiki suggests that for best results you should use the NIGHTLY build packages, rather than the stable release versions. Unfortunately, the nightly build links on the SIGROK downloads page have been broken since February 2023. That page suggests using an Archive.org snapshot to download nightly builds from December of 2022. Unfortunately, those Archive.org links are also corrupted. So I spent the next three days typing into my MacOS terminal trying to trace the dependency chain in order to build from source. (I could have done this with one command in Ubuntu! ) The SIGROK wiki suggests that the best (only) way to do this is to use Homebrew, which failed immediately for me. I went through a whole process of cloning git repositories trying to build the dependencies by hand, and finally determined that the actual problem is that two upstream packages (QT5.5 and Python2) have dropped support for MacOS Catalina. And... that's pretty much where I am right now. I can't use sigrok-cli (there is no release version of it for Mac) and the release version of PulseView (0.42) is truly truly awful. As in, can't type into configuration fields because all keypresses are captured and interpreted as navigation commands for the main window, awful

The laptop I normally use for my retrocomputing activities is a Thinkpad X41. It *does* have USB 2.0, but it only has a 1.5GHz Centrino processor and 1.5GB of RAM, so I'm not sure it will be able to keep up. I guess my next project is to install SIGROK on it and find out!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I got that 8-channel Saleae analyzer to work with sigrok under Windows 10, but my Hantek USB scope doesn't work with sigrok. The bundled Hantek software is adequate though.

The other, arguably better, option for capturing data from a FX2-based logic analyzer is a standalone program called fx2pipe written by Wolfgang Wieser.

fx2pipe allows the FX2 to be clocked from an external clock, which would typically be the 6502 phi2 clock. One sample is taken per 6502 bus cycle, at exactly the point data bus is stable (i.e. on the falling edge). This greatly reduces the volume of data that needs to be captured. It's not possible to use this mode in sigrok. I rarely use sigrok myself now.

Here's the original website:
http://www.triplespark.net/elec/periph/ ... 2pipe.html

I have included a slightly modified version of fx2pipe in my 6502decoder repository:
https://github.com/hoglet67/6502Decoder ... er/fx2pipe

I use this program on Ubuntu 18.04.

To enable the external clock capture mode, you need to:
- connect Phi2 to the RDY1 pin of the FX2
- connect the PA4 pin of the FX2 to ground
- pass the -a option to fx2pipe

I have no idea if it's possible to build fx2pipe on MacOS - the main external dependency is libusb.

By the way, if you just want to use sigrok to capture data, the sigrok-cli tool has far fewer dependencies the pulseview. Pulseview gets rather slow anyway when visualizing large capture files. In fact, the 6502 decoder started life as a sigrok protocol decoder, written in python. But for performance reasons it's now a standalone C program that runs at least 100x faster.

Dave

Hi Dave,

Thanks for the reply! I've pretty much given up doing this on my Mac at this point; I can't get even libsigrok to build, let alone Pulseview. I did just now, between the last post and this one, go upstairs to the Thinkpad. It took all of 10 minutes to get everything set up and working (for some value of working). I saw that the code for fx2pipe came with your decoder, but I didn't know what it was. Thanks for the tip; I'll go ahead and build that next.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

The other option, if you have one available, is to use a Raspberry Pi 4.

I wrote some notes on that here:
https://github.com/hoglet67/6502Decoder ... berry-Pi-4

It may well be worth you reading over that page anyway, as the instructions for building/using fx2pipe are pretty generic, and should be roughly the same on MacOS as well.

Dave

That was very helpful! I haven't quite got fx2pipe working though. It built fine, and seems to go, but then just sits there without receiving anything from the dev-board. I did manage to get a good capture with sigrok and decode it:


I think this is operating at the very limit of what my poor thinkpad can manage though. I had to set the capture rate down from 12MHz to 8MHz or it would give up before it was done. That's no problem for now (my board is running at 4MHz for now) but I would like to go faster eventually!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I do sometimes find the capture gets stuck like this. Usually just unplugging the fx2 board resolves it, but occasionally it seems to be a host kernel issue that requires a reboot to fix.

What version of libusb do you have?

It seems that fx2pipe needs version libusb-0.1 and fails when using libusb-1.0:
https://www.eevblog.com/forum/programmi ... ibusb-1-0/

This is something I wasn't aware off. I'll check later what version I have.

That thread also includes an fx2pipe replacement called cannelloni, which I plan to try later.

When using sigrok, because the sample clock is asynchronous to the 6502 clock, you need to oversample significantly. For example, on a 2MHz BBC Micro I need to capture at 12MHz (i.e. 6x oversampling). At 8MHz (4x oversampling) I see random errors. This is dependant on how long the read data is stable on the data bus for. Just something to be aware of.

Dave

FYI, I'm using libusb-0.1-4

Dave

I appear to have *both* libusb-0.1-4 and libusb-1.0-0. It looks to me like the libusb-dev dummy package installed the development libraries for 1.0-0, though. I don't see libusb-0.1-4-dev anywhere in my apt. I'm guessing the libusb-0.1-4 package is just a dummy package for compatibility with old programs.

My thinkpad has gone about a week and a half without a reboot, so I guess it's OK to restart it and see if anything changes.

The USB cable that came with the logic analyzer is really long, too. I'm going to see if I can fish out a shorter one. (Not that this will fix the problem with fx2pipe, but it might lead to better results overall.)

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I had the same problem with fx2pipe not collecting any data a few days ago, unfortunately I wasn't in the best mental state and put off trying to resolve it!

I did try fx2sharp on Windows, but couldn't work out how to build it - I was using Visual Studio 2017, and I got a copy of CyUSB.dll from the Infineon website as it seemed to be required, but it seems to want to run a git command from the build process, and I'm not sure I trust it to do that. If there's any documentation on how to build this though, I'd be happy to follow through.

I also found a thing called canneloni which claims to be a libusb-1.0 compatible version (rewrite?) of fx2pipe - and this was easy to build and run, and seems to work better. I haven't been able to get it to do an async capture yet (-a) but sync capture seems to work if I provide the right "pin inverting" options. So it looks promising. Unfortunately the github for this has gone 404 for some reason - I built it from a version distributed in a zip file on another forum somewhere!

Sorry to hear that George; hope you're feeling better!

I tried a couple of the fx2pipe fixes from the thread that Dave (Hoglet) linked to upthread, with no luck. I didn't try Cannelloni; it looks like the project is defunct, and the available source code is outdated. But, if you get good results with it I may change my mind!

What I would like to do is have some kind of test program in a ROM that I could boot from then use the logic analyzer / decoder to observe it. I'm thinking of doing this with a minimal Blue August configuration - CPU, ROM, RAM, decoding glue, but not IO - and gradually increasing the system clock speed to see when I start getting errors.

First, I guess, does this seem like a good idea? And, second, what would such a test ROM look like, and does one exist already? I've seen the Klaus Dorman test suite mentioned in a few threads. Would that work for this? My impression is that maybe it wouldn't be a good choice, since it seems to have been designed for testing emulators, not real hardware, and supplies a full 64k memory image. It seems to be designed to run from RAM and requires an interactive monitor program to load it on real hardware.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Thanks


I'll post here if I get it working - I don't have a good understanding of what it's trying to do yet though, e.g. the need for the "-a" option as I thought the idea was to do synchronous captures. I suspect it is not seeing my clock signal but I don't know how that is configured, it will probably require understanding the firmware code to diagnose it further. And this could then be the problem with fx2pipe as well - it may not be related to libusb at all.


That should be good. The issue with clock speed really depends on your system - there's a question of whether to take the data bus sample from just before the phi2 falling edge or just after it, which matters a lot if the sample rate is not much higher than double the system clock rate because it's possible that neither of those samples actually includes the right data bus data! I think hoglet found that for different Acorn computers it worked better in different configurations. But so long as the sample rate is much higher than the CPU clock rate, it should be good. I tried to get four or five samples in each PHI2 phase, which means a sample rate 8-10x higher than the system clock.


The Dormann tests are pretty good. I had some doubts but Dave encouraged me to give them a go, and it was worth it.

The tests fairly thoroughly cover aspects of the CPU's behaviour - all combinations of operands for each operation, for example - but they're not soak tests (out of the box) and they don't particularly test your address decoding, for example - all the absolute addressing mode tests use the same block of memory, it doesn't exercise the whole memory map. So you could supplement them with something that does.

They do have an option to verify that instructions didn't corrupt other areas of memory, but I didn't enable this.

You can enable an option to get text-based output from it in case of errors, which also allows you to give input to tell it to continue or skip - and this also allows asking it to rerun the whole test suite after it finishes. I rigged the "get chararcter" mode to alternately return "C" for continue and "R" for rerun, so that I could leave it running unattended for a soak test.

They are by default designed to be loaded by some form of monitor program, but you can change some settings to make it work from ROM instead. For my purposes I made my ROM copy the test suite to RAM and run it from there because my system runs faster from RAM and that's what I wanted to test.

I had to make a minor change to the test code as well to work around an assembler error related to testing of BRK, which is not possible when the system vectors are in ROM. There's an option to skip this test, but it still caused errors unless a couple of extra labels were defined, so I just defined them in a random place!

By far the biggest obstacle to running the Dormann tests is the assembler itself, which is unusual and no longer officially available. A copy of the assembler is bundled with the tests, and I think there's also a github fork with the test suite converted to a more common assembler. I used the supported assembler to assemble the image, then embedded it in my ROM code as a binary blob so that my ROM code could still be written with an assembler that I'm more familiar with.

There is definitely some confusing terminology here...

What I have been calling "synchronous capture", is where the 6502 clock is connected to the RDY1 pin of the FX2 and is used as an external capture clock. From the perspective of the 6502 bus, the samples are synchronous to the 6502 clock, with exactly one sample being taken on the designated clock edge.

Unfortunately, fx2pipe refers to this capture mode as "asynchronous", because from the perspective of the fx2, the external 6502 clock is indeed asynchronous to it's internal clock.

The -a flag to fx2pipe configures the firmware to expect an external clock on the RDY1 pin. If no clock is present, no data will be sampled.

If you omit the -a flag, then the FX2 will use it's internal clock. Do you get any data in this mode?

The other possible reason for fx2pipe hanging is a conflict with the usbtest module. But I would expect this would break sigrok as well.

Dave

apt doesn't list anything for "libusb" or "lib-usb" but:


That looks like 0.1 I think.





Ah I see, that makes sense.


Without "-a", I do get correct-looking data, with both fx2pipe and cannelloni. Neither works with "-a" - cannelloni reports a timeout after a second or two, while fx2pipe seems to wait more patiently.

cannelloni also gave the timeout error when launched without "-a", until I provided it with its "-x" option which "Inverts polarity of 'SLWR' input pin (i.e., assert high)".

fx2pipe and cannelloni both require me to "sudo modprobe -r usbtest" after plugging in the device (I didn't blacklist usbtest yet). sigrok-cli doesn't require this.

I suspect the issue here is the specific boards we are using, rather than the library version. Mine has a different pin layout to yours, has the extra jumper, and reports different device IDs I think. Is it possible they need different pins to be connected? I have a fairly slow signal going into RDY1 from an output pin - not my main clock, I wanted to get it working with something more sedate first. I also have PA4 tied low, and 8 bits of signals to sample wired through to PD0-7.

I actually have two boards.

With the jumpers off, they both report 04b4:8613, which is the ID in the Cypress FX2. It's this ID that the USBTEST kernel modules binds to.

With the jumper on, they report whatever ID is programmed into the SPI EEPROM:
- Board #1 (bought in 2017 from Hobby Components) reports 1D50:608D (Sigrok 16-bit capable FX2)
- Board #2 (bought in 2019 on ebay) reports 0925:3881 (Salea Logic 8-bit capabile FX2)

Both of mine look like this:


Can you post a photo of your board?

Looking on ebay, I can find some versions of this board where one of the connectors is labelled differently. For example, RDY0 and RDY1 are swapped, and one of the 3V3 pins has changed to be a GND pin. I'm wondering if this is an error on the silk screen, or whether these are a real pinout changes.

In particular, can you check that the RDY pins are connected to the correct pins on the FX2 chip itself? RDY0 should connect to pin 8 and RDY1 should connect to pin 9.

The full set of signals to configure the FX2 to capture using an external clock on RDY1 is:
- PA5 = high (FIFOADR1)
- PA4 = low (FIFOADR0)
- PA2 = high (SLOE)
- RDY0 = high (SLRD)
- RDY1 = Phi2 (SLWR)

On my board unconnected inputs seem to float high, so I have only needed to jumper PA4 to GND. But it's possible relying on this is dodgy!

Dave