Products > Test Equipment

HP Logic Analyzer Inverse Assemblers

<< < (35/37) > >>

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: ---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.
--- End code ---

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: ---*  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)
--- End code ---

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:

go4retro:
Does someone have a spreadsheet or other tabular representation of the pod pinouts for various CPUs?

1) I'd like to make up some small PCBs with the pinouts for CPUS I use (6502, 6800, 6809, Z80)

2) I would like to make up some boards that plug into expansion ports of various consoles/systems, some which have inverse assemblers, some that do not, but i figure using a similar layout might make it faster to set up the 16702A here.

If I missed a link to a spreadsheet in the thread, just let me know and I'll go search again.  If there is interest and there is none, I can start a Google sheet...

Jim

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod