HP Logic Analyzer Inverse Assemblers

[gslick]

also looking at the 80186 ( which is one i just picked out of thin air ) , seems Stat/CoProc/Dma Ch all use the same A5 Pod..  but no A4.. so POD4 shouldn't do anything on the IA module.

I haven't found a full manual for the 64658A 10306B 80186/80188 Interface yet, which should have full details on the POD signal connections.

There are manuals available for some of the other preprocessor interfaces, which have full details on the POD signal connections. For example:

64657B 10312D 80286 Preprocessor Interface
http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/10312-90911_10312D_80286_Preprocessor_Operating_Manual_198902.pdf

E2409B 80286 Preprocessor Interface
http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/E2409-90903_E2409B_Intel_80286_Preprocessor_Interface_Users_Guide_Feb92.pdf

10314D 80386DX Preprocessor Interface
http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/10315_90915_10314D_Intel_80386DX_Preprocessor_Interface_Users_Guide_199202.pdf

[Hamster]

I have the Manuals for the z80, 68000 I will try to scan them when i put my hands on them, it has all the pin information in them.

Obviously this isn't needed for the _P IA Options ( non pre-processor )

[gslick]

I have the Manuals for the z80, 68000 I will try to scan them when i put my hands on them, it has all the pin information in them.

Obviously this isn't needed for the _P IA Options ( non pre-processor )

These two manuals have full schematics for the 64683A 10300B Z80 and 64670A 10311B 68000 Preprocessors:

http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/64683A_Z80_Interface_Module_Service_Brief_6483-90901_Jan_1983.pdf

http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/64670A_68000_Interface_Card_Service_Brief_64670-90901_Dec_1982.pdf

If anyone is curious, with preprocessor schematics and the Signal Routing tables B-1 and B-2 in the 10269C manual it can be seen exactly how the signals from the target microprocessor route though the preprocessor and the 10269C to the logic analyzer POD connections.

http://www.bitsavers.org/test_equipment/hp/logic_analyzer_preprocessors/10269-90910_General_Purpose_Probe_Interface_Aug87.pdf

[Hamster]

Based on what i see...

For Z80...  I assume State Machine Mode.. Rising Edge on CLK0 for Qualifier? or Falling Edge?

ADDR

A0  - J4 1 - POD 2 / 0
A1  - J4 2
A2  - J4 3
A3  - J4 4
A4  - J4 5
A5  - J4 6
A6  - J4 7
A7  - J4 8
A8  - J4 9
A9  - J4 10
A10 - J4 13
A11 - J4 14
A12 - J4 15
A13 - J4 16
A14 - J4 17
A15 - J4 18 - POD 2 / 18

DATA

D0 - J3 45 - POD 1 / 0
D1 - J3 46
D2 - J3 47
D3 - J3 48
D4 - J3 49
D5 - J3 50
D6 - J3 51
D7 - J3 52 .. POD 1 / 7


LWR - J3 53   .. POD 1 / 8  [STAT.0]
LIORG - J3 54          [STAT.1]
LRFSH - J3 55          [STAT.2]
LMI   - J3 56         [STAT.3]
LBUSRQ- J3 57         [BUSREQ]*DISABLED
LNMI  - J3 58         [NMI]*DISABLED
LHALT - J3 59         [HALT]*DISABLED
LINT  - J3 60 - POD 1 / 15   [INT]*DISABLED

LMREQ - CLK0/J3 23  -- POD 1 J CLK  ( Memory Request )
LIORQ  - CLK1/J3 21   -- POD 2 K CLK ( IO Request )
LRFSH  - CLK2/J3 17   -- POD 3 L CLK ( Refresh )

LBUSAK - J3 19       -- POD 3 / 0 ( BUS Ack ) ** not in .text file.

LWAIT  - WT5 -- NC ( if you wanted to see this, you need to run a jumper from WT5 over to WT3 or WT2 )

[gslick]

HP 10300B Zilog Z80 Preprocessor for the HP 1650A/51A and HP 16510A Logic Analyzers
Operating Manual, Part Number 10300-90911, February 1989

Table 2-1 Z80 Signal List

