Searching for a HP 1630 HP 1631 inverse assembler files.

[harrimansat]

Hi,

I´m playing with my old logic analyzer. Now is connected to my PC with windows 8 and a HP USB to GPIB. Now I can send and read configurations, and data waveforms. And I can send some of the inverse assembler files that I have, and it works.

But I can't make work HP 10391B Inverse Assembler Development Package, neither with my old XP computer, it needs a serial connection with LA, HP-IL. And assembler files exe doesn't work properly.

Anyone has inverse assembler files for this analyser?
Anyone has experience doing inverse assembler files for this LA, there is some way to make inverse assembler files for the LA with out connection?

Thanks
Regards

[Andy Watson]

And I can send some of the inverse assembler files that I have, and it works.

How ? I have a 1630 and have managed to upload and download configurations but I could not find any details about uploading things like the inverse assembler.

Sorry, I can't help with the assemblers - I only have the same 10391B software - and I'm running Linux.

[harrimansat]

Thanks Andy

You can write attached file, 6809 to your LA like it was a configuration file, try it

[Andy Watson]

Thanks. I'll will try pushing that inverse assembler down the gpib next time I fire-up the 1630.

I have just been playing with the ASM.EXE from the inverse assembler tools - I can't get any sense out of it. It seems to run in a dosbox but it can't find the appropriate "table" file. 

[MarkL]

I have just been playing with the ASM.EXE from the inverse assembler tools - I can't get any sense out of it. It seems to run in a dosbox but it can't find the appropriate "table" file.

Are you using this IA package from HP/Agilent/Keysight? :

  http://www.keysight.com/main/software.jspx?ckey=sw575&lc=eng&cc=US&nid=-536900196.536895355&id=sw575

After running the included "INSATLL.BAT", the file "HP64700/TABLES/AIAL.TXT" should be renamed to "HP64700/TABLES/AIAL".  The assembler is hard-coded to look for it.  For some reason they erroneously tacked a ".txt" on that file name in the zip archive.

[harrimansat]

Thanks!!! I will tray it

[MarkL]

Thanks Andy

You can write attached file, 6809 to your LA like it was a configuration file, try it

How did you generate this file?

[harrimansat]

Hi,

It doesn´t works, AIAL file doesn't have any extension. A GPIB guru send me some compiled 1631d inverse assembler files, attached.
Some files must be cropped at beginning and end, it must begin with XX charts.

[MarkL]

Hi,

It doesn´t works, AIAL file doesn't have any extension.
...

Attached is a zip archive of the above Keysight IA that is freshly installed and works; I just tried it.

I don't know how you would run this under windows, but in linux you can unzip this archive in your home directory, run dosbox, and from dosbox compile the I68010 example:

  Z:\>mount c ~/dos/c
  Drive C is mounted as local directory /home/user/dos/c/

  Z:\>c:
  C:\>asm i68010.s

  C:\>

This will create the output files I68010.A and I68010.R in ~/dos/c.  Other options to ASM will get you a listing file, etc.

[harrimansat]

Thanks, ASM works in DOSBOX!

Now the problem is if I can upload R file...i don't have an HP-IL adapter. Is possible to build target file with out RS232 connection?

 

[Andy Watson]

Is possible to build target file with out RS232 connection?

I think that is how the IALDOWN software is intended to work. Page 1-9 of "HP 10391B Inverse Assembler Manual 10039103.pdf" describes setting-up the RS232 on COM 1 or COM 2 of the PC.

This is a page with an interesting link:
http://www.vcfed.org/forum/archive/index.php/t-52726.html
I have not yet tried to unpack the Z80 stuff but I believe that the Inverse assembler code is common to 16xx series and it's the communication between the analyser and the IALDOWN program that does the relocation for the specific analyser.

[MarkL]

The 1631D doesn't have an RS232 port (unfortunately), so IALDOWN won't help.

Here's a page makes a reference to a program called "FORMAT.EXE" (a poor choice for a user program name) which is used to convert the .R file to "older" analyzers:

  http://www.rudiswiki.de/wiki9/HP1652InverseAssembler

Download the .R file to the HP1652B Floppy Disk

Because the Inverse Assembler produces a relocatable output file only, it must be adopted to the target Logic Analyzer. In the case of the HP1652B this is done via a RS232 download to the Logic Analyzer , there processed and then written to the floppy disk. On younger Logic Analyzers from HP the program FORMAT.EXE is used to do that off-line in the Analyzer itself.

In addition, the version of IA we all have access to (10391B, v2.00) *implies* that it indeed does not support the 1631D (see attached IA manual snippet, "TASK will always be 5 or greater.").  Perhaps a previous version of the IA package is what's needed and provides "FORMAT.EXE".

You could also try setting up the HPDrive emulator:

  http://www.hp9845.net/9845/projects/hpdrive/

and see if the 1631D recognizes the .R file on virtual drive.  But my guess is it probably wants it to be "formatted" first.


If anyone has figured this out, please post.  I don't have an urgent need for IA on the 1631D, but it has been eluding me too (for years).


EDIT:  I sent email to the author of the page that mentions FORMAT.EXE, and also pointed them here.  I'll share if I get a response.

[MarkL]

...
A GPIB guru send me some compiled 1631d inverse assembler files, attached.
Some files must be cropped at beginning and end, it must begin with XX charts.

Thanks for the archive of IA files.  These look like they were from the disk that came with the HP 10342B bus preprocessor, plus a couple of other files.

There are two types of files: One that starts with XX which is an undocumented command to load inverse assemblers into the 1631D (and similar), and others that begin with RC.  The RC files are "learn string" configuration files to set up the signal assignments (see programmer manual for details).  It would make sense that to use the 10342B you would need to load both the config and inverse assembler files for a particular protocol.

I've attached a zip file that has the pure XX and RC files extracted from your originals.  Files ending with "c" are the RC files, and "i" are the XX (inverse assembler) files.  I tested these with my 1631D and they load without error, but I didn't try to use them. (Except for I68000P8i, where I got a displayed error: Not 1631D Compatible.)

With other HP analyzers, there's a naming convention that a "P" at the end means for use with general purpose probing, and "I" means for use with a preprocessor.  Seems likely that's the case here too (eg., I6809P vs. I6809I).

At this point I'm just posting what I know in the hopes that we can collectively figure this out, namely how to go from the IA assembler to the 163x analyzers.  We now know we can load "XX" IA files into the 163x series.  I think we just need to get from the .R format to a binary that starts with "XX".

[harrimansat]

http://www.massmind.org/techref/postbot.asp?by=thread&id=%25Analyser%25&w=body&tgt=top

Hi,
  I know a few folks here own HP 1600-series logic analysers, so I hope this
 isn't stretching the boundaries of on-topicness too much..

  I've just hacked together a little symbol loader for the 1651B. All it does
 is read a text file full of "LABEL = $F00D" format lines, then loads them all
 into the 1651B's symbol table. Very handy when debugging microprocessor
 systems with one of these analysers (especially when you've got an inverse
 assembler for the target CPU).

  In addition to that, I've also thrown together a 6502 inverse assembler for
 the 1651B (though it *should* work on the other 1650 and 16500 series
 machines too). It understands all the Western Design Center 65C02S "extra"
 instructions, and should (in theory at least) work with raw 6502 and Rockwell
 65C02 code as well.
  Oh, and it calculates the actual target of relative addresses, too. And
 cross-references addresses against the analyser's symbol table (see above)

  Now for the icing on the cake - I've also written an inverse assembler
 downloader. The old IALDOWN util that HP released with the Inverse Assembler
 Toolkit won't work on anything faster than a PC/AT (IIRC), so I grabbed a
 copy of the 1650B Programmer's Manual and threw together a Windows-based
 (although it could be ported to Linux console-mode easily enough) tool to
 replace IALDOWN.

  OK, so the million dollar question is, should I clean up the code for these
 apps and release them? Does anyone else use one of these analysers, or am I
 the only person on the planet who considers a 1651B to be "good enough"?

  Has anyone else written any little tools or analyser addons like these?
  What about inverse assemblers?
 I've seen the 8008 disassembler Jim Kearney wrote, but that seems to be about
 it...

  Licence will probably be a BSD derivative - along the lines of "Use it as
 much as you like and for whatever you want as long as you credit me in
 whatever you derive from it, and change the name of your app."

  IALDown32 was written with Delphi 3, the symbol table uploader was written
 in ANSI C using mingw32 (read: GCC with a Win32 twist).

 Thanks.
 --
 Phil.                              | Acorn RiscPC600 SA220 64MB+6GB 100baseT
