Here's a photo of mine - apologies it's so blurry, I didn't notice that on the phone screen!

VCC and GND pins appear to be correct but RDY0 and RDY1 look like they're swapped. I will try a capture with the clock connected to RDY0 instead of RDY1.

Looking at this version:

You can just about make out the traces from pins 8/9 to RDY0/RDY1. I'm about 90% sure that RDY0 and RDY1 are labelled incorrectly on the silk screen.

Dave

George, I think your board also has an incorrect silk screen.

On the FX2 IC, RDY1 is pin 9. But on your board it looks like that is connected to the pin labelled RDY0, (on the inner row). I think that's where you need to connect your external clock.

But do check with a meter first!

Dave

Me getting meter probes onto thoses pins was barely possible - I don't have very steady hands! But I think I managed and am confident they were swapped.

However, I still don't see any improvement with the capture, with just RDY0 and PA4 connected.

My device also appears with the 04b4:8613 ID regardless of the jumper position, it's possible the EEPROM comes programmed with that anyway.

That's a shame, I felt sure this was the issue.

The problem is, there are too many variables!

Dave

Is there any chance I broke it by connecting the clock to the wrong pin? I'm also conscious it's a 3.3V device and my signals are 5V. It's seemed happy so far though, regardless.

BTW I did have quite a lot of mileage out of the simple 8-channel device I started out with, which was some sort of Salae Logic clone. It couldn't sample the clock, but it can read 8 bits at 48MHz. I found that the system I was measuring was well-behaved enough that it was possible to identify the discrete clock cycles based on the changes on the data bus. Later I started running the data bus through a D flip-flop clocked at the end of phase 2, which made it very easy to identify the clock boundaries in the data stream, and I wrote a Python script to take this 48MHz 8-bit log and deduce the clock signal to go with it. I think that was pretty good for up to about 10MHz clock speeds, maybe even 16MHz. The thing it had trouble with was data bus samples being taken while the signals are in transition - the Python script required a few steady values on either side of such transitions in order to be confident which data was valid.

I very much doubt it, and it's officially 5V tolerant.

I've just been looking at the EZ-USB datasheet again (it's been a few years since I last looked).

There are various operating modes described.

I ended up using the "Slave FIFO Asynchronous Write", because it allowed the data to be clocked on the falling edge, and it works with the 1MHz/2MHz clock on the Beeb. But I see from the datasheet (page 51) that the maximum clock is ~1/(50ns + 70ns) i.e. about 8MHz.

The "Slave FIFO Synchronous Write" mode (page 50) allows for a much faster clocking (between 5MHz and 48MHz on the IFCLK pin). Although I have no recollection of ever using this mode, it seems I did:
https://stardot.org.uk/forums/viewtopic ... 74#p249774

Without the -a flag, fx2pipe defaults to Slave FIFO synchronous write mode. And the -ifclk option "x" switches the clock source to be the IFCLK pin, and "i" causes it to be inverted so the falling edge used.

So this might be something else to try.

Sorry this is all so complicated!

Dave

Unfortunately no change in behaviour there - I connected GND, and IFCLK to a 16MHz oscillator, but it didn't send any sample data back. I tried with and without PA4 connected to GND.

I also had a look around in case it's worth buying another board of the other kind - they are hard to come by these days except direct from China. I also saw an eBay listing that had photos of both types of board in the same listing, so if there actually is a difference between them, it's hard to see which you're buying.

That said, given that all these pins are just wired straight into the same chip, surely there shouldn't be a difference aside from the pinout/silkscreen errors. Perhaps something in the EEPROM.


It's not your fault!

I seem to be missing a post from the thread... maybe the forum software is acting up again. But, I will try to supply the same information as George:

My device always appears to lsusb as: regardless of whether the jumpers are on or off; in fact, I'm not sure what the jumpers are meant to do here. They don't seem to affect the LEDs either.

My board appears to be exactly the same one as George's - here's a picture of it:

Edit: More info; my RDY1 is on the left (outside) row, my RDY0 is on the right (inside) row. RDY1 appears to be connected to pin 8, while RDY0 is connected to pin 9.

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

J1 is in series with the ground for the two LEDs in that corner of the board, one in particular that flashes when you are sampling data - it makes it not light up.

