Searching for a HP 1630 HP 1631 inverse assembler files.

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