philpemspamphilpem.me.uk              | Athlon64 3200+ A8VDeluxe R2 512MB+100GB
http://www.philpem.me.uk/          | Panasonic CF-25 Mk.2 Toughbook
 ... :.::: ::..: ::.::.  :..:: Tagline in Braille

[MarkL]

Thanks for the linked posts, harrimansat.

The 165x is quite a different beast from the older 163x.

After reading the above posts, I was curious what IALDOWN might be doing with the 165x that we could leverage for the 163x.  I was hoping that maybe there would be some conversion of the .R format into something more useful.  But the answer is it's not doing anything.

IALDOWN simply downloads the .R file to the 165x analyzer.  Any further linking or conversion to bytecode is done on the 165x itself.

IALDOWN uses the MMEM command to do the transfer, which is documented in the 1650B programmer manual.  The data it sends out the COM port looks like this (for example):

  MMEM:DOWNLOAD "filename" ,"description",-15614,#800004875<type-byte><.R file>

Where:

  "filename" and "description" are what the user typed at the IALDOWN prompts

  -15614 means file type is Inverse Assembler

  00004875 is the length in decimal of the following binary block

  <type-byte> is the user response to the "Invasm" Field Options:

    0xff if the answer was "A"
    0x00 if the answer was "B"
    0x01 if the answer was "C"
    0x02 if the answer was "D"

  <.R file> is the contents of the .R file (in this example I8085.R, which is 4874 bytes long)


So, this is no help at all for the 1631D and its required "XX" format.


One of the above posts you linked mentions that the utilities for the 1631D were never sold to customers.  I've searched the HP catalog archives from when the 163x was introduced until it was phased out, and I believe that is correct.  There is only mention of the 10391A/B development package in relation to the 165x, which we already know about.

I think the ability to do this for the 1631D may be lost to time.


You said you got those IA files from a "GPIB guru".  Some of those files are in 1631D "XX" format and they don't look like they are from the original disks, namely TEST44c.#fffe and testc.#fffe.  This implies that whoever created them might have access to the utilities, or know how the conversion can be done.

Can you ask whoever it was?

[harrimansat]

Hi

This is the guy who sent my the files:

http://www.dalton.ax/hp1631d/

http://www.dalton.ax/gpib/

[harrimansat]

I´m trying to understand because manual talks about 1631, may be we need a older asm file.

[Andy Watson]

The note at the bottom of page B-19 says that the 1630's are restricted to the option B and also not to use the INITIAL FLAGS or INITIAL OPTIONS.

The HP 1630 family of logic analyzers do not support options C and D
of the download program IALDOWN. Only the simple
synchronization using option B is available with these instruments. If
the source code will also be used for the HP 1630A/D/G or
HP 1631A/D, do not use the INITIAL_FLAGS or
INITIAL_OPTIONS communication variables.

I would guess that the assembler is ok but you need to be careful which options and features you use.

[MarkL]

I´m trying to understand because manual talks about 1631, may be we need a older asm file.

I think so also.  We may need 10391A (instead of the B version), but I'm still not seeing any reference in the old catalogs that says the A version is ok for the 163x series.  What we seek could be a differently numbered product (which I haven't been able to identify), or perhaps buried in a related package that was available for one of their old microcomputers.

If I were to venture guess, I think at some point HP decided to productize their internal tool, which is what they used to create the pre-defined inverse assemblers for the 163x series.  The 163x appears in the documentation because 1) they had to produce documentation for their own internal developers and/or, 2) they provided the tools to certain third parties to outsource IA development.  Once the development kit was productized and orderable by regular customers, it was decided not to support the 163x and those utilities were omitted, but the 163x still appeared in the documentation.  Again, I'm only guessing.

I'm hoping someone has a copy of the needed utility left over from long ago.

But if you really need inverse assembly now, 165x analyzers which are compatible with the 10391B development package can be had for < $100, and much more capable analyzers which are also compatible, such as the 16700B series, are typically a few hundred $$.

[MarkL]

The note at the bottom of page B-19 says that the 1630's are restricted to the option B and also not to use the INITIAL FLAGS or INITIAL OPTIONS.

The HP 1630 family of logic analyzers do not support options C and D
of the download program IALDOWN. Only the simple
synchronization using option B is available with these instruments. If
the source code will also be used for the HP 1630A/D/G or
HP 1631A/D, do not use the INITIAL_FLAGS or
INITIAL_OPTIONS communication variables.

I would guess that the assembler is ok but you need to be careful which options and features you use.

I think you're right.  We can create a fully compatible .R file for a 1630A/D/G, but we just can't get it converted/linked/whatevered into "XX" format.

It's also an odd statement in the manual regarding IALDOWN and the 1630A/D/G.  The 1630A/D/G has no RS232 capability at all, so it's fundamentally incompatible with IALDOWN.

Maybe there was an HPIB or HP-IL version of IALDOWN that worked with the 163x?

[MarkL]

I said:

You said you got those IA files from a "GPIB guru".  Some of those files are in 1631D "XX" format and they don't look like they are from the original disks, namely TEST44c.#fffe and testc.#fffe.  This implies that whoever created them might have access to the utilities, or know how the conversion can be done.

Oops, I have to take that back about those extra files.

The two files, TEST44c.#fffe and testc.#fffe, end with "c" and are *configuration* files (consistent with what I wrote before).  They start with RC, not XX.  It's easy to create those with the TC (Transmit Configuration) HPIB command.

So, it's NOT evidence someone has created a custom inverse assembler for a 163x.  Bummer.

[gslick]

I have original HP 3.5-inch floppies for the 8085 Inverse Assembler for the 1630A/D/G and 1631A/D part number 10304-13012, and the 10342 Bus Preprocessor Inverse Assembler for the 1630A/D/G and 1631A/D part number 10342-13012.

[AndersG]

If you have those disks, then can you please create LIF-files out of those and post? Someone could then just extract the individual files, using HPDir or put them on an SD card for HPDisk.

I think that I am the "guru" referred to earlier and yes, the files that begin with TEST* or DALT* are indeed just test files. I simply grabbed one of the LIF images I had used.

I am definitely not a "guru", just a humble hobbyist that happen to own a 1631D, I also have the 10269 for the 680x-processors. I did put together a small page for the 1631D with tips on how to create new connectors for the pods for example.

Thanks for all the valuable input in this thread!

[gslick]

If you have those disks, then can you please create LIF-files out of those and post? Someone could then just extract the individual files, using HPDir or put them on an SD card for HPDisk.

Attached are images of the part number 10304-13012 and 10342-13012 3.5-inch floppies.

c:\HPDir\Hpdir.exe -list 10304.hpi
                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
COPYFILEx               1 98X6 #fffe       30      256 15-Aug-85 16:20
I8085IPi                1 98X6 #fffe        9      256 13-Jun-84 07:41

274176 of 284160 bytes free.

c:\HPDir\Hpdir.exe -list 10342.hpi
                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
COPYFILEx               1 98X6 #fffe       30      256 15-Aug-85 16:20
IHPIBc                  1 98X6 #fffe       21      256 25-Jul-85 07:04
IHPIBi                  1 98X6 #fffe        6      256 24-May-85 10:23
IHPIBGc                 1 98X6 #fffe       22      256 25-Jul-85 06:55
IRS232Cc                1 98X6 #fffe       21      256 24-Jul-85 08:12
IRS232Ci                1 98X6 #fffe       16      256 22-Jul-85 10:51
IRS232Gc                1 98X6 #fffe       22      256 24-Jul-85 08:32
IRS449c                 1 98X6 #fffe       21      256 25-Jul-85 08:23
IRS449i                 1 98X6 #fffe       16      256 22-Jul-85 10:52
IRS449Gc                1 98X6 #fffe       22      256 24-Jul-85 08:35

233728 of 284160 bytes free.

[harrimansat]