J2 on the other hand... seems to fix the problem! Combined with using the pin labelled RDY0 instead of RDY1, as these are mislabelled on this board. So it was these two things together that were wrong - I'd unfortunately ruled out J2 as a solution a long time ago, and not tried until now having it removed while using RDY1.

So connecting a clock to RDY1, PA4 to ground, and GND to ground, with J2 removed, I can get samples from fx2pipe:



So that's good! This is the asynchronous synchronous mode, which Dave said is limited in clock speed to about 8MHz. The command for the IFCLK mode didn't work for me, even with J2 removed. I'm tempted to check the pin is labelled correctly etc though and go from there.

Great news though, and thanks for mentioning the jumpers again as I'd been overlooking them for a while now!

Interesting. Mine still blinks even with that jumper off. It must have a solder bridge. (It really is a fairly low-quality board).

Heeey, cool. I was just reading on another site that J2 seems to have something to do with programming the EEPROM. Maybe with J2 shorted the firmware wasn't getting downloaded?

This is no longer necessary, I guess, but I'll go ahead and share: I finally tracked down an Amazon seller who has the original LCSoft mini version of this board for $12: https://www.amazon.com/EZ-USB-FX2LP-CY7 ... 07Z8W5GSR/

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

Ooh, this works for me too now! I noticed in the timing diagram that Dave posted (page 50) that even in synchronous mode, it wants SLWR to be low - that's RDY1, which is labelled RDY0 on our boards. So tying that low and rerunning the --ifclk=xi command caused it to grab some data.

I was able to sample my system running at 16MHz very well. One problem I found was difficulty sampling from an "off" state - for some reason that didn't work well. But I wanted to capture the reset, so I connected the 6502's NRESET line to the FX2LP's PA5 pin - when this is low, it disables capture. Then I can hold the reset button, run the command, wait for it to be ready, then let go of the reset button:



Now I swear this program has black magic in it - I'm going to lose sleep tonight wondering how on earth it's able to detect an interrupt scenario from sampling only the data bus:


The prediction failure is due to that location being a VIA's IFR register.

It's amazing what can be achieved from sampling so few lines, and it makes the whole thing much easier to use than other options, much easier to plug in when it's needed. There are a few output options that I think could be added, and it still struggles when it doesn't know the machine state (like starting a capture while the system is already running) and in those cases maybe a little human help could be supported - telling it what the program counter is, register values etc if we can figure them out, or even just that a certain branch was not taken (as it seems to assume they're all taken if it's not sure).

I also tried capturing at 25.175MHz, and while this seemed to work when starting from a running system, it didn't work from reset - fx2pipe seemed to get blocked up after receiving only one block. It's possible that the clock signal I'm sending to the FX2LP is not clean enough - it's certainly not symmetric as I stretch it a lot. But then, it didn't mind at 16MHz - so perhaps it's just too fast.

That's great news that it is all now working

J2 I think connects to bit A0, which sets the EEPROM device address.

So I guess the EEPROM must contain more than just the IDs? That's probaly described somewhere in the datasheet.


It uses a heuristic based on what's expected to be seen in bus cycles 2, 3 and 4:
https://github.com/hoglet67/6502Decoder ... 502.c#L610

I could tighten this up further, because the data in cycles 0 and 1 should always be equal (the opcode that is interrupted).

So an interrupt would match the sequence:

If you new the possible vector values, then you could tighten this further.

This does add a fair amount of overhead to decoding each instruction.

I would be interested if you encounter any false positives.

Dave

It seems that way - briefly mentioned on page 6:


So the EEPROM can either provide just a device ID, or initial content for the internal RAM. I thought fx2pipe would be overwriting that with the custom firmware though.


A command line option like --vecrst could work - could it also use memory modelling to track the vector value? It may be reliable enough already but it could also check the expected first instruction of the ISR (through memory modelling again).

I wondered something similar about branches when the flags are not known - I tried a 16-bit capture with "sync" and "rnw", which worked fine even at 25MHz, and now it knows whether such branches were taken or not based on "sync". But in many cases I think it could also have been able to tell from whether the content of the extra cycle matched the opcode of the next instruction.

Did this work for you in the end?

And for Dave - if this works for Paganini then we should probably update the wiki with the new information, is that something you'd like to do or would you like some help with it?