CPU Signal  CPU Pin Label       Pod Bit
-----------+-------+-----------+---+-----
LMREQ       19      (Clock)     1   J CLK
LIORQ       20      (Clock)     2   K CLK
LRFSH       28      (Clock)     3   L CLK

A0          30      ADDR        2    0
A1          31      ADDR        2    1
A2          32      ADDR        2    2
A3          33      ADDR        2    3
A4          34      ADDR        2    4
A5          35      ADDR        2    5
A6          36      ADDR        2    6
A7          37      ADDR        2    7
A8          38      ADDR        2    8
A9          39      ADDR        2    9
A10         40      ADDR        2   10
A11          1      ADDR        2   11
A12          2      ADDR        2   12
A13          3      ADDR        2   13
A14          4      ADDR        2   14
A15          5      ADDR        2   15

D0          14      DATA        1    0
D1          15      DATA        1    1
D2          12      DATA        1    2
D3           8      DATA        1    3
D4           7      DATA        1    4
D5           9      DATA        1    5
D6          10      DATA        1    6
D7          13      DATA        1    7

LWR         22      STAT        1    8
LIORQ       20      STAT        1    9
LRFSH       28      STAT        1   10
LM1         27      STAT        1   11
LBUSREQ     25      (Note 1)    1   12
LNMI        17      (Note 1)    1   13
LHALT       18      (Note 1)    1   14
LINT        16      (Note 1)    1   15

Note 1: These signals are not required for inverse assembly and do not appear on the STAT label. However, they may be useful for Z80 analysis.

Clock on (Falling Edge of Clock J + Falling Edge of Clock K)
LMREQ is inverted by the interface module for Clock J
LIORQ is inverted by the interface module for Clock K

To filter out Z80 refresh cycles:
Clock on (Falling Edge of Clock J + Falling Edge of Clock K) * Clock L
Capture data on the falling edge of the J or K clock only when the L clock (LFRSH) is high (not a refresh cycle).

[Hamster]

I would like two hours of my time cross refencing the docs you posted above and not the doc i can't seem to find...

Where did you find this document? And is there a scan available long with ones for the other IA Modules?

HP 10300B Zilog Z80 Preprocessor for the HP 1650A/51A and HP 16510A Logic Analyzers
Operating Manual, Part Number 10300-90911, February 1989

no amount of googling seems to be able to find said document.

[MarkL]

I spent a little time to adapt gslick's IZ80_I.S (the disassembled IZ80_I.R) so that /WR was interpreted normally (i.e., not inverted as it appears from the preprocessor).  This allows it to be used with general purpose probing.  I called it mz80_p.  Zip archive below with the source and the .R file as assembled by the HP 10391B development package.

I also found that the multiple 240/241 buffers in the preprocessor must have delays that are significant to the state clocking.  When using the rising edge of /MREQ and /IOREQ as the clock directly from the CPU, the address and other lines can start changing before those rising edges.  This interferes with a valid capture of state data.  Changes in the address, data, and other lines are actually initiated inside the CPU by the rising edge of Phi (the Z80 clock input).

To keep with the goal of using only general purpose probes and not adding gates to implement delays, Master/Slave clocking was activated which clocks all state data into the slave latches on the rising edge of Phi.  Then on the rising edge of the master clock, /MREQ or /IOREQ, the analyzer completes the state capture.  This seems to work reliably.

User gslick presented a way to filter out refresh cycles in the listing by using the /RFSH signal as a clock qualifier.  An alternative way is to use the Conditional Store feature, and only store those states which are not refreshes.  The end result is the same, but this way preserves a clock input for possibly something else.

Screen captures of various settings I used and output examples below.  I've probed all pins except power, but obviously this is not necessary.  Eventually I'll probably make an adapter to make this easier to set up.

I used mz80_p.r on a 16702B with a 16752A card, which needs to be imported by the IAL utility first.

Please post success or any problems with mz80_p if you try it.

EDIT:  Oops, forgot the zip file and fix typo....

[gslick]

At the same time you were doing that, I was working on the X86 DLL General Purpose Probe version for the 1680/1690/16800/16900 series.