Thanks for your post, wich type of HPDIR  do you use, mine doesn´t works

[Andy Watson]

Check the file name that you have provided to the HPdir program. It is missing the first number "10304-". Perhaps it needs escaping (I'm not a windows user).

[gslick]

I had long file names in the .zip file. Hpdir didn't seem to like using the long names so I simply renamed the files with short names to use with hpdir.

EDIT: It appears that in general using longer file names isn't a problem with hpdir, but some characters in the file name might cause problems. Removing the dash character from the file name solves the problem.

C:\HPDir\Hpdir.exe -list 10304-13012.hpi
Error: Can't open file (Msus "10304-13012.hpi")

copy 10304-13012.hpi 1030413012.hpi
        1 file(s) copied.

C:\HPDir\Hpdir.exe -list 1030413012.hpi
                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
COPYFILEx               1 98X6 #fffe       30      256 15-Aug-85 16:20
I8085IPi                1 98X6 #fffe        9      256 13-Jun-84 07:41

274176 of 284160 bytes free.

[MarkL]

I said, earlier in this thread:

EDIT:  I sent email to the author of the page that mentions FORMAT.EXE, and also pointed them here.  I'll share if I get a response.

I received a reply from this person yesterday.  In short, they read it somewhere in an HP publication and they don't have the FORMAT.EXE utility to convert .R files to 1631D XX format.

Another dead end.  Sorry, folks.

[MarkL]

I looked at the disk images provided by gslick (thanks, gslick!).

One thing I noticed is that the COPYFILE utility on those disks is also in XX format.  So, it would seem that XX format for the 1631D is not only for inverse assembler files, but it's really a generalized mechanism for loading executables,  or a "plug-in" (which might be more accurate in today's parlance).

So the .R file probably gets converted and linked specifically for the 1631D and its processor.  It also means that utility we seek *might* also be a plug-in that converts .R to XX.  I think this is less likely, but wanted to put the possibility out there in case anyone ever stumbles across it.

[gslick]

Does anyone know if the inverse assemblers are executed by some sort of interpreter on the logic analyzers, or directly in native code?

The 1630 series are based on a 6809 CPU while the 16500 series are based on a 68000 series CPU so if the inverse assemblers are executed directly as native code on the logic analyzer CPU the code would obviously have to be different.

If  the inverse assemblers are executed by some sort of interpreter on the logic analyzers the code could be basically the same between the various series of analyzers.

The 16700 series are based on a PA-RISC CPU and can use the same inverse assemblers as the 16500 series.

[MarkL]

I put COPYFILE and I8085 through a 6809 disassembler.  I'm not fluent in 6809 ASM, but COPYFILE makes an amount of sense and I8085 is junk.

So, a reasonable conclusion is that inverse assembler is some kind of bytecode for an interpreter, which had been mentioned before.  Also, since a user can write an inverse assembler, it would be reasonable to expect a layer of isolation between whatever code the user wrote and the innards of the instrument.

So, gslick, do you think we could use a .R to bytecode converter for one of the other LAs?  Do you have a I8085 sitting around for a 16500 to compare against the 163x one?

[gslick]

Do you have a I8085 sitting around for a 16500 to compare against the 163x one?

Attached are images of an original HP 3.5-inch floppy part number 10304-13016 containing an 8085 Inverse Assembler for use with HP 1650A, HP 1651A and HP 16510A.

-Glen

DISK DIRECTORY                                                                 

DOS Filename  Date    Time     Bytes   Description
____________  _______ ________ _______ ________________________________

C8085_I       28Sep87  0:00:00    4352 8085 CONFIG FOR INTERFACE    2_0
C8085_P       28Sep87  0:00:00    3840 8085 CONFIG FOR GP PROBES    2_0
I8085_IP      25Sep87 11:09:35    5120 8085 INVERSE ASSEMBLER       1_0


                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
I8085_IP                1 98X6 #c302       20      256 25-Sep-87 11:09
C8085_I                 1 98X6 #c120       17      256 28-Sep-87 00:00
C8085_P                 1 98X6 #c120       15      256 28-Sep-87 00:00

800768 of 814080 bytes free.

[AndersG]

I get the same error with hpdir v 2.03. Presumably the .hpi files are LIF files. IMD is a different format. You can use that format to put the files onto a diskette. The HPI files seem to be straight LIF files though. Let me put those on an SD card and try reading on my analyser.

[Orange]

I used ImageDisk V1.18 to create the floppy. Use a DD floppy, running DOS (Win98).
Checked on my HP9122C with a HP1630A :-)

The HPdir application V2.03 does not work, and gives the error, even after renaming the files to a shorter one.

[gslick]

I get the same error with hpdir v 2.03. Presumably the .hpi files are LIF files. IMD is a different format. You can use that format to put the files onto a diskette. The HPI files seem to be straight LIF files though. Let me put those on an SD card and try reading on my analyser.

The .IMD files are ImageDisk files created by reading the floppies in a floppy drive directly on a PC.
http://www.classiccmp.org/dunfield/img/index.htm

The first .ZIP file HP1630-10304-10342.zip also contained .HPI files created by reading the floppies in an HP 9121D floppy drive using HPDir -dup

The second .ZIP file 10304-13016.zip also contained a .DSK file created by using IMDU to dump the .IMD file into raw binary sector format. I forget if that .DSK file would be exactly the same as an .HPI file created by reading the floppies in an HP 9121D floppy drive using HPDir -dup, or maybe there are extra spare sector tracks at the end of the floppy which HPDir (or actually the 9121D drive) would ignore. In any case HPDir should also work with the .DSK file.

[gslick]

The HPdir application V2.03 does not work, and gives the error, even after renaming the files to a shorter one.

Hmm, works fine for me...

C:\tmp\16500A-Disks>dir
 Volume in drive C has no label.
 Volume Serial Number is 5ED5-8226

 Directory of C:\tmp\16500A-Disks

05/29/2017  06:35 AM    <DIR>          .
05/29/2017  06:35 AM    <DIR>          ..
12/28/2014  01:24 PM           819,200 10304-13016-SN498.DSK
12/28/2014  01:24 PM            22,126 10304-13016-SN498.IMD
12/28/2014  03:06 PM           158,693 10304-13016-SN498.JPG
05/28/2017  02:10 PM               925 10304-13016-SN498.TXT
05/28/2017  02:11 PM           169,653 10304-13016.zip
               5 File(s)      1,170,597 bytes

C:\tmp\16500A-Disks>copy 10304-13016-SN498.DSK 10304.HPI
        1 file(s) copied.

C:\tmp\16500A-Disks>c:\tmp\hpdir\hpdir -v
2.03 (2009/12/11)

HPDir Copyright (c) 2008 Ansgar Kueckes

This program comes with ABSOLUTELY NO WARRANTY.

This software is free for non-commercial use, and you are welcome to
redistribute it under certain conditions. Type 'HPDir -license' for details.

C:\tmp\16500A-Disks>c:\tmp\hpdir\hpdir -list 10304.HPI
                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
I8085_IP                1 98X6 #c302       20      256 25-Sep-87 11:09
C8085_I                 1 98X6 #c120       17      256 28-Sep-87 00:00
C8085_P                 1 98X6 #c120       15      256 28-Sep-87 00:00

800768 of 814080 bytes free.

C:\tmp\16500A-Disks>c:\tmp\hpdir\hpdir -extract 10304.HPI I8085_IP
record 19 (100%)
C:\tmp\16500A-Disks>dir
 Volume in drive C has no label.
 Volume Serial Number is 5ED5-8226

 Directory of C:\tmp\16500A-Disks

05/29/2017  06:36 AM    <DIR>          .
05/29/2017  06:36 AM    <DIR>          ..
12/28/2014  01:24 PM           819,200 10304-13016-SN498.DSK
12/28/2014  01:24 PM            22,126 10304-13016-SN498.IMD
12/28/2014  03:06 PM           158,693 10304-13016-SN498.JPG
05/28/2017  02:10 PM               925 10304-13016-SN498.TXT
05/28/2017  02:11 PM           169,653 10304-13016.zip
12/28/2014  01:24 PM           819,200 10304.HPI
05/29/2017  06:36 AM             5,120 I8085_IP.#c302
               7 File(s)      1,994,917 bytes

[MarkL]

Do you have a I8085 sitting around for a 16500 to compare against the 163x one?

Attached are images of an original HP 3.5-inch floppy part number 10304-13016 containing an 8085 Inverse Assembler for use with HP 1650A, HP 1651A and HP 16510A.

-Glen

Thanks, Glen.

It looks to me that the inverse assembler I8085_IP on that disk image is in .R format.  This is not surprising, since we know that IALDOWN just passes the .R file to the 1650 for further processing when using RS232 instead of a disk.

Because the same disk covers the 16500, the 16500 therefore uses the same .R format.  I was hoping we might get lucky and it would be more like what the 163x would need.


On the formatting issues that people are encountering with HPdir, I used the linux lifutils from here and it works fine:

  http://www.hpcc.org/datafile/hpil/lif_utils.html

There's another version floating around that's newer, lifutils-1.7.6, but that was having trouble extracting files.

[AndersG]

Indeed, HPDir works just fine if you shorten the filename to 8.3. Copied it to HPDisk and renamed to lifdata.bin and I could load the inverse assembler just fine. I guess there are docs somewhere on how to connect the pods?

[MarkL]

Indeed, HPDir works just fine if you shorten the filename to 8.3. Copied it to HPDisk and renamed to lifdata.bin and I could load the inverse assembler just fine. I guess there are docs somewhere on how to connect the pods?

What model LA did you load it onto?

[Orange]

Indeed, HPDir works just fine if you shorten the filename to 8.3. Copied it to HPDisk and renamed to lifdata.bin and I could load the inverse assembler just fine. I guess there are docs somewhere on how to connect the pods?

I found the bug in HPdir. If you do a -list, HPDir opens the file for writing.
If your file is read-only marked it will give you this error !

 

[AndersG]

What model LA did you load it onto?

HP 1630D, had no way to test further though.

[MarkL]

What model LA did you load it onto?

HP 1630D, had no way to test further though.

Just to be clear about this, did you load the version that Glen just posted for the 1650/16500 (10304-13016), or did you load the one he posted a few days ago for the 1630 (10304-13012)?

If you loaded the one for the 1650/16500, it means the 1630 can read the .R format in addition to XX format.  I wouldn't have expected that to be the case, but I'll take it since it may provide the solution.

[AndersG]

It was 10304-13012.hpi. With 10304-13016-SN498.DSK it lists the files as type "unknown" and refuses to load them.

[jpham]

Is it possible for me to get your 6502 inverse assembler?  I'm in a middle of a debugging
and would be great to use your 6502 inverse assembler

[AndersG]

In what format? Would the 1630 disk image (lif) file work?

[TerraHertz]

You guys might be interested in this list of HP 1630G inverse assemblers I have on HP LIF floppy:
     http://everist.org/NobLog/20190106_hacked_appleII.htm#inv

I'm not yet sure how I'm going to get those files off the old LIF floppies and to a PC. But I'm advised it's not too hard and have been given some advice on how.  We'll see how it goes.

Files list attached. It's a photoshopped collage of several screen photos from my 1630G, running through the disk contents.

[MarkL]

Youu guys might be interested in this list of HP 1630G inverse assemblers I have on HP LIF floppy:
...
I'm not yet sure how I'm going to get those files off the old LIF floppies and to a PC. But I'm advised it's not too hard and have been given some advice on how.  We'll see how it goes.

A great collection!  Bring it on!

Even if you only get so far as a binary image of the entire floppies, I'm sure as a group we would be able to decode the individual LIF entries from there.

[harrimansat]

Is easy to read those discs if you have a Windows based PC with floppy Reader. Please make a image and post it!
Thanks

[TerraHertz]

Please feel free to recommend specific methods of doing so. URLs to utilities known to work, and your experience with them.
I want something that just works, that I don't have to mess with for days/months. Since I have other more urgent projects and don't want to get bogged down in floppy file structure dissection.

I have a good variety of old PC floppy drives, but one slight complication is I only have WinXP machines.

Ideally there's two parts to this. One is to grab an image of the floppy (archived on PC), and be able to duplicate it. So I and anyone else can write fresh copies for the 1630.
Secondly, to get the files extracted on the PC, for examination.  Not so important to me.

[MarkL]

Please feel free to recommend specific methods of doing so. URLs to utilities known to work, and your experience with them.
I want something that just works, that I don't have to mess with for days/months. Since I have other more urgent projects and don't want to get bogged down in floppy file structure dissection.

I have a good variety of old PC floppy drives, but one slight complication is I only have WinXP machines.

Ideally there's two parts to this. One is to grab an image of the floppy (archived on PC), and be able to duplicate it. So I and anyone else can write fresh copies for the 1630.
Secondly, to get the files extracted on the PC, for examination.  Not so important to me.

The biggest problem is the non-standard low-level formats HP used on the floppies, such as a different sector size (256 vs. 512).  It needs a program that knows how to get at the floppy controller hardware either directly or via the BIOS.

