Wow, Dr. Gusman has made a lot of progress on this since I checked it out a year ago running on my own pico. The software didn't quite have the features I was in need of back then, so I shelved my project. It seems like the updates are enough for me to resume progress on the project, so I'll dust it off in a few weekends. Thanks for demonstrating the recent updates!
Very nice video and I'm really impressed with the developments of the software, great to be able to use SigRok decoders as that was the main reason I would export and use SigRok, cool to be able to stay in the picoLA software only. Glad I sent that original PCBs to you now 😂!
This looks great. I'll definitely be building a few soon. I designed an FPGA-based Logic Analyzer years ago, but never had it made. That used a Cyclone IV (I think?), and FT601Q USB 3.0 chip. That had 64 channels, but could only manage up to about 33 MHz sample rate, unless something like RLE compression is used. But then I saw the CoLA project on sikrok, which is almost exactly what I wanted, but has 96 channels. (I'm a bit hazy on the info below, so there may be some mistakes)... The problem is, CoLA has some quite serious issues with the standard version of Pulseview, because of some FTDI DLLs which aren't open source, or something. You can compile a version of Pulseview with the FTDI binaries included, but I never did manage to get it compiled. lol CoLA also uses a six-layer board, and an oversized Cyclone V, so would be quite expensive to have made. The thing is, those LAs should be capable of streaming directly via USB 3.0 at high speeds, so you can do VERY long captures, directly into RAM on the PC. I'm wondering if there's any way the Pico project could do something similar? AFAIK, the Pico and Pico 2 USB only works up to 12 MBits, though, so that could be a problem for doing long captures to the PC.
I just read some of the README on github. I saw the issue with the Pico 2, which seems quite bad. One of the things I really need a fast LA for, is to help reverse-engineer a modern DLP chip (DMD). I made some progress with that before, by hooking up a projector's LVDS signals to an FPGA dev board. (The intention there, was to build my own three-chip DLP projector, basically.) But I could never *quite* get pixels loaded onto the DMD using my own Verilog. :( It could be very interesting to try the Pico LA with an extension board that has LVDS receivers on it. Even if it can only capture for a relatively small amount of time, multiple captures could probably be joined together. There might even be a way of doing a kind of double-buffering thing, using two or more Pico LA modules. So one Pico is sending the data to the PC, whilst the opposite Pico is capturing more samples, and so-on.
btw, I think a really neat addition to the sigrok decoders would be... To have it actually display what is getting written to the video output on the Speccy. lol Assuming enough samples could be captured at once, the software could reconstruct what is being displayed by the Speccy. And / or, a way to display a hex view of any writes to Speccy DRAM, so a kind of mirror of everything that should be in DRAM. ie. Rather than having to capture the DRAM writes after reset, the Pico just uses a small chunk of memory as a "mirror" of whatever the Z80 is writing to Speccy DRAM. That way, you can keep doing multiple captures on the LA, to update the hex display of DRAM on the PC side.
I did a project on FPGA a while back which does something similar... The FPGA itself generates VGA output with Hex values displayed, for a small chunk of memory. You hook some the FPGA GPIO pins to the device-under-test, which in my case was a Roland D-20 synth board. That allowed me to view a "mirror" of memory, and showed in realtime whatever the CPU was writing to memory and/or mem-mapped registers. That can be a VERY powerful way to help diagnose faulty systems, or reverse-engineer the register map. I used that to help figure out the registers in the LA32 synth chip. I could hit a few keys on a MIDI keyboard, or tweak some CC values, and instantly see the register values update on-screen. It would have taken me about ten times longer to figure anything out from LA captures otherwise.
Oh, even better... I forgot the Pico can be used to output RGB/VGA or even HDMI directly. ;) I know there are projects like RGB2HDMI which use a Pico to output higher-quality video from retro systems. Something like that could be added to the Pico LA software, just not necessarily updated in realtime. Sorry, I know that's a lot to read, but this project just happens to coincide with a lot of what I've wanted for a while.
13 годин тому+8
Those FEFE and FDFE and so on are just IO operations. Check the /IORQ signal on the bus to see it better. Sinclair changes the higher byte of the IN A,(C) - which is in fact IN A, (BC) as the B register (higher part of the BC register) is put on the address bus during IO operations. It is a side effect, but widely used in the Z80 world. Data on the data bus are, what the IO port reads. Refresh is done at the last cycle of the Machine cycle and puts register pair IR on the address bus as well, as it activates /RFSH signal. Register R is only 7bit.
13 годин тому+3
To expand on keyboard reading. Sinclair reads the state in eight subsequent steps. Each for one keyboard "row". Keyboard has 40 keys organized into 8 "rows" of five keys. rows are connected to the A15-A8 address lines with diodes and the five keys in a "row" are connected to the ULA, where they make the lower five bits D0-D4 if the input port FE (which is also a simplification as it requires just A0 == 0 and IORQ == 0 to activate). D6 is the "Ear in" tape reading input bit. So the reading routine sets one row low, which makes possible to read zero in a bit corresponding to a pressed key in the selected row. The same it goes with all eight rows.
The project states a serious problem with the Pico 2 that may impact the usefulness when using a Pico 2. The issues have been mainly addressed, but YMMV.
Thanks for the video, I'll definitely try this software with my pico ! About the PCB design, I advise you to loose the instinct of wanting to nicely bundle up signals close to each other and route them around the periphery of the board ;) it's probably bad for EMI and could cause some false pulses on your lines. I know it's tempting to "cable manage" them nicely in a corner but it's a common mistake I have made lots of time 😅
V2 is much more practical than the original two board solution but 24 channels is not really sufficient even for an 8 bit micro. 32 channels is the realistic minimum for this kind of work and so requires two complete units. Sampling should generally be done at a minimum of 5x the frequency of the signals being measured so 20MHz should be fine for a Spectrum without wasting samples. I am sure that you should be able to find an appropriate header template for the Spectrum user port in the Kicad libraries. Using this world simplify design and prevent problems with components not fitting. The more you get into PCB design the more fun it is! 😁👍
Z80 use the address and data bus in two modes - memory access and input/output. Since the code is about reading the keyboard its likely the port address and I/O data you see. Be curious. Feel free to ask or reach out to me.
You could use a 40pin chip clip, you’d wire it for the z80 and clip it over, quick way to get access to the voltages, clock, address, data and irq lines.
If you place the logic analyser connectors on the reverse side of the Spectrum interface board then the board doesn’t need to be larger for toast rack style machines.
That's true for one analyser, for two though it's more difficult to package, you'd need a double height ( or more) socket for the 2nd analyser and I'd be worried the weight imbalance could cause issues with the connection to the edge connector
@ I’m not sure weight would be an issue (some of the old spectrum expansion boards were a bit hefty). You could place the connectors on the back so that one analyser is vertical and the other is horizontal. Place a support under the horizontal board if you are worried.
Great Work!!! Do you have any idea about the release of this new design?!? I can't wait to build my copy!!!! ZX spectrum was my first computer when I was 6 years old! Rediscovering it with your videos is such a joy!!! Thank you so much!
Interesting idea. It's still not clear to me how exotic the triggering is; probably nothing like a conventional analyzer. Thankfully I rarely ever need to fire-up my scope or logic analyzer (HP16500A) for debugging, as I embed a lot of diagnostics in my RasPi code as well as add hardware debug aids in projects that have an FPGA.
Keep an eye on the GitHub. I'm not sure what the story is with building this yourself, but I do know that people were downloading the V6 data while it was still in the works and potentially not ready, so maybe it's just temporarily down until a design is finalised
Always a good idea. I get lazy and set a bad example especially with new and cheap electronics. If you're somewhere cold and dry, you'll see sparks from static shocks. I work in Lapland once per year and believe me you could damage a board in those conditions
Totally confused by the post about pico2 is dead and not supported. Also is the analyzer only for the hardware and how to get it, … somehow if pico2 issue is solved ?
very nice that should help fixing my spectrum's, also did you mention your an auto electrician i have a Mitsubishi gto that wont start are you close to manchester
There's no sponsor link in the github project, could you ask him to enable it, or maybe suggest the creator of the project to run a patreon? I mean I could raise an issue in the gh repo, but I think a closer contact would be better here. It'll help everyone who wants to help with the project. And wow this project it's really incredible
I included it in the thumbnail, I felt that if I waved this single device around saying it can do 120 channels it's not totally accurate, since you need 5 of them to achieve that
I don't think it's important for the relatively low frequencies we're dealing with on the ZX Spectrum (3.5 MHz), but I'm happy to be corrected on that!
The traces inside the Spectrum itself will not be length corrected, and there are multiple Spectrums with different trace lengths (would need a different design for each Specy board). Luckily, the Spectrum runs at such a slow clock rate that it's not a requirement anyway.
You should add some more ground vias near where signals enter and exit the board, also near splits/borders of the groundplane. Connecting the ground plane in way that DC can flow is not the same thing as ensuring high frequency signal integrity. It will also improve signal integrity to add some ground-carrying pins in between your signal pins in the connector, high frequency signals always need a low impedance return path, otherwise you'll be severely limited in bandwidth. A 400 MHz squarewave has harmonics well into the Gigahertz range, you'll need to improve the grounding to be able make use of the highest sample rates this board offers. I highly recommend this video on the effect of ground plane stitching: ua-cam.com/video/nPx2iqmVAHY/v-deo.html
Are you referring to the design of the logic analyser PCB? Or the interface PCB? If you have insights into the LA PCB design then I'm sure the designer would be interested
RP2350 itself ought to happily run its PLLs from 10MHz input reference... pico boards are hard-wired to a crystal though, and the other clock inputs cannot drive the PLLs, only the clock mux itself. I believe the result is this is trivial with a custom board, and impossible for an unmodified pico. Addendum: if you're sampling ~10x or higher above the external clock, you're getting all the relevant edges, if by 128x or more you have 7 whole bits of phase information about the rising and falling edge of every bit. You can sample an external clock using your own free-running clock, and reference signals to it in software if your input clock is under ~8MHz itself.
Great project, might put this together myself. Definitely agree about the excitement of designing and sending of for PCB's, even if making errors are extremely common place, it's just so easy to overlook stuff. Thank you for the tip about printing off design and checking against components, never would of thought of that.
It's somewhat disheartening to see that the venerable (and long out of production) OLS remains unchallenged even to this day. This LA has some very respectable speed and bit count stats but its inherent inability to do long captures with run length encoding (which enables the OLS to capture for seconds even at 200MSPS) leaves it much less usable than it could be. Try capturing some fast-ish serial-type message exchanges with some pauses between messages on a limited sample count and you'll see soon enough why you need RLE (or streaming capture). Also, the software has an absolutely atrocious case of "not invented here" attitude.
"long out of production" True, but it's fully open source so it's technically not unobtainable. Parts are still available but it wouldn't take much to port it to a newer FPGA and microcontroller while keeping compatibility if wanted..
Here's why your sampling frequency should at least double the frequency of the system you are watching: en.m.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
Thanks! The issue is if you go too fast the sigrok decoders flood with errors because it relies on detecting synchronous changes in control signals, if they are apparently off by a few nano seconds it will flag an error, for slow things like this 3.5 MHz clocked Z80, that can trip you up
Software is available for Windows, OSX and Linux. Be sure to support creators with these kinds of projects. Thanks for watching! ❤
Too bad, no support for macOS.
Wow, Dr. Gusman has made a lot of progress on this since I checked it out a year ago running on my own pico. The software didn't quite have the features I was in need of back then, so I shelved my project. It seems like the updates are enough for me to resume progress on the project, so I'll dust it off in a few weekends. Thanks for demonstrating the recent updates!
It's cool PCB way works with small channels like yourself. I've never used them yet but it's such a cool service for makers.
Yes I appreciate their support
Very nice video and I'm really impressed with the developments of the software, great to be able to use SigRok decoders as that was the main reason I would export and use SigRok, cool to be able to stay in the picoLA software only. Glad I sent that original PCBs to you now 😂!
Thanks for that! 👍🏻👍🏻🙏🏻
This looks great. I'll definitely be building a few soon.
I designed an FPGA-based Logic Analyzer years ago, but never had it made.
That used a Cyclone IV (I think?), and FT601Q USB 3.0 chip.
That had 64 channels, but could only manage up to about 33 MHz sample rate, unless something like RLE compression is used.
But then I saw the CoLA project on sikrok, which is almost exactly what I wanted, but has 96 channels.
(I'm a bit hazy on the info below, so there may be some mistakes)...
The problem is, CoLA has some quite serious issues with the standard version of Pulseview, because of some FTDI DLLs which aren't open source, or something.
You can compile a version of Pulseview with the FTDI binaries included, but I never did manage to get it compiled. lol
CoLA also uses a six-layer board, and an oversized Cyclone V, so would be quite expensive to have made.
The thing is, those LAs should be capable of streaming directly via USB 3.0 at high speeds, so you can do VERY long captures, directly into RAM on the PC.
I'm wondering if there's any way the Pico project could do something similar?
AFAIK, the Pico and Pico 2 USB only works up to 12 MBits, though, so that could be a problem for doing long captures to the PC.
I just read some of the README on github. I saw the issue with the Pico 2, which seems quite bad.
One of the things I really need a fast LA for, is to help reverse-engineer a modern DLP chip (DMD).
I made some progress with that before, by hooking up a projector's LVDS signals to an FPGA dev board.
(The intention there, was to build my own three-chip DLP projector, basically.)
But I could never *quite* get pixels loaded onto the DMD using my own Verilog. :(
It could be very interesting to try the Pico LA with an extension board that has LVDS receivers on it.
Even if it can only capture for a relatively small amount of time, multiple captures could probably be joined together.
There might even be a way of doing a kind of double-buffering thing, using two or more Pico LA modules.
So one Pico is sending the data to the PC, whilst the opposite Pico is capturing more samples, and so-on.
btw, I think a really neat addition to the sigrok decoders would be...
To have it actually display what is getting written to the video output on the Speccy. lol
Assuming enough samples could be captured at once, the software could reconstruct what is being displayed by the Speccy.
And / or, a way to display a hex view of any writes to Speccy DRAM, so a kind of mirror of everything that should be in DRAM.
ie. Rather than having to capture the DRAM writes after reset, the Pico just uses a small chunk of memory as a "mirror" of whatever the Z80 is writing to Speccy DRAM. That way, you can keep doing multiple captures on the LA, to update the hex display of DRAM on the PC side.
I did a project on FPGA a while back which does something similar...
The FPGA itself generates VGA output with Hex values displayed, for a small chunk of memory.
You hook some the FPGA GPIO pins to the device-under-test, which in my case was a Roland D-20 synth board.
That allowed me to view a "mirror" of memory, and showed in realtime whatever the CPU was writing to memory and/or mem-mapped registers.
That can be a VERY powerful way to help diagnose faulty systems, or reverse-engineer the register map.
I used that to help figure out the registers in the LA32 synth chip.
I could hit a few keys on a MIDI keyboard, or tweak some CC values, and instantly see the register values update on-screen. It would have taken me about ten times longer to figure anything out from LA captures otherwise.
Oh, even better...
I forgot the Pico can be used to output RGB/VGA or even HDMI directly. ;)
I know there are projects like RGB2HDMI which use a Pico to output higher-quality video from retro systems.
Something like that could be added to the Pico LA software, just not necessarily updated in realtime.
Sorry, I know that's a lot to read, but this project just happens to coincide with a lot of what I've wanted for a while.
Those FEFE and FDFE and so on are just IO operations. Check the /IORQ signal on the bus to see it better.
Sinclair changes the higher byte of the IN A,(C) - which is in fact IN A, (BC) as the B register (higher part of the BC register) is put on the address bus during IO operations. It is a side effect, but widely used in the Z80 world.
Data on the data bus are, what the IO port reads.
Refresh is done at the last cycle of the Machine cycle and puts register pair IR on the address bus as well, as it activates /RFSH signal. Register R is only 7bit.
To expand on keyboard reading. Sinclair reads the state in eight subsequent steps. Each for one keyboard "row". Keyboard has 40 keys organized into 8 "rows" of five keys. rows are connected to the A15-A8 address lines with diodes and the five keys in a "row" are connected to the ULA, where they make the lower five bits D0-D4 if the input port FE (which is also a simplification as it requires just A0 == 0 and IORQ == 0 to activate). D6 is the "Ear in" tape reading input bit.
So the reading routine sets one row low, which makes possible to read zero in a bit corresponding to a pressed key in the selected row. The same it goes with all eight rows.
The project states a serious problem with the Pico 2 that may impact the usefulness when using a Pico 2. The issues have been mainly addressed, but YMMV.
I was hoping this early release finally fixed those problems. I’ve been following those developments closely too.
Such an awesome project!!
It's good to here that. I'm now making an Oscilloscope base on Pi Pico. It worked! I can get 125Msps sampling rate. Thanks for your video!
Can we see it? Could you join the discord and share?
Simply amazing! Thanks for sharing
This is really amazing! Awesome and great ingenuity!
Thank you for the informative video. I love these more advanced tool videos.
Really good device, thank you for sharing.
Thanks for the video, I'll definitely try this software with my pico ! About the PCB design, I advise you to loose the instinct of wanting to nicely bundle up signals close to each other and route them around the periphery of the board ;) it's probably bad for EMI and could cause some false pulses on your lines. I know it's tempting to "cable manage" them nicely in a corner but it's a common mistake I have made lots of time 😅
Thanks, I was constantly thinking this while making everything look neat. It's the beginning of a long learning journey
A cheap usb oscilloscope with pico would be nice. I'm aware there's a current one, but it relies on some paid for android app, and an android.
There's another comment in here where somebody has made one!
V2 is much more practical than the original two board solution but 24 channels is not really sufficient even for an 8 bit micro. 32 channels is the realistic minimum for this kind of work and so requires two complete units. Sampling should generally be done at a minimum of 5x the frequency of the signals being measured so 20MHz should be fine for a Spectrum without wasting samples. I am sure that you should be able to find an appropriate header template for the Spectrum user port in the Kicad libraries. Using this world simplify design and prevent problems with components not fitting. The more you get into PCB design the more fun it is! 😁👍
Great video. Very interesting content 👌👀
Z80 use the address and data bus in two modes - memory access and input/output.
Since the code is about reading the keyboard its likely the port address and I/O data you see.
Be curious.
Feel free to ask or reach out to me.
Great answer, thanks!
@@HappyLittleDiodes I like your channel and it's great if I could contribute. However, check the facts, as always. :)
@LarsHHoog I stay modest and always make it known when I don't know the answer. Thanks for providing the facts
You could use a 40pin chip clip, you’d wire it for the z80 and clip it over, quick way to get access to the voltages, clock, address, data and irq lines.
That's a good option, but it's super nice to be able to do this without opening the machine
@ thanks for the video - I’ve liked and subscribed. I built a very rudimentary one in the 90s, using SRAM, ttl 74F octal buffers leds and counters.
If you place the logic analyser connectors on the reverse side of the Spectrum interface board then the board doesn’t need to be larger for toast rack style machines.
That's true for one analyser, for two though it's more difficult to package, you'd need a double height ( or more) socket for the 2nd analyser and I'd be worried the weight imbalance could cause issues with the connection to the edge connector
@ I’m not sure weight would be an issue (some of the old spectrum expansion boards were a bit hefty). You could place the connectors on the back so that one analyser is vertical and the other is horizontal. Place a support under the horizontal board if you are worried.
Very nice project, way better than the cheap Saleae clone I've bought probably a decade ago.
It was amazing!
Thats just amazing
This might be common knowledge, but is there a similar adc version of the software?
Great Work!!! Do you have any idea about the release of this new design?!? I can't wait to build my copy!!!! ZX spectrum was my first computer when I was 6 years old! Rediscovering it with your videos is such a joy!!! Thank you so much!
Thanks! Keep an eye on the GitHub is all I can say. Feel free to join the discord where we chat about it often
Interesting idea. It's still not clear to me how exotic the triggering is; probably nothing like a conventional analyzer. Thankfully I rarely ever need to fire-up my scope or logic analyzer (HP16500A) for debugging, as I embed a lot of diagnostics in my RasPi code as well as add hardware debug aids in projects that have an FPGA.
I see the PCB for Ver 6 sneds you else where and eventually to a dead link ... Is there going to be a prebuilt version of this now from Mr GusMann?
Keep an eye on the GitHub. I'm not sure what the story is with building this yourself, but I do know that people were downloading the V6 data while it was still in the works and potentially not ready, so maybe it's just temporarily down until a design is finalised
Hope it becomes available one way or another!
@101blog I'm certain it will
A competitor to @Saleae perhaps
Pico (Pico H) newbie here. So are anti-ESD wristbands overkill when working with boards?
Always a good idea. I get lazy and set a bad example especially with new and cheap electronics. If you're somewhere cold and dry, you'll see sparks from static shocks. I work in Lapland once per year and believe me you could damage a board in those conditions
Totally confused by the post about pico2 is dead and not supported. Also is the analyzer only for the hardware and how to get it, … somehow if pico2 issue is solved ?
I believe the designer found a way around the pico 2 issue, however, the only benefit of Pico 2 for this project, at the moment, is more samples
very nice that should help fixing my spectrum's, also did you mention your an auto electrician i have a Mitsubishi gto that wont start are you close to manchester
I am close to Manchester but I'm not so much an electrician as a development and test engineer
There's no sponsor link in the github project, could you ask him to enable it, or maybe suggest the creator of the project to run a patreon? I mean I could raise an issue in the gh repo, but I think a closer contact would be better here.
It'll help everyone who wants to help with the project.
And wow this project it's really incredible
I'll let them know!
How does this compare to the much more expensive Saleae Logic Pro 16?
Sadly I don't have one, but I'm sure the Saleae is very capable and robust, for professional applications it's probably a good choice
Coud you run that in Rasbry pi 5 instead of pico?
I'm not sure!
Is the software sigrok itself or a cousin ?
The software imports the sigrok protocols, it's been put together by the project creator themself
You should update the video title to specify 128 channels because 24 channels is nothing particularly special. But 128 that's very unique special!
I included it in the thumbnail, I felt that if I waved this single device around saying it can do 120 channels it's not totally accurate, since you need 5 of them to achieve that
Is there no trace length correction needed on your own pcb?
I don't think it's important for the relatively low frequencies we're dealing with on the ZX Spectrum (3.5 MHz), but I'm happy to be corrected on that!
The traces inside the Spectrum itself will not be length corrected, and there are multiple Spectrums with different trace lengths (would need a different design for each Specy board). Luckily, the Spectrum runs at such a slow clock rate that it's not a requirement anyway.
@@HappyLittleDiodes You are right. I didn't think of the low frequency of the spectrum. 🙃
You should add some more ground vias near where signals enter and exit the board, also near splits/borders of the groundplane. Connecting the ground plane in way that DC can flow is not the same thing as ensuring high frequency signal integrity. It will also improve signal integrity to add some ground-carrying pins in between your signal pins in the connector, high frequency signals always need a low impedance return path, otherwise you'll be severely limited in bandwidth. A 400 MHz squarewave has harmonics well into the Gigahertz range, you'll need to improve the grounding to be able make use of the highest sample rates this board offers.
I highly recommend this video on the effect of ground plane stitching: ua-cam.com/video/nPx2iqmVAHY/v-deo.html
Are you referring to the design of the logic analyser PCB? Or the interface PCB? If you have insights into the LA PCB design then I'm sure the designer would be interested
@@HappyLittleDiodes I'm referring to your interface PCB design, shown at the end of your video. I haven't looked at the LA layout yet.
@vatterger thanks! I'll take a look at the video, thanks for the tips
Does it accept external clock signal?
I don't think so at the moment but I believe it's being discussed
RP2350 itself ought to happily run its PLLs from 10MHz input reference... pico boards are hard-wired to a crystal though, and the other clock inputs cannot drive the PLLs, only the clock mux itself. I believe the result is this is trivial with a custom board, and impossible for an unmodified pico.
Addendum: if you're sampling ~10x or higher above the external clock, you're getting all the relevant edges, if by 128x or more you have 7 whole bits of phase information about the rising and falling edge of every bit. You can sample an external clock using your own free-running clock, and reference signals to it in software if your input clock is under ~8MHz itself.
👍👍
Great project, might put this together myself. Definitely agree about the excitement of designing and sending of for PCB's, even if making errors are extremely common place, it's just so easy to overlook stuff. Thank you for the tip about printing off design and checking against components, never would of thought of that.
Valeu!
Thank you! 🙏🏻
It's somewhat disheartening to see that the venerable (and long out of production) OLS remains unchallenged even to this day. This LA has some very respectable speed and bit count stats but its inherent inability to do long captures with run length encoding (which enables the OLS to capture for seconds even at 200MSPS) leaves it much less usable than it could be. Try capturing some fast-ish serial-type message exchanges with some pauses between messages on a limited sample count and you'll see soon enough why you need RLE (or streaming capture). Also, the software has an absolutely atrocious case of "not invented here" attitude.
"long out of production" True, but it's fully open source so it's technically not unobtainable. Parts are still available but it wouldn't take much to port it to a newer FPGA and microcontroller while keeping compatibility if wanted..
🎈
🌈
Windows... I'm out.
Check the github, software is released for windows, osx and linux with each release
Bye
Here's why your sampling frequency should at least double the frequency of the system you are watching: en.m.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
Thanks! The issue is if you go too fast the sigrok decoders flood with errors because it relies on detecting synchronous changes in control signals, if they are apparently off by a few nano seconds it will flag an error, for slow things like this 3.5 MHz clocked Z80, that can trip you up