One thing I did different was to set the Slave Clock to be both edges of the Z80 CPU clock. If I understand the Z80 timing diagrams correctly, opcode fetch and interrupt ack cycles end just after a rising edge of the Z80 CPU clock, while memory and I/O read and write cycles end just after a falling edge of the Z80 CPU clock

CPU Signal  CPU Pin Label       Pod Bit
-----------+-------+-----------+---+-----
CLK          6      CLK-J       1   J CLK
LMREQ       19      LMREQ-K     2   K CLK
LIORQ       20      LIORQ-L     3   L CLK
LRFSH       28      LRFSH-M     4   M CLK

A0          30      ADDR        2    0
A1          31      ADDR        2    1
A2          32      ADDR        2    2
A3          33      ADDR        2    3
A4          34      ADDR        2    4
A5          35      ADDR        2    5
A6          36      ADDR        2    6
A7          37      ADDR        2    7
A8          38      ADDR        2    8
A9          39      ADDR        2    9
A10         40      ADDR        2   10
A11          1      ADDR        2   11
A12          2      ADDR        2   12
A13          3      ADDR        2   13
A14          4      ADDR        2   14
A15          5      ADDR        2   15

D0          14      DATA        1    0
D1          15      DATA        1    1
D2          12      DATA        1    2
D3           8      DATA        1    3
D4           7      DATA        1    4
D5           9      DATA        1    5
D6          10      DATA        1    6
D7          13      DATA        1    7

LWR         22      STAT        1    8
LIORQ       20      STAT        1    9
LRFSH       28      STAT        1   10
LM1         27      STAT        1   11
LBUSREQ     25      (Note 1)    1   12
LNMI        17      (Note 1)    1   13
LHALT       18      (Note 1)    1   14
LINT        16      (Note 1)    1   15

Note 1: These signals are not required for inverse assembly and do not appear on the STAT label. However, they may be useful for Z80 analysis.

Slave Clock:
Both Edges of Clock J

Master Clock:
(Rising Edge of Clock K + Rising Edge of Clock L)
Filter Out Refresh Cycles:
(Rising Edge of Clock K + Rising Edge of Clock L) * Clock M

[gslick]

What do you call those 1-to-4 0.1 pin header breakout connectors? I couldn't guess the correct search term to find them. Where can you get them? I could have used some of those to make it easier to attach the doubled up flying lead connections to the DIP test clip.

[MarkL]

What do you call those 1-to-4 0.1 pin header breakout connectors? I couldn't guess the correct search term to find them. Where can you get them? I could have used some of those to make it easier to attach the doubled up flying lead connections to the DIP test clip.

The part number is HP 16515-27601 "GND CONNECTOR".  They're included with the 16517-68701 Master Board Accessory Kit and 16518-68701 Expander Board Accessory Kit., but only two per kit.  I haven't seen them anywhere else.  They're fairly handy and I'd buy a pile of them if I could find them in quantity.

I think you're right about the memory and I/O cycles.  It is a little different than the opcode fetch.  Using the rising edge of CLK cuts the sample window a little short, but it still seems to be sampled with plenty of margin.  Properly, though, I think you're right to sample on both edges.  I'll have to look a little more into this.

Did you try the IA I posted, or did you already have a version?  Just wanted to confirm it's working ok for others.  If you already modified the Z80 IA and posted it before, sorry I missed it.

[gslick]

Here are some sample Z80 waveforms I captured with Timing Zoom enabled so that both state and timing samples are available.

With the Slave Clock set to both the rising and falling edges of the CPU Clock, in the Opcode Fetch waveform sample the relevant Slave Clock edge is the rising edge of the CPU clock at the marker position T3-H, just prior to the Master Clock at the rising edge of LMREQ at the marker position MREQ-H.

With the Slave Clock set to both the rising and falling edges of the CPU Clock, in the Memory Read waveform sample the relevant Slave Clock edge is the falling edge of the CPU clock at the marker position T3-L, just prior to the Master Clock at the rising edge of LMREQ at the marker position MREQ-H.

If the Slave Clock was set to only the rising edge or only the falling edge of the CPU Clock, the timing margin to capture valid state data could be reduced by half of a clock period, which could possibly be an issue if the access times of devices in the target system were near the timing margin limits.