I can't say that I've used it (I'm not a windows user), but here's a utility which satisfies your requirement to make an image and then be able to re-create it, for just about any old HP format:

  http://www.hp9845.net/9845/projects/fdio/

There's an excruciating amount of detail on floppy formatting down to the bit level, which makes me believe the author knows what they're talking about.

From a console window, it should be as simple as:

  fdio.exe -dup a: <image_file>

If you can post the images, I will extract the LIF files so that they (hopefully) can be loaded into a 163x series via the GPIB port.  Thanks!

EDIT: Reading more of the README, it does say that for XP you need to install the supplied raw driver, FDRAWCMD.  So it's a little bit more to do, but still pretty simple.

[TerraHertz]

Thanks MarkL. I'll try to get to it this week.
Another method that's been suggested, is a utility that knows how to drive the 9121 dual floppy unit via a GPIB card in the PC. To read/write the disks in natural format. But I don't think I have a PCI GPIB card. Might have.

[gslick]

Please feel free to recommend specific methods of doing so. URLs to utilities known to work, and your experience with them.
I want something that just works, that I don't have to mess with for days/months. Since I have other more urgent projects and don't want to get bogged down in floppy file structure dissection.

I have a good variety of old PC floppy drives, but one slight complication is I only have WinXP machines.

Ideally there's two parts to this. One is to grab an image of the floppy (archived on PC), and be able to duplicate it. So I and anyone else can write fresh copies for the 1630.
Secondly, to get the files extracted on the PC, for examination.  Not so important to me.

If you can get set up to boot a PC to plain real mode DOS one option would be to use ImageDisk to create disk images of the disks. Then the individual files could be extracted from those images, and floppies could be recreated from those images.

Download ImageDisk 1.18 here:
http://www.classiccmp.org/dunfield/img/index.htm

I suppose that might be a pain to set up if your PCs all currently boot Windows. You would probably want to swap in a spare hard drive to be able to boot to plain real mode DOS, and that might be more effort than you want to put into it.

[TerraHertz]

It's going slowly, since I'm focused on that 'get my old Apple II going' part of the project. When the Apple II is running well enough to be worth applying the logic analyzer, then I'll also do what's needed to get the HP 1630 inverse assembler files onto a PC.
The first path I'm going to try, is using a HP-IB card in the PC to drive the HP 9121 unit. There's a utility that can R&W the files directly that way. I'm hoping it also makes it very easy to produce duplicate floppies.

[harrimansat]

  we are waiting!!!! Regards!!!   

[gslick]

I need to get back to the project of trying to figure out the 1630 IA file format. When I last took a look it appeared that the file format was essentially an .R relocatable file as would be output from the 10391 software, that had then been flattened, i.e. the relocations had been applied, and was then wrapped in a simple block structure. The main thing I couldn't figure out at the time was that the blocks appeared to have checksums using an algorithm that I could not determine. I tried using some CRC cracking tools without any luck.

I was thinking I should try hooking a more modern analyzer up to the 6809 CPU of a 1630 while it is loading an IA file and see if I could observe how the firmware was computing and checking the checksums. I haven't gotten around to trying that yet. I did mange to acquire a 1630 extender board which should make it a lot easier to probe the CPU while in operation.

-Glen

[TerraHertz]

   I saw a 1630G on ebay for around $70 a few days ago. If I wasn't currently skint due to paying for that spectrum analyzer and shipping, I'd have bought it as spares for mine.
Then I'd have two. Relevant because, look what else I have with mine. The 6809E emulator pod. (Also a 68000/10 pod. And the manuals!)

Currently cursing because I cannot find the box with a couple of ISA HP-IB cards. I don't have any PCI ones. Do have a Prologix USB-HPIB, and ethernet-HPIB, but suspect they are not going to be useful for this.

[gslick]

look what else I have with my mine. The 6809E emulator pod. (Also a 68000/10 pod. And the manuals!)

Nice. I have two of the 6809/6809E 10308B (64671A) preprocessors. I'll put one to use when I get back to looking at the 1630 analyzers.

[Andy Watson]

The main thing I couldn't figure out at the time was that the blocks appeared to have checksums using an algorithm that I could not determine.

The 1630 data and configuration can be uplaoded or downloaded (as described in the manual). These blocks of data are protected by a two byte crc. If your relocated blocks are protected using the same algorythm - and I would think it highly likely - then the crc is the standard \$x^{16} + x^{15} + x^2 + x^0\$, or 0x8005, the most significant bit being implicit in the method of calculation. The crc algorythm is a standard left-shift through a 16-bit accumulator, however, it is slightly odd in that the crc operation is performed on the lower 8 bits of the register.

[TerraHertz]

I don't suppose anyone has a working PCI slot IEEE-488 bus card (or two) they would sell me very cheaply?
Ideally with drivers that work under WinXP.

[gslick]

The main thing I couldn't figure out at the time was that the blocks appeared to have checksums using an algorithm that I could not determine.

The 1630 data and configuration can be uplaoded or downloaded (as described in the manual). These blocks of data are protected by a two byte crc. If your relocated blocks are protected using the same algorythm - and I would think it highly likely - then the crc is the standard \$x^{16} + x^{15} + x^2 + x^0\$, or 0x8005, the most significant bit being implicit in the method of calculation. The crc algorythm is a standard left-shift through a 16-bit accumulator, however, it is slightly odd in that the crc operation is performed on the lower 8 bits of the register.

Do any of the 1630 manuals explicitly state what CRC algorithm is used? I did look in some of the programming manuals (01630-90915, 01631-90904) and while the sections on learn string commands mention that there are two CRC bytes, I don't remember seeing the actual CRC algorithm mentioned anywhere. I am not doubting that you are correct about the 0x8005 CRC16, I just wonder if the manuals explicitly mention that anywhere.

At the time I was last looking at this I did come across the standard 0x8005 CRC16 somewhere, I forget where. Maybe I was just searching online for common 16-bit CRC algorithms. I tried some online CRC calculators with some sample data and could never get things set up so that the calculated CRC values matched the 1630 values for the sample data. Now I forget if I was trying CRC calculations on learn string data from a 1630, or data from a 1630 IA file, or both.

I should go back and get some learn string data from a 1630 and take another look and see if I can get a CRC calculation to match. Is that something that you have done in the past yourself when uploading and downloading 1630 learn strings?

[Andy Watson]

Do any of the 1630 manuals explicitly state what CRC algorithm is used?

None that I am aware of.

At the time I was last looking at this I did come across the standard 0x8005 CRC16 somewhere, I forget where. Maybe I was just searching online for common 16-bit CRC algorithms. I tried some online CRC calculators with some sample data and could never get things set up so that the calculated CRC values matched the 1630 values for the sample data. Now I forget if I was trying CRC calculations on learn string data from a 1630, or data from a 1630 IA file, or both.

I should go back and get some learn string data from a 1630 and take another look and see if I can get a CRC calculation to match. Is that something that you have done in the past yourself when uploading and downloading 1630 learn strings?

Like you I was looking for the magic runes to communicate with a 1630G. The programming manual gives the format of the "learn string" communication blocks but does not specify the method of computing the checksums. Obviously this allows you to pull data from the machine (and ignore the checksum) but you can't push modified data to the 1630 without knowing how to calculate the checksum. I wrote a small C program to compute CRC checksums and applied it to a block of sample data downloaded from the 1630. I tried all the "standard" 16 bit CRC given on the wiki page but none of them would tally. I tried them forward, backward and inverted, but no luck. Eventually I stumbled across a website that gave the algorythm for computing the crc. I believe the algorythm was obtained by reverse engineering some of the 1630 code, however, I can't find that website now. I have a note that the source of this information was Adam Goldman. It has been more than a year since I last looked at this problem but I think the following code (possibly due to Mr Goldman) does compute the correct CRC checksum:

First we make a table of 256 possible CRC mappings. Note that it is a 16 bit table. You pass-in the generating polynomial - 0x8005.

Code: [Select]

void crc_table_gen(unsigned int poly)
{
    unsigned int reg;
    unsigned int y,z;
   
    for (z=0;z<256;z++) {
       reg = z;
       for (y=0;y<16;y++) {
  reg <<= 1;
  if (reg & 0x10000) reg ^= poly;
  reg &= 0xffff;
       }
       hpcrc_table[z] = reg;
    }
}

Now we use the table  to work through a "buffer" of data:

Code: [Select]

unsigned int hpcrc(unsigned char const *buffer, int len)
{
    unsigned int crc = 0;

    while (len--)
        crc = (crc & 0xff00) ^ hpcrc_table[(crc ^ *buffer++) & 0xff];

    return crc;
}
It's a fiarly standard CRC implmentation except for the fact that it operates on the least significant byte of the shift register. As I said, it's been a while since I tried this. However, I do believe that the above code produced CRC s that concurred with the 1630 checksums.

[gslick]

I'll have to try that code.  Here is some sample data from a 1630 IA file that I was looking at last time:

The first two bytes 0x00FA is the block length, and I assume those bytes would not be included in the checksum.  I believe the next four bytes 0x00003050 is the load address of the data block, and probably included in the checksum, but maybe not. Then I assume the final two bytes 0x0180 is the checksum.

Code: [Select]

0x00,0xfa,0x30,0x50,0x00,0x00,0xe0,0x00,0x02,0x02,0x00,0x00,0x00,0x00,0x02,0x00
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03
0x00,0x00,0xff,0xff,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0x03
0x00,0x3c,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x20,0x20
0x20,0x20,0x20,0x6d,0x65,0x6d,0x77,0x72,0x6d,0x65,0x6d,0x72,0x64,0x6f,0x70,0x66
0x63,0x68,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x69,0x6f,0x20,0x77,0x72
0x69,0x6f,0x20,0x72,0x64,0x69,0x6e,0x74,0x61,0x6b,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20
0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x02,0x02
0x00,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x00,0x00,0x00,0x00
0x01,0x80

[esde]

Hi everyone,
I've mostly reversed the format of the 163x Inverse Assembler binaries.  My notes are somewhat disorganized, but I'll try to pull them together and publish them here in the coming days.

To answer a few questions though:
The XX learn string doesn't use a CRC but rather simple 8 bit sum (the timing and state data learn strings however do use the CRC Andy posted).  gslick, in your example data, yes 0x00fa is the block length, and yes 0x3050 is the load address.  Officially the next two bytes are MSW of the load address, but this doesn't appear to be used and is always 0x0000.  At the end then, 0x01 is the checksum, and the 0x80 is the length in words of the next block.  Yeah, it's a bit goofy and block lengths end up being specified twice.  The sum is accumulated starting with the byte after the word length.  Blocks are word aligned, and it would seem sometimes HP's tools left a junk byte in that position (contrary to their docs).

To maybe make this a little more clear, the XX learn string is formatted as follows:
u8[2] "XX"
u16 length of string in bytes (including 4 trailing nulls)
{ n Blocks }
u8[4] 0x00 0x00 0x00 0x00

and a Block consists of:
u8 length of block in words
{ HP Absolute File record }
u8 checksum

The XX command itself is used for loading and executing 6809 code on the instrument, not specifically Inverse Assemblers.  I believe this was probably intended for development internal to HP and was later used to support the Inverse Assembler feature.  The IA binaries do have a little chunk of 6809 code at the start which prods some internal state and gets the byte code interpreter going.

The format of an Absolute File is described in Chapter 6 of the "HP 64000 File Format Reference Manual" available from here:
http://bitsavers.trailing-edge.com/pdf/hp/64000/software/64980-90933_Jul-1986.pdf
(Chapter 5 also contains a relatively detailed description of the Relocatable format)

[gslick]

To answer a few questions though:
The XX learn string doesn't use a CRC but rather simple 8 bit sum (the timing and state data learn strings however do use the CRC Andy posted).  gslick, in your example data, yes 0x00fa is the block length, and yes 0x3050 is the load address.  Officially the next two bytes are MSW of the load address, but this doesn't appear to be used and is always 0x0000.  At the end then, 0x01 is the checksum, and the 0x80 is the length in words of the next block.  Yeah, it's a bit goofy and block lengths end up being specified twice.  The sum is accumulated starting with the byte after the word length.  Blocks are word aligned, and it would seem sometimes HP's tools left a junk byte in that position (contrary to their docs).

Oh, now that you told me how the 1630 IA on disk block format works that part looks obvious. I haven't tried to fully understand the initial part of the IA on disk file format. More information on that would be useful.

The format of an Absolute File is described in Chapter 6 of the "HP 64000 File Format Reference Manual" available from here:
http://bitsavers.trailing-edge.com/pdf/hp/64000/software/64980-90933_Jul-1986.pdf
(Chapter 5 also contains a relatively detailed description of the Relocatable format)

I already found that documentation earlier, probably someone else on the forum in a different thread pointed to that and it was helpful. I was able to learn enough about the relocatable file format to be able to take a .R file as output by the 10391B tool and convert it back into equivalent .S source code that would then compile back into an identical .R file. The code I have for that is ugly. I need to make some attempt to clean it up while I still remember how it works and make it available to share.

From what I could tell from taking a quick look the 1630 IA file format it appears to be what you would get if you took a .R file as output by the 10391B tool, applied the relocations to flatten everything into the program, data, and common segments, then added a header section, and wrapped the segment data with the block record headers and trailers. Is that basically correct as far as you understand things?

-Glen

Earlier thread about the 1650/16500 family analyzer IA files here:
https://www.eevblog.com/forum/testgear/hp-logic-analyzer-inverse-assemblers/msg1567966/#msg1567966

[esde]

From what I could tell from taking a quick look the 1630 IA file format it appears to be what you would get if you took a .R file as output by the 10391B tool, applied the relocations to flatten everything into the program, data, and common segments, then added a header section, and wrapped the segment data with the block record headers and trailers. Is that basically correct as far as you understand things?

Yes that's correct.  It ends up being not terribly complicated: Iterate through the relocatable's records and copy the contents to the appropriate segment and update the corresponding segment counter.  The only actual symbol relocation I've encountered so far (type 3) drops an absolute offset (including load address) to a given segment.  I've been using the 8085 sources that came along with the 10391B kit, and it's .R object only has four such relocations.

The segment names differ from those in the FFRM:  PROG is for IA variables, DATA is the byte code, and COMN is constants.  Those three segments are concatenated together in that order, and overlaid by the ABS segment (a bit uncertain about that last bit).

I also have some ugly code to do this flattening, and will try to polish it at some point.

Two other components make up the IA binary though.  As mentioned previously, they start with a machine code loader.  The next block is a probe config and label block.  Some uncertainty there- I have it worked out for D (and A?) suffix units.  You'll notice that it sort of repeats itself, and I think the second version is for G suffix units.  Then comes the flattened object data.  Loader code is always loaded to 0x3000, probe config to 0x3050 and IA byte code to 0x3500.

As for the on disk format- I'm not sure, as I've done all the work via GPIB.  Looking at I8085IPi (from the 10304-13012 floppy) it looks like the first 36 bytes are disk header.  Then starts the actual learn string.  I'm fairly certain the disk subsystem just reads sectors and passes them off to the same code that handles GPIB data.  Looks like 0x0020 - header length, 0xFF05 - file type, 0x5858 - ? part of file name?, 28 bytes file name, and then 0x0828 - string length.  At the end the 0xffff is probably some kind of end of file marker.  It is not (necessary to be) transmitted over GPIB.

Let me know if you do get set up with that extender board and another logic analyzer.  I think I could come up with some questions to ask.

Attached is a log from my relocation tool which is maybe useful (unix line endings, some ansi colors)

[esde]

This is the first release of my tools for building 163x compatible inverse assemblers from the output of the 10391B development package.  Included are tools to flatten .R relocatables, convert raw binaries to HP Absolute format, and to wrap Absolute files in XX learn string blocking and disc headers.  Also included are three examples of how to generate bit exact copies of IAs distributed by HP.  I have not yet attempted to create original IAs with these tools, but it should be possible to some degree.  At least enough is known to start experimenting.  Some of the code isn't terribly nice (or well documented), be gentle 

Some further work is needed to verify the probe configuration block, especially for G suffix instruments, and to understand what exactly the machine code loaders do.  Thanks to everyone in this thread for their work in collecting and archiving these Inverse Assemblers!

[mmcgraw74]

I received several HP Inverse Assembler Modules plus an HP 10269B General Purpose Probe Interface, along with HP mini tape cassettes with the Inverse Assembler files for HP 1630 logic analyzers.

I purchased an HP 82161A HP-IL Cassette Drive and a couple of HP-IL cables on EBAY, and was able to load a 6800 Inverse Assembler into my HP 1630A.

I also purchased a "PIL Box" http://www.jeffcalc.hp41.eu/hpil/#pilbox and hooked it up today to try to capture the Inverse Assembler files.

I used the ilPer program to 'scope' the HP-IL messages, while doing a tape file copy.

I could easily see that the file data was continous DAB xx hex output, so used Notepad++ to edit out everything but the Hex characters, then used a HEX to Binary file conversion online tool to create the binary files.  I then checked each of those binary files with HxD and they appear to be IA program files.

I haven't figured out how to get my PC to use the PIL Box to emulate a tape - instead of the HP 82161A cassette drive, nor figured out how to put these files into a format to use with the PIL box, but I'll do some more experiments.

Here is a link to my zip of the IA files that I believe will work with HP 1630 series logic analyzers.  I have only loaded the 6800 file from tape but not used it yet.

https://drive.google.com/file/d/1ZoUKhpLj2oXJhCoTtjJ7GOhBDb72Qc9t/view?usp=sharing

[mmcgraw74]

Ok, I think I'm learning something about the file format for HP 1630 Logic Analyzer "Tape" peripherals - including not only the HP-IL 82161A cassette drive but also the HP-IL 9114b disk drive.

Neither the cassette drive nor the HP-IL floppy drive have file systems - the file systems were accomplished on the HP-IL "controller", either an HP 41/71 calculator or in our case the HP 1630A/D/G Logic Analyzer.  This format is not the same as the GPIB disk drive!

The HP 1630 has a "Tape" screen that appears when either an HP-IL cassette drive or 9114b disk drive is connected.  A completely different peripheral screen for "Storage" appears with an HP GPIB disk drive.

In addition - the HP 1630 only supports a single "Tape" device, and the COPYFILE command on the HP Inverse Assembler mini data cassettes only allows copying to another mini data cassette.  I imagine the same restriction for the 9114b diskettes - which can be emulated with a PIL Box.

My findings are based with experiments using the PIL-Box.

The ilPerf application for the PIL-Box supports two disk drives and a printer interface.  I haven't tried the printer interface yet.  I do know the HP 1630 only appears to support a single 9114b floppy disk - as a tape drive.

I can use the HP 1630 "Tape" menu to format either a mini data cassette, or a 9114b floppy disk based on whether I've plugged in the cassette drive or PIL-Box before navigating to the Tape menu.

With the cassette drive plugged in - using the COPYFILE command from an IA cassette, you can copy any file including COPYFILE to the same tape or a different tape.

However - in both the cassette and floppy cases - only ten files are displayed, with configurable file names.

When you use COPYFILE, that utility will copy the entire file name - and if the file was marked write-protected (* on first character of filename), the copy will also be marked write protected with the same full name.

In addition, because HP-IL has automatic device IDs - the HP 82161A MUST be the first device in the loop.  I don't have the HP-IL Thinkjet printer to experiment, but it would likely be the second device.
In my experiments using the PIL Box to analyze the HP-IL traffic - the PIL Box is plugged in 'downstream' of the 82161A cassette drive. 

HP-IL is differential serial with IN and OUT ports.  The controller sends commands on the OUT port, each device is enumerated based on location from the controller, and sends responses on their OUT ports to the next device.  Therefore any device on the loop is able to get their command and must resend IN port traffic that is not addressed to them to their OUT port.

Because HP-IL was designed to work with the HP-41 and HP-71 calculators, the HP-IL command set is very primitive - see the HP 82161A Cassette Drive Owners Manual for the commands.

What I have found on my HP 1630A logic analyzer connected to the PIL Box on HP-IL, is there are only 11 files created by the 1630 format command - whether it is the cassette or 9114b floppy disk.

Those 11 files are named: FILE0 through FILE9 and then FILEX.

When I do a lifdir command on the PIL Box emulated floppy disk file - it looks like this:

Code: [Select]

J:\>lifdir "hp9114b-config1-3 -4.dat"
Volume : HP1630
Tracks: 80 Surfaces: 2 Blocks/Track: 16 Total size: 2560 Blocks, 655360 Bytes
FILE0       ?(FFFE)     12800/12800    28/07/13 08:31:40
FILE1       ?(FFFE)     12800/12800    28/07/13 08:31:40
FILE2       ?(FFFE)     12800/12800    28/07/13 08:31:40
FILE3       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE4       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE5       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE6       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE7       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE8       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILE9       ?(FFFE)     12800/12800    28/07/13 08:31:41
FILEX       ?(FFFE)       512/512      28/07/13 08:31:41
11 files (16 max), last block used: 257 of 2560

Note the volume name is HP1630 - if the logic analyzer sees a different volume name, it does not support reading or writing any file - including it will not reformat that tape or disk.

I have experimented with formatting the emulated 9114b floppy disk, then writing the current 1630 configuration to different file locations.

From these experiments, I have concluded the following:

• The HP1630 9114b HP-IL diskette format is unique
• The current LIF utilities only appear to understand showing the directory and lifget can extract a file.
• The current LIF utilities do not understand that FILEX in this format contains the directory information including filenames.
• gslick's HP 1630 IA diskette HPI files do not work as HP-IL 9114b image files with the HP 1630.

I have file captures of formatting an emulated 9114b floppy disk with the PIL Box, and captures of writing one more configuration file.

But I don't have any experience with the low-level HP-IL commands, so I don't know how to extract a file from gslick's 1630 disk images and insert it as one of the 9114b files with the filename inserted into the FILEX file.

Here is the contents of FILEX displayed with HxD after writing the HP 1630 default configuration into the first file, 3rd file and 8th file with names: CONFIG1, CONFIG3 and CONFIG8.  I believe FILE0 on the cassette is the output of the first file.

Code: [Select]

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  46 49 4C 45 58 20 20 20 20 20 FF FE 00 00 01 00  FILEX     ÿþ....
00000010  00 00 00 02 13 07 28 08 31 41 80 01 00 00 00 00  ......(.1A€.....
00000020  00 06 48 50 31 36 33 30 01 F4 43 4F 4E 46 49 47  ..HP1630.ôCONFIG
00000030  31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20  1               
00000040  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
00000050  20 20 20 20 20 20 20 00 06 28 08 40 00 00 00 00         ..(.@....
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 4F  ..............CO
00000090  4E 46 49 47 33 20 20 20 20 20 20 20 20 20 20 20  NFIG3           
000000A0  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
000000B0  20 20 20 20 20 20 20 20 20 20 20 00 06 28 08 43             ..(.C
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000180  00 00 00 00 00 00 00 00 43 4F 4E 46 49 47 38 20  ........CONFIG8
00000190  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
000001A0  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
000001B0  20 20 20 20 20 00 06 28 08 47 00 00 00 00 00 00       ..(.G......
000001C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF  ..............ÿÿ

[mmcgraw74]

Bottom line:

I believe all HP 1630A/D/G logic analyzer users wanting to use Inverse Assembler files will be able to use a PIL-BOX on HP-IL if we find a way to create a floppy disk image including all the files I have recovered from my HP mini data cassettes.

You will also be able to save configurations to the emulated 9114b floppy disk.

[harrimansat]

Hi,

Try to crop files to begin with XX charts, then send it through GPIB to logic analyzer.

Regards

 

[mmcgraw74]

Hi,

Try to crop files to begin with XX charts, then send it through GPIB to logic analyzer.

Regards

Thanks for the 6800 IA file post!  It looks like the 6800 IA file I recovered - although your file has an extra "XX" at the beginning that is not present on my file.

I have a National Instruments USB to GPIB interface - but that model is not supported with the hpdrive program, so I don't have a way to use GPIB to load an IA file, since I don't have a GPIB floppy drive.

I can't tell if there is any checksum in the HP-IL tape files.  If not, I may just try to hack one of my captured IA files into the HPI floppy image and put the IA file name into the FILEX file - with an asterisk and see what happens.

[harrimansat]

Is your 6800 recovered! Check this other working IA file. I can send it to logic analyzer through gpib.
Regards!

[MarkL]

Hi,

Try to crop files to begin with XX charts, then send it through GPIB to logic analyzer.

Regards

Out of curiosity, I tried cropped versions of the files on a 1631D from mmcgraw74's google drive post above, "HP_1630_IA_tape_files".

The first two bytes before the "XX" appear to be a length which includes some pad bytes at the end.  However, the two bytes after the "XX" is another embedded length (as per esde's post above), which doesn't include the pad bytes.  Cropping to the first length can cause "Error in controller command" from the extra pad bytes.  Cropping to the second length seems to work.

The following two complained about "Second Timing Board Required", but that makes sense since the 1631D only has 43 digital channels:

  68000_IA_for_Probes_Rev2311.BIN
  8086_IA_Rev2309.BIN

Loading COPYFILE.BIN doesn't do anything.  Presumably some other action is needed to get it started.  But it's not really needed in this case anyway.

The files were sent to the 1631D through the GPIB connection, the same as you would any other command.  As a test, changing a random byte in the files caused a CRC error to be displayed when loaded, so the files are seemingly intact.

I didn't do any testing of the IA itself.

If anyone wants to play further with the cropped versions of the files, they are attached below.


EDIT: Fixed credit for XX length field.

[mmcgraw74]

I believe the HP 1630 tape file is slightly different than the GPIB file.  Certainly the "Header" is different.

I found an interesting article on HP-IL tape file format - that is closer to what I see on the HP 1630 tape files than the GPIB LIF file format:

https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=24

In particular, when I use the lifget.exe program to extract a file from the PIL-BOX tape emulation file - it says the FFFE is an unknown format.  I'll be that is the HP 1630 format number.

my FILEX directory files are a bit longer than 32 bytes, though.

I'll try to poke one of the tape IA files into the PIL-BOX tape emulation files this weekend and see what happens.

[MarkL]

I believe the HP 1630 tape file is slightly different than the GPIB file.  Certainly the "Header" is different.
...

Yes, the formats are different.  There's clearly another layer of encapsulation in the tape files.

What I'm after is the yummy insides of any of these files, which is the data starting with the XX to the end of that data as indicated by the length field (immediately following the XX).  That long binary string is the actual inverse assembler and can be pushed directly from the PC to the analyzer via the GPIB port in the same way as a "learn string".  There's no tape, disk, or other peripheral emulation needed.

If I understand, I think you're trying to take a more indirect route of emulating a tape drive on HP-IL, putting the files in the emulator in the right format, and letting the analyzer initiate the load.

[mmcgraw74]

I believe the HP 1630 tape file is slightly different than the GPIB file.  Certainly the "Header" is different.
...

Yes, the formats are different.  There's clearly another layer of encapsulation in the tape files.

What I'm after is the yummy insides of any of these files, which is the data starting with the XX to the end of that data as indicated by the length field (immediately following the XX).  That long binary string is the actual inverse assembler and can be pushed directly from the PC to the analyzer via the GPIB port in the same way as a "learn string".  There's no tape, disk, or other peripheral emulation needed.

If I understand, I think you're trying to take a more indirect route of emulating a tape drive on HP-IL, putting the files in the emulator in the right format, and letting the analyzer initiate the load.

Yes, I have a National Instruments USB to GPIB adapter that I have used to capture the print output from my HP 1630A, but it does not work with the HPDISK software (unsupported) as a GPIB drive emulator.  My 1630A ROMs only support HP-IL tape as a storage device to save configurations or load IA files.

The PIL-BOX ilper utility is able to emulate an HP-IL tape drive, but the HP 1630A only supports one tape drive at a time - and the IA tape COPYFILE utility only copies files to other tapes on the same tape drive.

So I have captured (with the PIL-BOX 'scope') each of the IA file contents during a copy of the entire IA file to another tape.  Those IA file captures are on my zip file - edited from the PIL-BOX captures and converted from ASCII Hex characters to binary data files. 

Since each of those file captures includes the entire file including the header - I'm hoping to just use the lifput utility to poke those files into the PIL-BOX LIF contents of an emulated tape, along with editing in the filename into the FILEX directory file - and see if I can use the result in my HP 1630A.

If it works - I think anyone with the 1630A or 1630D with the "tape" ROMs will be able to use a PIL-BOX to load their IA files, instead of having to buy (and possibly fix) an HP GPIB floppy drive AND upgrade their ROMs to the GPIB storage version.

[MarkL]

Yes, I have a National Instruments USB to GPIB adapter that I have used to capture the print output from my HP 1630A, but it does not work with the HPDISK software (unsupported) as a GPIB drive emulator.  My 1630A ROMs only support HP-IL tape as a storage device to save configurations or load IA files.
...

You can load IAs and save/restore configurations via the GPIB port, provided the 1630A's dip switches are set for external GPIB controller (positions 7 8 set to 0 1),   And *without* HPDISK or other emulation.  In this mode the 1630A is just another GPIB instrument which can accept and reply to GPIB commands.  For example, the "ID" command will return the string "HP1630A".

The undocumented "XX" command loads IAs is just like any other GPIB command.  "TC" (transmit configuration) returns the configuration of the unit.  And "RC" (receive configuration) loads a configuration (as was returned by TC).

Perhaps you already know all this and you're just interested in getting HP-IL storage working.  If so, my apologies.  If not, the operations you want can be done without the additional, and complicated, layer of storage emulation.

[mmcgraw74]

Yes, I have a National Instruments USB to GPIB adapter that I have used to capture the print output from my HP 1630A, but it does not work with the HPDISK software (unsupported) as a GPIB drive emulator.  My 1630A ROMs only support HP-IL tape as a storage device to save configurations or load IA files.
...

You can load IAs and save/restore configurations via the GPIB port, provided the 1630A's dip switches are set for external GPIB controller (positions 7 8 set to 0 1),   And *without* HPDISK or other emulation.  In this mode the 1630A is just another GPIB instrument which can accept and reply to GPIB commands.  For example, the "ID" command will return the string "HP1630A".

The undocumented "XX" command loads IAs is just like any other GPIB command.  "TC" (transmit configuration) returns the configuration of the unit.  And "RC" (receive configuration) loads a configuration (as was returned by TC).

Perhaps you already know all this and you're just interested in getting HP-IL storage working.  If so, my apologies.  If not, the operations you want can be done without the additional, and complicated, layer of storage emulation.

Thanks for the tip.

I've just started using the National Instrument USB to GPIB adapter with a simple capture utility. 

I haven't experimented with the utilities - or tried to change my 1630A to use an external controller.

I think I'll try that command.

Thanks!

[MarkMLl]

I'm an utter noob here, both to this forum and to HP analyzers (I'm a Tek refugee), but I wonder if I could ask a question.

This manual from Natsemi http://bitsavers.trailing-edge.com/components/national/_appNotes/AN-0688.pdf specifically mentions the "HP 10391A Inverse Assembler Development Package", i.e. complete with the -A suffix rather than identifying it by an unqualified number.

I find myself wondering whether that indicates that the -A and -B variants of the software existed simultaneously, and whether the -A variant explicitly supported the 1630 as well as the 1650 while the -B was the one that was used for the 1650 and later instruments.

Mark Morgan Lloyd

[MarkL]

I'm an utter noob here, both to this forum and to HP analyzers (I'm a Tek refugee), but I wonder if I could ask a question.

This manual from Natsemi http://bitsavers.trailing-edge.com/components/national/_appNotes/AN-0688.pdf specifically mentions the "HP 10391A Inverse Assembler Development Package", i.e. complete with the -A suffix rather than identifying it by an unqualified number.

I find myself wondering whether that indicates that the -A and -B variants of the software existed simultaneously, and whether the -A variant explicitly supported the 1630 as well as the 1650 while the -B was the one that was used for the 1650 and later instruments.

Mark Morgan Lloyd

That datasheet only refers to the 165x and 165xx analyzers, so their reference to 10391A I would expect is also limited to those models.

You've piqued my curiosity on this again, and I was able to find the first mention of the 10391A in the 1988 HP catalog.  Below is what it has to say.  There's no mention of compatibility with the 163x series even though the 163x is included in the same section.

I'll put forth again my unsubstantiated theory that the IA development package for the 163x series was only used internally at HP, and also probably at HP developer partners.

Further diligent digging by users in this thread have finally worked out a method to produce IAs for the 163x, without access to the original package, whatever it was called.

Trove of catalogs here:

  http://hparchive.com/hp_catalogs

[MarkMLl]

That datasheet only refers to the 165x and 165xx analyzers, so their reference to 10391A I would expect is also limited to those models.

Agreed, but the -B suffix is also described as being applicable to the 165x and later. I presume that the -A was in effect the older 10391 (no suffix).

You've piqued my curiosity on this again, and I was able to find the first mention of the 10391A in the 1988 HP catalog.  Below is what it has to say.  There's no mention of compatibility with the 163x series even though the 163x is included in the same section.

Yes, I've also found the same text in the 1990 catalogue.

I'll put forth again my unsubstantiated theory that the IA development package for the 163x series was only used internally at HP, and also probably at HP developer partners.

Which might possibly include Natsemi.

Further diligent digging by users in this thread have finally worked out a method to produce IAs for the 163x, without access to the original package, whatever it was called.

Which I'm very much looking forward to playing with.

Trove of catalogs here:

  http://hparchive.com/hp_catalogs

I've also found this today http://bitsavers.trailing-edge.com/bits/HP/1650/hp_1650/dos_utils.tar.gz which contains a 1650 access program written in Pascal.

MarkMLl

[garrettm]

For anyone who is still interested in acquiring inverse assembler files for the HP 1630 and 1631 logic analyzers, I have extracted the contents of two inv. asm disks that came with my HP 8175A for the 1630G and 1631D LAs.

The files have been converted from LIF to DOS format using the hpdir tool provided by hp9845.net.

Code: [Select]

I8088Ii
I8086Ii
I80286Ii
I80188Ii
I80188IEi
I80186Ii
I80186IEi
I6809Pi
I6809Ii
I6809Ic
I6809EPi
I6800Pi
I6800Ii
I68008Pi
I68008Ii
I68000P8i
I68000P3i
I68000I8i
I68000I3i
The original disks have been archived in the following thread:

https://www.eevblog.com/forum/general-computing/archiving-lif-formatted-3-5-inch-disk/msg4039306/#msg4039306

[MarkMLl]

Thanks for that. I was trying to work through the documentation for connecting a 1630 to an 8088 (actually a V20) a few days ago and without some form of detail about how the instrument channels were mapped to the target it was... hard work.

MarkMLl

[gslick]

I made a quick pass at unassembling the inverse assembler files posted in the "HP163xx Logic Analyzer Inv ASM.zip" collection above.

Attached below is what I got. I haven't tried feeding these source files back through 10391B yet to double check that it would produce identical inverse assembler binary results.

I68000I3i.S
I68000I8i.S
I68000P3i.S
I68000P8i.S
I68008Ii.S
I68008Pi.S
I6800Ii.S
I6800Pi.S
I6809EPi.S
I6809Ii.S
I6809Pi.S
I80186IEi.S
I80186Ii.S
I80188IEi.S
I80188Ii.S
I80286Ii.S
I8086Ii.S
I8088Ii.S