HP Logic Analyzer Inverse Assemblers

[Hamster]

most if all the information is in this thread, however, some processors require pre-processors to work ( z80, etc ) , you can't just hook up the LA and then use the IA(s).

all the documentation for how to compile the IA for new version Systems have been posted.

i dont think i have ever seen anything that shows cpu to cpu layout.

[go4retro]

most if all the information is in this thread, however, some processors require pre-processors to work ( z80, etc ) , you can't just hook up the LA and then use the IA(s).

all the documentation for how to compile the IA for new version Systems have been posted.

i dont think i have ever seen anything that shows cpu to cpu layout.

My goal was to design some adapters that didn't fall into the trap of one of the links earlier in the thread:

https://pcbjunkie.net/index.php/logic-analyzer-adapters/

Obviously, his adapter for the Z80 lacks all the buffering, but even his 6502 adapter (which would not have needed any pre-processing, according to the current thread) uses the wrong pin mappings.

And, by looking at a few mappings in a single place, I might be able to deduce how best to create a mapping for a CPU not already supported (the TI ones in the cc-40/74/95 come to mind)

Jim

[deanclaxton]

Gerbers attached for the 65C02 adapter, but I havent built/tested this yet. I'll update this post once I know its working ok - I'll slip in a few of these boards with my next order. This can be used with Phils inverse assembler (I'll have to get that running on the 16902).

The order of the STAT signals is correct for his inverse assembler. I designed and built a similar adapter for the 40 pin probes with all the termination parts on the adapter. This will be much faster to assemble!

I don't think I ever updated this thread after building my 65C02 adapter, but it works great. I'll try dig out a photo.

EDIT: cant find a good photo of it in use - the images are normally focused on what I'm testing and not the adapter, but here is a photo I took some time after building it.

[Hamster]

I like it! Thoughts on releasing the plans?

[gslick]

Good use of the Samtec connector. Makes it easier to put the newer style 90-pin logic analyzer modules to work that can be a pain to use for most things otherwise.

You might be able to sell a few of those if you built some up.

[deanclaxton]

I like it! Thoughts on releasing the plans?

I posted gerbers and schematic a while back in this same thread. It was just the other day however that I realised I'd never posted an update since I built it.

EDIT : It was quite a while ago actually, but this is where I posted the gerbers : https://www.eevblog.com/forum/testgear/hp-logic-analyzer-inverse-assemblers/msg4690589/#msg4690589

Schematic attached.

[dorkshoei]

Couple questions:

1. Has anyone worked on an IA for the Hitachi 64180?   It's a derivative of the Z80 so I assume it would require similar active logic as the z80 preprocessor.     There was a 64180 option for the 64000 but I don't think that implies anything about the IA side.

2. What is a good price to pay (US) for a 10269C?  I believe I require it to use any of the HP pre-processors with a 16702B (assuming I ever find any of the pre-processors I want for a reasonable price  ).   

[Hamster]

not every ia needs the 10269c

i am not aware of a IA file for the 64180

However, since the 64180 is just a Z80 w/MMU and on chip perf, you could probably just use the z80 ia and just make an adapter, the trick will be handling the mmu and any memory banking as the z80 would be handling that access internally?

[MarkL]

Couple questions:

1. Has anyone worked on an IA for the Hitachi 64180?   It's a derivative of the Z80 so I assume it would require similar active logic as the z80 preprocessor.     There was a 64180 option for the 64000 but I don't think that implies anything about the IA side.

2. What is a good price to pay (US) for a 10269C?  I believe I require it to use any of the HP pre-processors with a 16702B (assuming I ever find any of the pre-processors I want for a reasonable price  ).

A cursory comparison of the HD64180 bus cycles compared to the Z80 says there's little difference.  The previous page in this thread discussed using passive general purpose probing to get the Z80 IA to work (i.e., no preprocessor), so I think it should not be a problem on the HD64180.

Granted, there's a little more to the HD64180 with its MMU, the refresh is not exactly the same, and there are a few additional instructions.  However, you could start with the Z80 IA source that's been already been adapted for passive probing, and add what you need.

https://www.eevblog.com/forum/testgear/hp-logic-analyzer-inverse-assemblers/msg5398076/#msg5398076

[davidshoe]

How does one know if you have to have the preprocessor or not?  I have a 1692 and want to probe a 68000 in PLCC68 form factor (soldered down).  I expect I am going to have to use flying leads as finding the E2447AA/AB probe is going to require a miracle. Reading through the thread it seemed to be I could use the IAL68000_p files to support this flying lead option.

I am running the 5.9 version application on windows 10 64 bit.  Then connect to my 1692 over firewire.  Gives a nice responsive UX.

I installed the IAL68000_p add-in using the IAL68000_P-amd64\install.bat, had to fix it up a bit as it has a bug:

if not exist "C:\Program Files (x86)\Agilent Technologies\Logic Analyzer\AddIns\nul" mkdir "C:\Program Files\Agilent Technologies\Logic Analyzer\AddIns"
if not exist "C:\Program Files (x86)\Agilent Technologies\Logic Analyzer\AddIns\Hewlett-Packard\nul" mkdir "C:\Program Files\Agilent Technologies\Logic Analyzer\AddIns\Hewlett-

Looks for the (x86) paths to exist then creates the non x86 folders.  Fixing that to create the folders in (x86) and I was able to install the add in.

Now I can load the app, I created my bus/signal settings, then created a new tool which let me pick the 6800 IA for gp probes, I went through the dialogs and connected the signals to my bus config.

Now I just need to attach all the fly wires and do a capture.

Does this sound like I am on the right path?  Or am I missing some steps?

[Hamster]

This is just testing if the directory exists, and if doesn't add it.

if not exist "C:\Program Files (x86)\Agilent Technologies\Logic Analyzer\AddIns\nul" mkdir "C:\Program Files\Agilent Technologies\Logic Analyzer\AddIns"
if not exist "C:\Program Files (x86)\Agilent Technologies\Logic Analyzer\AddIns\Hewlett-Packard\nul" mkdir "C:\Program Files\Agilent Technologies\Logic Analyzer\AddIns\Hewlett-

You can just make sure the two directories exist and delete these two lines.

I manually followed the batch file and manually installed the IA ..

Yeah, the 1690 w/firewire is nice, I really wish Windows 11 support Legacy Firewire, the windows 11 nag is anoying.

[MarkL]

...
Does this sound like I am on the right path?  Or am I missing some steps?

I think you are on the right path.  The *_p version of the IA and config are for general purpose (e.g., flying lead) probing.

Where did you get your assignments config?  I would check the assignment to the SIZE field in STAT.  SIZE[0] is LDS, and SIZE[1] is UDS in all the examples I see: c68000_p.txt, the E2447 User Manual, and the 68010 IA source (68010.S).  Also, I'm not sure if the IA is expecting LDS to be input on ADDR[0], and if it also wants LDS to be in the SIZE field in STAT.

The 68010 IA source is available in the 10391B Development Package, so you can look there to determine behavior, or to modify anything that isn't quite working right.  (Reading IA source is a bit of a learning curve...)

When you get figured out, please post back with what works!

[davidshoe]

I got the configuration from the c68000_p.txt file that was in the invasm_v3.zip file from earlier in this thread.

Pod assignments (? = disabled)
-----------------------------

Label  0: ADDR     (24 bits):  A3: ******** ........  A2: ******** ******** 
Label  1: DATA     (16 bits):  A1: ******** ******** 
Label  2: STAT     ( 8 bits):  A3: ........ ******** 
Label  3: SIZE     ( 2 bits):  A3: ........ .....**. 
Label  4: VMA      ( 1 bits):  A3: ........ ....*... 
Label  5: FC     ? ( 3 bits):  A3: ........ .***.... 

[MarkL]

I got the configuration from the c68000_p.txt file that was in the invasm_v3.zip file from earlier in this thread.

Pod assignments (? = disabled)
-----------------------------

Label  0: ADDR     (24 bits):  A3: ******** ........  A2: ******** ******** 
Label  1: DATA     (16 bits):  A1: ******** ******** 
Label  2: STAT     ( 8 bits):  A3: ........ ******** 
Label  3: SIZE     ( 2 bits):  A3: ........ .....**. 
Label  4: VMA      ( 1 bits):  A3: ........ ....*... 
Label  5: FC     ? ( 3 bits):  A3: ........ .***.... 

And continuing on, the SIZE label is:

Label: SIZE 
       LOW BYTE          10
       HIGH BYTE         01
       WORD              00

Implying the two bits in SIZE are in the order /UDS:/LDS.

In your screen capture of the assignments, you appear to have LDS assigned to the upper bit of SIZE, and perhaps you were connecting it that way?  And similar for /UDS vs. A0.

I'm not saying you're wrong, since I'm not aware of any working examples of 68000 GP probing for comparison (yet), but rather just pointing out a couple of things that differ from the documentation if the IA isn't working right.

[davidshoe]

Was there a reason for using pods 1,2 & 4?  Vs just 1,2 & 3?

[davidshoe]

Ahhh, I understand what your saying now.  I just got them (UDS / LDS) backward

Haven't had a chance to actually connect the LA up and run this all yet. 

[MarkL]

Was there a reason for using pods 1,2 & 4?  Vs just 1,2 & 3?

The IA doesn't have any sensitivity to the specific pod being used, so any pod will do.  It just looks for the label names (ADDR, DATA, STAT).

Some models allow arbitrary assignment of bits in different orders and from different pods to the same label.  That will probably also work with the IA, but I would keep the label grouping and bit order as shown to keep it simple and not invite trouble.

[fenugrec]

Thanks to MarkL, gslick and others on their great work here, these past few years.

It's still a surprisingly fragile process - I must have hard-crashed my 1660C about 15 times before figuring out just the right sequence to load the IA; not even sure what 'fixed' it.

Question for someone familiar with the mc68k IA, or Nemesis1207 probably: would there be any hope of using the 68k IA without hooking the FC0-FC2 signals ? they are not routed on this board I'm working on, and it throws off analysis because the IA doesn't know which is an opcode fetch VS other types of reads. I assume the IA would have to be modified (and would imply certain limitations and assumptions) + recompiled but I'm not sure I want to get into that.

I tried modifying the Symbol Table to not take into account the FC and VMA bits but it's impossible to disambiguate reads and the IA cannot deal with that. Even if I force all reads to be 'OPCODE FETCH' it doesn't help.

[MarkL]

I don't think it's hopeless without FC[2:0], but it's probably not going to be easy to modify the IA code.  No chance of sneaking a few jumpers in there to clip onto?

I looked through the 68010 IA source for a little.  It's provided with the development kit and is reasonably well commented.  And there's also a detailed treatment of the 68010 and its quirks in the IA reference manual in Appendix B, along with lots of examples.

The 68010 IA appears to want to synchronize by looking for (STAT & 10111111B) == 10101001B, which is a 16-bit READ from memory while FC[2:0] is Supervisor Program (110) or User Program (010), and not doing DMA.  Another interesting thing to note is that Appendix B implies that FC does NOT differentiate the first word of an opcode anyway (page B-2).  In other words, multiple fetches for the OPERANDS needed for an OPCODE are all Program READs (FC==110 or FC==010).

One thing you could try is tying FC[2:0] to 110 or 010.  I didn't look deep enough into the code to see how upset the IA will get if FC is not changing with other memory access expectations.  It could do horrible and incorrect things.  Or maybe it will spit out enough info to be useful for you.  Easy to do and probably worth a try.

If turns out to be close, maybe there are some tweaks that can be done to the IA source to get what you want.

Also, the STAT label and other symbolic decoding is completely separate from what the IA does.  The IA gets the raw STAT bits and does its own interpretation.

[fenugrec]

No chance of sneaking a few jumpers in there to clip onto?

It's a 0.64mm-pitch PQFP, and I already have a somewhat precarious tangle of probe wires all over the board, so... at the moment, not possible.

One thing you could try is tying FC[2:0] to 110 or 010.

I like your thinking. Will have to try that, hopefully today.

Also, the STAT label and other symbolic decoding is completely separate from what the IA does.

Ah interesting, I hadn't realized that.

Thanks !

[cmax100000]

First thing is thanks to all that have posted on this subject.  It has helped me greatly move along.

I am still having loads of trouble.  My first question is has anyone successfully loaded a "XX" gpib command string to a 1630a and if so which file that is currently posted in this forum worked?

I have loaded all and one loaded but I cant seem to find where anything in my machine changed.  Most give either a CRC error or have a message that the gpib is waiting for further entry on the machine.

I have examined the files and on most have double checked the CRC's and I can't find that as the root cause.  The only thing that I have found odd is there seems to be some files that have trailing 0's after the crc and some use spaces.  In the hp file format reference the padding is done with 20H and the trailing are 0H. 

I have started trying to read the assembly (6809) in the string to try and make headway but it's slow going. esde had some helpful information in his posts about the loader.

Any comments would be helpful or a 1630a verified load of something existing.

Thanks in advance.

[fenugrec]

Hi Mark,

One thing you could try is tying FC[2:0] to 110 or 010.

well, I think it was a good idea, but couldn't get it to work. I got STAT to show '1010 1001' (had to tie BGACK and VMA to vcc as well; VMA is not even present on the mc68302), tried also FC2=1 (so STAT=1110 1001', but the mnemonic column keep saying just 'DMA'. I tried with BGACK=0, both FC= 110 and 010; I think I got all sane combinations but it always says DMA, altohugh the Symbol does indicate the expected 'user pgrm read'  or  'SUPR PGRM READ' based on FC state I forced.

So there's probably more to it in the IA's state machine.
[EDIT]
Ok, I found something weird. In one of the .zip's from this thread, in i68000_p.S :

Code: [Select]

LABEL_0031
    LOAD INPUT_STATUS
    IF 2,2 = 1 THEN GOTO LABEL_0037
    OUTPUT STR_0029    * "DMA"
    RETURN
huh, why is it testing '2,2' as in 'bit position 2' ? So I go to the HP 10391B pdf appendix B, annotated 68010 ia, if I copy-paste the text, I get roughly the same thing

Code: [Select]

NOT_PREFETCH
LOAD INPUT_STATUS
IF 7,7 = 1 THEN GOTO NOT_DMA
OUTPUT DMA
RETURN
Ah, so it *is* testing bit 7. What's going on

[EDIT2] I have not dug more into why the 68000 and 68010 have such a crucial difference in the probe assignments, but I was able, finally, to get a bit of credible disasm output. Thank goodness, because this probing situation is getting out of hand:

[gslick]

There are i68000_p and i68010_p inverse assemblers, and corresponding c68000_p and c68010_p configuration files.

I'd have to load the two configurations files into a logic analyzer and take a look at the differences in what CPU signals are assigned to the analyzer signal labels. Off hand, I don't know what the differences are, and why there are differences.

[MarkL]

First thing is thanks to all that have posted on this subject.  It has helped me greatly move along.

I am still having loads of trouble.  My first question is has anyone successfully loaded a "XX" gpib command string to a 1630a and if so which file that is currently posted in this forum worked?

I have loaded all and one loaded but I cant seem to find where anything in my machine changed.  Most give either a CRC error or have a message that the gpib is waiting for further entry on the machine.
...

I have, to a 1631D.  It will behave the same as a 1630A as far as the IA is concerned.  I don't have it anymore to verify anything further, but I successfully loaded the following IAs:

  https://www.eevblog.com/forum/testgear/searching-for-a-hp-1630-hp-1631-inverse-assembler-files/msg2588835/#msg2588835

If the files in that post won't load, I would suspect an issue with your GPIB adapter, drivers, or other software that they are not supporting an 8-bit clean path.  If it's some kind of serial port GPIB adapter, maybe flow control is not working right.

Also, if you haven't seen that thread before, you might want to go through it as it is specific to IAs on the 163x series.

[MarkL]

Hi Mark,

One thing you could try is tying FC[2:0] to 110 or 010.

well, I think it was a good idea, but couldn't get it to work. I got STAT to show '1010 1001' (had to tie BGACK and VMA to vcc as well; VMA is not even present on the mc68302), tried also FC2=1 (so STAT=1110 1001', but the mnemonic column keep saying just 'DMA'. I tried with BGACK=0, both FC= 110 and 010; I think I got all sane combinations but it always says DMA, altohugh the Symbol does indicate the expected 'user pgrm read'  or  'SUPR PGRM READ' based on FC state I forced.

So there's probably more to it in the IA's state machine.
[EDIT]
Ok, I found something weird. In one of the .zip's from this thread, in i68000_p.S :

Code: [Select]

LABEL_0031
    LOAD INPUT_STATUS
    IF 2,2 = 1 THEN GOTO LABEL_0037
    OUTPUT STR_0029    * "DMA"
    RETURN
huh, why is it testing '2,2' as in 'bit position 2' ? So I go to the HP 10391B pdf appendix B, annotated 68010 ia, if I copy-paste the text, I get roughly the same thing

Code: [Select]

NOT_PREFETCH
LOAD INPUT_STATUS
IF 7,7 = 1 THEN GOTO NOT_DMA
OUTPUT DMA
RETURN
Ah, so it *is* testing bit 7. What's going on

Very strange!  And good sleuthing to find that bit of code!  Which IA are you using for your tests?  i68000_p or i68010_p?

As far as that bit is concerned in the IF statement, "2,2" is testing STAT[2] which is /UDS (not_Upper_Data_Strobe) as described by the config file.  After looking at the 68000/010 manual and wading into the IA source i68000_p.S, I do not see how that bit being "0" can possibly be construed as a DMA cycle.

Looking further into i68000_p.S, it would appear that it prefers a mapping like this:

  STAT[2]: 0=DMA (could be /BGACK or /BG)
  STAT[1]: 0=Program, 1=Data (implies FC0)
  STAT[0]: 0=Write, 1=Read (R_/W)

I don't see any code that cares about any other bits of STAT.

As far as the configs are concerned, c68000_p and c68010_p are the same except that FC is not used (disabled) in c68000_p.  The 68000/010 Preprocessor Operating Manual for the 1650A and 16510A (pub #10311-90913) has some interesting information.  The files C68000_P and C68010_P are mentioned by name in that manual, along with the general-purpose probe connections that correspond to the assignments in c68000_p and c68010_p.  However, this is again inconsistent with the STAT expectations in the disassembled source code in i68000_p.S.

And c68000_p refers to i68000_p, and c68010_p refers to i68010_p, so it's not like c68000_p wants to load the i68010_p IA instead.

So, I am a bit confused and also wondering about the pedigree of i68000_p.

[EDIT2] I have not dug more into why the 68000 and 68010 have such a crucial difference in the probe assignments, but I was able, finally, to get a bit of credible disasm output. Thank goodness, because this probing situation is getting out of hand:

Looks like a fun mess.

What "credible" IA output did you get?

And also, specifically what 68k part # are you probing?  Does your device do DMA?