Zilog databook timing diagrams came from here:
http://www.bitsavers.org/components/zilog/z80/03-0029-01_Z80_CPU_Technical_Manual_1977.pdf

[MarkL]

The opcode fetch is a faster cycle than a regular memory fetch.  Below is the opcode fetch timing cycle without the wait states.  The first byte of the instruction is sampled by the CPU on the second rising edge of PHI after /MREQ falls.  In rough numbers, this allows 1.5 clock periods for access time.

A memory data read is sampled by the CPU on the second falling edge of PHI after /MREQ falls, allowing it roughly 2 clock cycles for access time.

Since the opcodes and operands necessarily share the same physical memory in the Z80 architecture, they therefore have the same access speed requirements.  The system must be designed to support the higher speed of the opcode fetch cycle.

So, LA slave sampling on the rising edge of PHI, with only 1.5 cycles of access time, should always work for memory.  I suppose it's possible that a Z80 system could be designed with slower memory that is only for data and never instructions, but I've never seen that.

However, in the case of an I/O read, the cycle time is roughly 2.5 cycles, and starts on a rising edge of PHI, which is later in phase than an opcode or memory cycle.  See I/O timing below (the "Tw" in the diagram is an automatically inserted wait state).  If the LA slave was sampling only on the rising edge of PHI, the peripheral read would have only 2 cycles to settle.  Giving it an extra half cycle to settle is probably not going to make a difference since peripheral registers, etc. are generally much faster to access than memory, but it would be wrong to assume this is always the case.

I think I'm convinced sampling on both edges of PHI is the right thing.

[MarkL]

One interesting thing in my timing capture is that the address lines start changing before the rising edge of /MREQ.  When using /MREQ * /IORQ as the only clock, which I tried first, it created nonsensical results in the state capture.  This is what led me to look at PHI to do the slave latch capture.

However, in your timing digram, the address lines are stable for at least 80ns (MemRead) to 200ns (OpFetch), leaving plenty of time to use /MREQ * /IORQ in master mode as the only clock (no slave).

With your previous analysis of buffer delays in the Z80 Interface Module:

  https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412

I'm not sure how this would have ever worked for me, since /MREQ * /IORQ would occur even later because of the buffer delays.

One difference in my system is that I'm using a Zilog Z80H, which is the 8MHz variant (in contrast to the standard part speed of 4MHz).  It's not beyond reason that the external bus interface in the chip was modified for the higher speed and behaves a little differently.  The Z80H was introduced in 1982 (wikipedia), perhaps after the Interface Module was released?

At any rate, it doesn't change the approach to use master/slave clocking, or clocking on both edges of PHI.  In fact, it's required in my case.  Just thought it was interesting.

[Hamster]

This is great stuff  ! Love it.. I have two large driving arcades leaving and going to setup a proper station so i can test things out and dig in and help.

[gslick]

One interesting thing in my timing capture is that the address lines start changing before the rising edge of /MREQ.  When using /MREQ * /IORQ as the only clock, which I tried first, it created nonsensical results in the state capture.  This is what led me to look at PHI to do the slave latch capture.

However, in your timing digram, the address lines are stable for at least 80ns (MemRead) to 200ns (OpFetch), leaving plenty of time to use /MREQ * /IORQ in master mode as the only clock (no slave).

With your previous analysis of buffer delays in the Z80 Interface Module:

  https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412

I'm not sure how this would have ever worked for me, since /MREQ * /IORQ would occur even later because of the buffer delays.

From https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412

Once through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 19 /MREQ    CLOCK J

Once through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 20 /IORQ    CLOCK K

Twice through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 20 /IORQ    STAT BIT 1

Three times through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 22 /WR      STAT BIT 0

One result of that is that the /WR signal as used for a STAT bit should be delayed by two gate propagation delay periods relative to the /MREQ and /IOREQ signals as used for the J and K clocks.

Delaying the /WR signal before it is sampled at the /MREQ and /IOREQ signal edges as used for the J and K clocks when using the 10300B Z80 preprocessor might be important if the /WR signal transition at the CPU pin can occur before the /MREQ signal transition at the CPU pin.

That appears to be occurring in the trace that I previously acquired when I scrolled forward to a memory write cycle. The rising edge of the /WR signal appears to occur around 3.25ns before the rising edge of the /MREQ signal (with the Timing Zoom sampling resolution of 250ps).

[MarkL]

...
Delaying the /WR signal before it is sampled at the /MREQ and /IOREQ signal edges as used for the J and K clocks when using the 10300B Z80 preprocessor might be important if the /WR signal transition at the CPU pin can occur before the /MREQ signal transition at the CPU pin.

That appears to be occurring in the trace that I previously acquired when I scrolled forward to a memory write cycle. The rising edge of the /WR signal appears to occur around 3.25ns before the rising edge of the /MREQ signal (with the Timing Zoom sampling resolution of 250ps).

Going back in my captured data, I also see /WR going high (mumble) 8ns before /MREQ in some cases.  For example, the first address byte pushed on the stack in a CALL is that way, but the second address byte has /WR coincident with /MREQ, at least as far as 4ns TZ sampling can tell.  (I don't have the system set up anymore to get a more precise delay measurement.)

Fortunately, slave latch clocking on both edges of PHI saves us there too for the general probing case.

Side note: For some reason the reload of data did not restore the symbols for STAT_TZ.  It was certainly there when doing the capture.  Maybe a bug?  Oh well... that's not getting fixed.

[MarkL]

This is great stuff  ! Love it.. I have two large driving arcades leaving and going to setup a proper station so i can test things out and dig in and help.

All fun!  Glad it's helpful for you!

[gslick]

What do you call those 1-to-4 0.1 pin header breakout connectors? I couldn't guess the correct search term to find them. Where can you get them? I could have used some of those to make it easier to attach the doubled up flying lead connections to the DIP test clip.

The part number is HP 16515-27601 "GND CONNECTOR".  They're included with the 16517-68701 Master Board Accessory Kit and 16518-68701 Expander Board Accessory Kit., but only two per kit.  I haven't seen them anywhere else.  They're fairly handy and I'd buy a pile of them if I could find them in quantity.

Thanks for the part number.

This eBay listing photo shows two of those 16515-27601 in the item listing photo for $9.95, plus shipping. Not clear if two are included per item purchase, or only one:

Keysight 16515-27601 Ground Connector for 16517-68701 Accessory Kit
https://www.ebay.com/itm/354835319679

This eBay listing photo shows four of those in the item listing photo with some ground leads and some sort of probe for $19.95 (OBO), plus shipping. I assume in this listing everything in the item listing photo would be included. Not super cheap, but not an outrageous price if makes things easier to get probes set up.

Keysight 16515-68703 16515A 16516A 1 GHz Timing Probe Accessory Kit
https://www.ebay.com/itm/350517306271

[MarkL]

...
This eBay listing photo shows two of those 16515-27601 in the item listing photo for $9.95, plus shipping. Not clear if two are included per item purchase, or only one:

Keysight 16515-27601 Ground Connector for 16517-68701 Accessory Kit
https://www.ebay.com/itm/354835319679

This eBay listing photo shows four of those in the item listing photo with some ground leads and some sort of probe for $19.95 (OBO), plus shipping. I assume in this listing everything in the item listing photo would be included. Not super cheap, but not an outrageous price if makes things easier to get probes set up.

Keysight 16515-68703 16515A 16516A 1 GHz Timing Probe Accessory Kit
https://www.ebay.com/itm/350517306271

I saw the first listing and it seemed a bit pricey when you add in shipping, but I didn't know the ground connectors were also provided in the 16515-68703.  Thanks!

Those other leads in the pouch are ground extenders, 6" M-F and fit standard 25mil posts.  I have a few of those too, but I don't know where I got them.  Why HP has 6" ground leads in a GHz probe set seems strange, but they are a handy accessory.  With those included the package at the same price, I may have to get some.  I've purchased from Global Test before.  They tend to accept reasonable offers when buying a quantity, and they combine shipping.

[MarkL]

And that probe is probably one of these, below.  It has a 200 ohm series resistor inside ot it.  The non-pointy end is 0.1" spacing.  I have several of those too, but they don't fit anything I have.

I guess somewhere I must have inherited some of those 16515-68703 kits, or at least the contents of them.  A lot of the time these things are just thrown in with other LA accessories when buying on ebay.

[Nemesis1207]

Has anyone been able to successfully load inverse assemblers on the 1670G? I've been bashing away at this for a couple of days now without any real progress. I have the invasm_v3 files transferred over, and the unit seems to recognize them. The config files load in happily, but when I try and load the inverse assemblers, any of them, the unit hangs for 30 seconds or so then fails to load and/or crashes, like this:


I'm after the z80 and 68000 ones in particular, but it doesn't seem to matter what inverse assembler I pick as all the ones I've tried fail in the same manner. Any advice appreciated.

[Nemesis1207]

Never mind, got that sorted. I was loading files onto the unit via ftp, since the 1670G has a LAN port. I thought I'd setup my ftp client to transfer everything in binary mode (IE, don't try and do newline translation), but it turns out there was a sneaky setting to treat all files without extensions (like "i68000_p") as text, meaning it was corrupting the binaries. The inverse assemblers now appear to load. Just got to mess around with pod mappings now so they work properly. At least while going around in circles over the last two days I've got setup to build these things from source, so I'll be able to hack away at them.

