Open Source Logic Analyzer Experiments

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Wed Feb 07, 2018 10:17 pm

OK... I have cygwin CLI capturing data and the 6502 decoder working :D

Great work Hoglet =D> =D>

I followed the windows setup earlier in this thread.
Most helpful... Thankyou

I think I found one snag in the env path :
C:\Program Files (x86)sigrok\sigrok-cli
Missing \

I'm posting the data.bin file:
data.zip
(779.65 KiB) Downloaded 12 times
It reported 4 fails, but looks correct.

Pulse view is capturing data but theres no native 6502 decoder...
I guess thats my next job.

Marcus

Coeus
Posts: 775
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by Coeus » Wed Feb 07, 2018 10:21 pm

marcusjambler wrote:Pulse view is capturing data but theres no native 6502 decoder...
I guess thats my next job.
I thought hoglet's 6502 decoder started as a plugin and migrated to stand-alone. Could it migrate back again?

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Thu Feb 08, 2018 12:01 am

Coeus wrote: I thought hoglet's 6502 decoder started as a plugin and migrated to stand-alone. Could it migrate back again?
Possibly, but I wouldn't want to do that, for several reasons:
- The C version is at least 100x faster than the python version.
- PulseView tries to hold everything in RAM, which rapidly blows up for large traces.
- Looking at long traces in PulseView as a single long horizonal line is an awful user experience.

I think a text file is a much better output format, unless you are only capturing a few instructions.

Dave

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Thu Feb 08, 2018 12:01 am

marcusjambler wrote: I think I found one snag in the env path :
C:\Program Files (x86)sigrok\sigrok-cli
Missing \
Fixed now, thanks.

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Thu Feb 08, 2018 12:05 am

marcusjambler wrote: I'm posting the data.bin file:
data.zip
It reported 4 fails, but looks correct.
I think the fails are symptomatic of bus contention that occurs in the Beeb when you try to write to a ROM, i.e. both the ROM and the 6502 drive the data bus at the same time.

It's happening in ROM slots F, D, C and 0.

What ROMs do you have installed?

Dave

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Thu Feb 08, 2018 5:24 pm

I've got OS, BASIC, 32k SW RAM module with VideoNULA riding on top, EEPROM module ( empty at the minute ) & DFS

Not sure why some of them repeat.

Screen and board shots :
IMG_2353.JPG
IMG_2356.JPG
IMG_2351.JPG

Coeus
Posts: 775
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by Coeus » Fri Feb 09, 2018 2:22 pm

marcusjambler wrote:Not sure why some of them repeat.
On an unexpanded model B the ROMS select line is not fully decoded so the ROM that appears in slot 15, usually basic, also appears in slots 11, 7 and slot 3. Likewise the ROM in slot 14 also appears at 10, 6, and 2. etc.

The OS is wise to this partial decoding and eliminates the duplicates when building its own table of ROMS to offer service calls to hence when you do *HELP each ROM responds only once.

There are a number of ROM listing tools including the various versions of the *ROMS command in the sideways RAM utils built into some DFSs as well as some independent ROMs and you look like you may be using a BASIC program that serves the same purpose. Each of these can work differently. Some use the OS table to to decide which ROMs to look at more closely, and thus avoid reporting duplicates, others deliberately choose to look at every slot every time in order, for example, to report on something loaded into sideways RAM but not built into the OS table yet.

HTH,
Steve.

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Mon Feb 12, 2018 10:41 pm

Thanks Steve

Heres a bin file from a part dead beeb
data.zip
(709.97 KiB) Downloaded 14 times

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Mon Feb 12, 2018 11:04 pm

That's a particularly weird failure.

It seems the memory clear code never terminates. Here's that code:

Code: Select all

D9E7  A2 04              ..      LDX #&04
D9E9  86 01              ..      STX &01
D9EB  85 00              ..      STA &00
D9ED  A8                 .       TAY
D9EE  91 00              ..      STA (&00),Y
D9F0  C5 01              ..      CMP &01
D9F2  F0 09              ..      BEQ &D9FD
D9F4  C8                 .       INY
D9F5  D0 F7              ..      BNE &D9EE
D9F7  C8                 .       INY
D9F8  E8                 .       INX
D9F9  E6 01              ..      INC &01
D9FB  10 F1              ..      BPL &D9EE
Lets look at some of the bus cycles when this runs....

Here is zero page location 01 being initialized right at the start:

Code: Select all

0 a2 1 1
1 04 1 1
D9E7 : A2 04    : LDX #04        : A=00 X=04 Y=?? SP=FE N=0 V=? D=0 I=1 Z=0 C=1
0 86 1 1
1 01 1 1
2 04 0 1
D9E9 : 86 01    : STX 01         : A=00 X=04 Y=?? SP=FE N=0 V=? D=0 I=1 Z=0 C=1
Here is the first time INC 01 is executed:

Code: Select all

0 e6 1 1
1 01 1 1
2 04 1 1
3 04 0 1
4 05 0 1
D9F9 : E6 01    : INC 01         : A=00 X=05 Y=01 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
The value of 04 read in cycle 2 is incremented to 05 and written back in cycle 4. So far so good...

Here is the second time INC 01 is executed:

Code: Select all

0 e6 1 1
1 01 1 1
2 04 1 1
3 04 0 1
4 05 0 1
D9F9 : E6 01    : INC 01         : A=00 X=06 Y=01 SP=FE N=0 V=? D=0 I=1 Z=0 C=0
This is wrong, because the value read in cycle 02 is still 04, and it should be 05.

So somehow the write at the end of the first INC 01 is either ignored, or it is affecting the wrong address.

As to why, I have no idea, but maybe someone else does?

Dave

Coeus
Posts: 775
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by Coeus » Mon Feb 12, 2018 11:13 pm

hoglet wrote:So somehow the write at the end of the first INC 01 is either ignored, or it is affecting the wrong address.
I have a suspicion this read-bank of 01 to increment it to the next value maybe the first read from RAM in the initialisation sequence so maybe writes are being ignored to all addresses, not just this one.

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Tue Feb 13, 2018 12:09 am

It is a 'suspected' RAM Beeb.
With Trickys ROM in I get a garbled mode 7 Frogger screen and the RAM test writes give some fixed bits.
I'll take some photos sometime in the next few days.

Marcus

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Sun Feb 18, 2018 11:21 am

These are screen shots of Trickys ROM running in this poorly Beeb
IMG_2898.JPG
IMG_2897.JPG
IMG_2893.JPG
IMG_2891.JPG
IMG_2886.JPG
IMG_2887.JPG
IMG_2889.JPG

User avatar
tricky
Posts: 2441
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by tricky » Sun Feb 18, 2018 12:08 pm

Looks like b7 is incorrectly set when a0 is 0 in the lower banks and one of the bits is stuck on in the high banks.
You can run the test in an emulator to see what it should look like.

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Mon Feb 19, 2018 12:26 pm

Thanks Tricky
Looks like b7 is incorrectly set when a0 is 0 in the lower banks and one of the bits is stuck on in the high banks.
Is there an explanation as to what I'm looking at in terms of which chips could be at fault.
On the schematic IC60 or IC68 RAM deal with bit 7 but it could also be the decoding or latching logic.

I could really use some help with figuring this out. [-o<

This particular beeb is my original one from the 80's... Its been poorly for 25 years!!

User avatar
tricky
Posts: 2441
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by tricky » Tue Feb 20, 2018 9:14 am

I think you need a logic analyser or scope from here, but you might get away with piggybacking new chipson top of the old ones one at a time until things improve. Depending on how the faulty chip has failed, this might work, but I'm not sure what the worst case is.

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Sun Feb 25, 2018 12:25 pm

RAM ICs and sockets on order.
I'll start with replacing IC60 and if that cures the lower 16k with S25 south.
I should then be in a position to invert the s25 feed and find the issue with the upper 16k

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Tue Feb 27, 2018 2:52 pm

tricky wrote:Looks like b7 is incorrectly set when a0 is 0 in the lower banks.
I replaced IC60 and the fault is still present.
I wonder... do the bits run 01234567 or 76543210 ?

User avatar
vanekp
Posts: 539
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: Open Source Logic Analyzer Experiments

Post by vanekp » Tue Feb 27, 2018 5:22 pm

Have a look at my post here viewtopic.php?f=3&t=12920&hilit=memory&p=166721#p166721
On locating memory faults and which chip is which bit.
Peter.

User avatar
marcusjambler
Posts: 335
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Open Source Logic Analyzer Experiments

Post by marcusjambler » Wed Feb 28, 2018 8:32 am

Thanks Peter

My Beeb from my childhood is back in the land of the 'Booo Bip' =D>

It was bit 0 Upper (IC53) and bit 6 lower (IC67)

Another win for Tricky's ROM =D>

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Wed Feb 28, 2018 9:12 am

Does Tricky's Test ROM include any kind of a RAM Test?

If so, it might be worth capturing a logic analyzer trace from that running.

Dave

User avatar
tricky
Posts: 2441
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Open Source Logic Analyzer Experiments

Post by tricky » Wed Feb 28, 2018 12:50 pm

It only writes to ram iirc :oops:
It does push and pop, but only to use the SP as another register (or maybe I didn't add that).
I remember posting the source and it would be easy to add some reads or Inc/Dec/bit to give the analyser something to check against.

User avatar
vanekp
Posts: 539
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: Open Source Logic Analyzer Experiments

Post by vanekp » Wed Feb 28, 2018 3:47 pm

Well done =D> =D> =D> Yay glad we got another BBC back to the land of living =D> =D> =D>
Peter

User avatar
Elminster
Posts: 2016
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Open Source Logic Analyzer Experiments

Post by Elminster » 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.

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Tue Jun 05, 2018 11:14 am

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....

Dave

User avatar
Elminster
Posts: 2016
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Open Source Logic Analyzer Experiments

Post by Elminster » Tue Jun 05, 2018 11:39 am

Thanks for the full reply.

It is a shame while I prefer DSView to Sigrok it would have been nice to have a GUI that could do on the fly decoding with all the features you have added, but I guess hat is expecting a lot from a scripting language, is it clearly not go to be as fast as C (or some other compiled language). I am still playing with Python, more of a shell script person, but I have written some beautiful complex shell scripts before that took hours to run, re-written in C takes minutes.

User avatar
myelin
Posts: 410
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

Re: Open Source Logic Analyzer Experiments

Post by myelin » Tue Jun 05, 2018 12:59 pm

A project suggestion for anyone looking for one: embed 6502Decoder into b-em so you can capture machine state from a real machine and resume in the emulator (or use an attached machine as a monitor).

Update: I've started on this, except with Elkulator, because I'm hoping to show off my heavily modified Elk (with FPGA in the CPU socket, and three cartridges: fx2/Pi adapter, hacky SD card/serial port, and flash) at VCF West (Mountain View, CA, Aug 5-6), and it would really highlight its general hacked-up nature to have it outputting video to an emulator on a laptop via the FX2 :)

The plan is to modify Elkulator to make exec6502() read from the 6502Decoder log (which will gain a new format that outputs bus cycles: RnW, A, D, and the register values) rather than emulate the 6502. It'll also watch for EVENTV calls with A=4 (VSYNC) and reset the video logic appropriately, which will hopefully be good enough for games to work. With any luck this should let me stream samples from fx2pipe into 6502Decoder and then into Elkulator, for a nearly-realtime display on a laptop.
SW/EE from New Zealand, now in San Francisco, making BBC/Electron hardware projects for fun.
Most popular: fast serial port, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

z80micro
Posts: 1
Joined: Mon Jun 11, 2018 10:10 am
Location: W Midlands
Contact:

Re: Open Source Logic Analyzer Experiments

Post by z80micro » Mon Jun 11, 2018 10:59 am

Dave

Have read your posts on MOS6502 disassembler protocol decoder for the 6502 on the sigrok LA with great interest.

I am looking to disassemble the Serial ROM on Tektronix 122x LA, this uses several 6502 CPUs.

I am using sigrok PulseView on 64 bit Windows 10 and have copied your python 6502 files into a new directory mos6502 under C:\Program Files (x86)\sigrok\PulseView\share\decoders but when I run Pulseview it does not pick up your analyser. I have also tried copying it to C:\Program Files (x86)\sigrok\sigrok-cli\share\decoders but it still does not appear to pick up your new decoder. When I read the sigrok documentation it suggested that I only needed to copy the new .py files over, but clearly I have missed something. Please advise what I am missing?

I appreciate that most of your posting is for a LINUX version of sigrok. Will this work on Debian on the Raspberry Pi B mk3?

Thanks

Peter

User avatar
hoglet
Posts: 7114
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Open Source Logic Analyzer Experiments

Post by hoglet » Mon Jun 11, 2018 2:09 pm

z80micro wrote:
Mon Jun 11, 2018 10:59 am
I am using sigrok PulseView on 64 bit Windows 10 and have copied your python 6502 files into a new directory mos6502 under C:\Program Files (x86)\sigrok\PulseView\share\decoders but when I run Pulseview it does not pick up your analyser. I have also tried copying it to C:\Program Files (x86)\sigrok\sigrok-cli\share\decoders but it still does not appear to pick up your new decoder. When I read the sigrok documentation it suggested that I only needed to copy the new .py files over, but clearly I have missed something. Please advise what I am missing?
A couple of suggestions.

1. Have you checked carefully for any error message from Pulseview?

2. Try setting the SIGROKDECODE_DIR environment variable to where you have installed the decoder. This is mentioned in the Protocol Decoder HOW TO
z80micro wrote:
Mon Jun 11, 2018 10:59 am
I appreciate that most of your posting is for a LINUX version of sigrok. Will this work on Debian on the Raspberry Pi B mk3?
As I mentioned in the 6502.org thread, I'm no longer maintaining the sigrok protocol decoder, as the standalone C version is much better. Were you not able to successfully compile this?

Dave

Post Reply