Elminster wrote: ↑
Tue Jun 05, 2018 10:04 am
I was a bit late to the party on this one. With regards to the work on the decoder for sigrok. I might have missed it but I am not sure I can see anything as to why it was not fast enough in Python. What I mean is if the Z80 cpu could be decoded why was the 6502 so much of an issue. Or was it jsut that the Z80 owners are putting up with minutes of computer time to decode seconds of trace? Or maybe you implemented more that is in the Z80 module. I havent finsihed building my Z80 RC2014 yet so not tried it on a Z80.
I don't think decoding the 6502 is any more expensive than decoding the Z80.
I had a number of reasons for moving away from Sigrok as an environment for examining traces.
1. For short traces (say less than 1s of capture) performance was OK. It would take maybe 20-30 seconds for pulseview to process the trace. But I found I was wanting to work with longer captures. For example, I wanted to use the Dormann tests to validate the 6502 decoder. These take about a minute on the Beeb, and processing this was causing pulseview to run out of memory.
2. If you are using asynchronous capture (12 MHz), rather than synchronous capture (using the Beeb's 2MHz Phi2 as a capture clock), the volume of data goes up 6 fold, making the performance / memory issues worse.
3. I didn't find the pulseview's signal/bus traces view of the world a very natural environment for working with large numbers of instructions. So I found myself using the decoder from sigrok-cli and generating a text file. But the formatting options are very limited.
4. As an experiment, I did a quick port of the python code to C, and felt the result was much better:
- it was literally 100x faster
- it's memory usage was essentially constant, so could handle very long captures (and even continuous streaming)
- it's very easy to add multiple command line options
- there are no formatting constraints
- large text files are much easier to work with. I can load a 700MB capture file into emacs and searching works fine
- for larger files, grep is very effective at extracting the areas of interest
5. I'm a much more competent C programmer than I am a Python programmer
6. I wanted to add some quite complex features, and doing this in Python would have challenged me!
Since switching to C, the following features have been added:
- Support for different 6502 variants (NMOS 6502, WD 65C02, Rockwell 65C02)
- Making all the control signals optional (RnW, Sync, Rdy, Reset, etc)
- Emulation of the 6502 state, so the full register state can be displayed
- Emulation of the memory system
- Capture triggers (when to start, when to stop, whether to ignore interrupts)
- Code profiling options (instruction, block and call based)
- Automated test suite
- Beeb specific Floating Point Accumulator decoding
- Beeb specific Tube Protocol decoding
All of this would have been much harder in Python, because I less familiar with it, and because for each feature there would have been a trade-off with performance.
7. It's still possible to use sigrok-cli to create the capture files, so this will still work with any supported logic analyzer.
The only downside is that I desperately need to improve the documentation now, as with all the features and options it can be quite confusing. So that's what will be coming next....