[Nemesis1207]

There didn't seem to be any tool in existence that could create a "HFSLIF" single-file image for these HP systems, which means while it was possible to transfer the existing inverse assembler "images" in this thread to a HP unit via FTP, the only way to get the "relocatable" versions of the inverse assemblers onto the system in a format it would recognize was to use IALDOWN.EXE, which only supports serial and GPIB, and even then only within dosbox or on a native dos system. I found that annoying, so I wrote a command line tool to go straight from a .A file to an inverse assembler file in a HFSLIF image. It's written in C# for .NET 8, so it can compile and run on anything. Here's the github repo:
https://github.com/RogerSanders/HFSLIFWriter
The tool itself is currently geared to these inverse assemblers specifically, but the code is generic and with some trivial changes it could support packing any kind of files into these HFSLIF images, if that ends up being useful to anyone. The code itself describes the image format well, so it'll serve as useful documentation if nothing else for anything that comes after.

For convenience, here's a pre-compiled Windows exe that's been compiled down to native machine code with no external .NET dependencies or anything else:
https://github.com/RogerSanders/HFSLIFWriter/releases/download/v1.0/HFSLIFWriter.exe

Usage as follows:

Code: [Select]

Packs a relocatable HP Inverse Assembler into a HFSLIF file structure, suitable
for transferring to a HP Logic Analyzer via FTP. This program provides an
alternative to the HP provided IALDOWN.EXE file, which only supports uploading
via a serial or GPIB connection.

usage:
HFSLIFWriter.exe inputFilePath outputFilePath fileDescription invasmFieldOpt

inputFilePath    Path to the relocatable inverse assembler file on disk.
                 Usually a ".A" file as output by ASM.EXE.
outputFilePath   Path to write the generated HFSLIF file to
fileDescription  A file description up to 32 characters to display on the logic
                 analyzer when listing this file on disk.
invasmFieldOpt   The control setting for the invasm field. Usage is the same as
                 in IALDOWN.EXE, a single character of A,B,C or D must be
                 specified as follows:
                    A = No "Invasm" Field
                    B = "Invasm" Field with no pop-up
                    C = "Invasm" Field with pop-up. 2 choices in pop-up.
                    D = "Invasm" Field with pop-up. 8 choices in pop-up.

[Nemesis1207]

I've been mainly working with the 68000 inverse assembler so far, and I wanted to post a few comments here to help anyone else who might try and do the same.

First of all, it's worth noting that the 68000, 68008, and 68010 inverse assemblers are almost identical, which makes sense, since the processors themselves share almost the same instruction set and physical interface. The disassembled source for the inverse assemblers in this thread is very useful, but we actually have the original sourcecode for the 68010 inverse assembler in the 10391B Inverse Assembler Development Package here:
https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/10391b-inverse-assembler-development-package-version-0200-sw575.html
In the "Examples" folder is I68010.S, which on comparison with the disassembled 68010 inverse assembler in the INVASM_SRC.zip file supplied in this thread, I've verified has identical code, apart from a minor difference in the entry point around task setup, which may even be injected at compilation time by ASM.EXE, I haven't checked. The actual steps around disassembly are the same though, and critically this original source file has all the comments and proper names intact, making it much more readable.

From the comments in the original 68010 inverse assembler source, and the great resources in this thread, it's fairly easy to work out the pin mappings for the pod connections. From the header comments of the disassembler, we have this:

Code: [Select]

*  THE LOGIC ANALYZER CAPTURES 24 ADDRESS LINES, 16 DATA LINES AND
*  8 STATUS LINES ON THE RISING EDGE OF LAS.
*
*  THE 8 STATUS LINES FOR THIS INVERSE ASSEMBLER ARE:
*
*           BIT 0  ---  R/LW  (CPU PIN 9)
*           BIT 1  ---  LLDS  (CPU PIN 8)
*           BIT 2  ---  LUDS  (CPU PIN 7)
*           BIT 3  ---  LVMA  (CPU PIN 19)
*           BIT 4  ---  FC0  (CPU PIN 28)
*           BIT 5  ---  FC1  (CPU PIN 27)
*           BIT 6  ---  FC2  (CPU PIN 26)
*           BIT 7  ---  LBGACK  (CPU PIN 12)
Here's what I did, which follows the expectations of the config files with the invasm_v3.zip archive here:
Pod A1:
15-0 - D15-D0
CLK - AS

Pod A2:
15-1 - A15-A1
0 - UDS

Pod A4:
15-8 - A23-A16
7 - BGACK
6-4 - FC2-FC0
3 - VMA
2 - UDS
1 - LDS
0 - R/W

Here's what it looks like on the unit:



Using UDS as A0 may seem counter-intuitive, but there's no external A0 line on the 68000, it's the UDS and LDS strobes that indicate which half of the 16-bit data bus is being read/written to perform 8-bit operations. Now LDS being asserted and UDS not asserted is how you'd normally tell when you were doing an 8-bit operation on an odd address, but UDS and LDS are active low, while the address lines use a high logic level when asserted, so we use UDS being high, indicating there is not valid data on the "upper" (even address) data lines, to work out that it must be an 8-bit odd address operation.

While trying to use the 68010_P inverse assembler on my 1670G though, I ran into problems right away - none of the instructions would actually disassemble. It became clear why on some examination, the UDS and LDS lines were both logic high when sampled. As per the comments in the original source file, the system wants you to connect your clock signal to AS, the address strobe, and set it to trigger on the rising edge. This line is active low, so basically when a bus operation (IE, read or write generally) is being completed, we latch all the lines. That's all well and good, except as per the 68000 User's manual, when performing either a read or a write, at the falling edge of the main clock entering S7 "the processor negates AS, UDS, or LDS". Negates in this context meaning no longer asserts, which being active low signals mean these strobes all go high. Since we sample at the edge of AS going high, it makes perfect sense that UDS and LDS would also have been negated at this point. We need to know what UDS and LDS were set to prior to this occurring. The solution to this problem is already given above as for the Z80 - we need to use slave clock settings to sample these lines. Doing this is easy - we connect the clock source for the CPU to another pod clock (I used clock M on pod 4), and set it up as a slave clock source to trigger on the rising edge of the clock:


We then assign this slave clock to pods A4 and A2, so that UDS/LDS in both the "STAT" field and the A0 position of the address are sampled using the slave clock. And since the slave clock is triggered on the rising edge of the CPU clock signal, while AS being negated (going high) occurs on the falling edge of the CPU clock, we'll now latch everything but the data lines a half-clock cycle prior to AS being negated. Since the data lines don't get negated by the CPU on a write until another half clock cycle, and for reads until the devices have a chance to see and respond to AS being negated, we're safe to sample them with the main clock. With this configuration, the inverse assembler works as expected. When interpreting results though, it's important to have a solid idea of how 68000 prefetch works, since the logic analyzer will show instruction words being pulled in while the prior instruction is still executing, meaning you may see things logically out of order from a code perspective, but in the correct order for how the bus operations actually occur in hardware. The result is something like this: