HP Logic Analyzer Inverse Assemblers

[TimInCanada]

What is an Inverse Assembler (IA), and why would I want one?

If you are using a logic analyzer to watch the address and data buses of a microprocessor, values on the data bus represent the CPU's opcodes and operands which are the addresses and data moving to/from the CPU and I/O and memory.  An inverse assembler is a kind of disassembler that translates bus data into the CPU's assembly language.  It is a piece of software that has to be installed on the analyzer before use.

Modern microprocessors include features such as JTAG for debugging, but vintage microprocessors don't.  A logic analyzer with an IA makes it much easier to reverse engineer or debug an old microcomputer.  It doesn't give you the assembly language source of the program, but instead shows the stream of instructions that are executed and the data they operate on.

As part of the HP 64000 Logic Development System launched in 1979, an "inverse assembler language", IAL, was created and has been used by HP logic analyzers since. An IAL source file has a .S extension.  It is assembled into a .R relocatable file which is formatted for and installed on particular analyzers. 

Operation

A separate IA is required for each microprocessor.  They only operate in the Listing view of State analysis, and just decode the data on the current screen rather than all the acquired data.  The operating manual for each logic analyzer gives the details of how to install an IA.  To use it, the analyzer is connected to the address, data and status buses of the CPU and in the Format menu are given the labels ADDR, DATA, and STAT, respectively.  The IA needs to provide information on how the status lines are to be connected  This is usually in a configuration.txt file.

Once data is acquired, in the Listing view under the label DATA there is a base selector which normally defaults to Hex.   Select the field labeled "Invasm" and the inverse assembler will be activated.

Automatic/Manual Code Detection: Some processors, such as the 6502 and 8085, have status lines which indicate when a byte fetched from memory is code rather than data.  The IA reads the status lines and automatically determines which lines on the display are code.

For other processors, the IA needs to be manually synchronized.  When an IA  that needs manual syncing is loaded there should be a "Invasm" Field displayed on the Listing page.   Scroll the listing up or down until a known code instruction is in the top line,  then select the "Invasm" field.  The IA will start decoding that line as an opcode.  The listing can be scrolled down and the IA will stay in sync, but it will not stay synced when scrolling up.

Naming Conventions

Some of the software that deals with IA files require file names to be 10 characters or less, starting with an upper case letter, letters or numbers or underscore characters only.

The general convention is:

• First letter of "I" means it is the IA file.
• First letter of "C" means it is a configuration file.
• Last letter of "P" means the IA file is for use with general purpose probing (e.g., flying leads).
• Last letter of "I" means the IA file is for use with dedicated hardware interfaces (often called "preprocessors").

Inverse Assemblers by Processor:

• invasm_v3.zip contains inverse assemblers for the
  
  • 6800, 6809
  • 68000, 68008, 68010, 68020
  • 8085, 8086, 8088
  • 80186, 80188, 80286, 80386
  • NSC800
  • Z80 
  In addition to the configuration and IA files, there are relocatable *.R and Invasm Field Option *.info files. (Big thanks to MarkL  )
• INVASM_SRC.zip contains the decompiled source code for the above IAs.  (Big thanks to gslick  )
• Details on Z80 STAT bus connections
• 6502 (includes .S and .R files)
• 8008 (includes .S and .R files)
• 10342B_IA.zip contains IAs for the 10342B HPIB, RS-232, RS-449 bus decoder probe.  (Big thanks to gslick  )

Logic Analyzer Notes:

1611A
This is more for historic interest.  The 1611A Logic State Analyzer was described in the January 1977 HP Journal.  It used "personality modules" for each microprocessor that included an IA in ROM.

1630/31

• A discussion on using IAs on these analyzers.
• Formatted IAs for the 6809, 68000, HPIB, RS232 and RS422.
• Introducing the HP1631D
• Another discussion about getting IAs onto the 1630.

1650/16500/1660/1670

• IA files for each of these is compatible with the other models.
• Z80 (ImageMagic disk image for 1650)
• Some 1650 software utilities including some Pascal source code (may work with other analyzers too).
• HP1652B Inverse Assembler
• HP16500B Experiences

16600/16700

• Loading preformatted IA files:
• Copy the IA file into a temporary directory. (Don't forget to set public read permission on the file.)
• Use the File Manager to load the IA file you just put on the analyzer.
• The File Manager does necessary formatting and puts its IA file into the  /logic/ia directory.
• From the Listing screen, select Invasm then Load...
• If the above doesn't work,
  
  • Copy a IA relocatable .R version of the file onto the analyzer.
  • Use the  IA Format Utility to convert the file and load it into the /logic/ia directory.
  • From the Listing screen, select Invasm then Load...

1680/1690/16900

• The relocatable .R files don't work directly on these analyzers, and involves creating a .DLL wrapper around them.

Getting IAs onto an analyzer:

• Older analyzers with floppy drives often used the HP LIF format for the floppies.  The HPDir software can create LIF format floppies on a Windows PC.
• There are also LIF Utilities for linux.
• Some IA files turn up in ImageDisk .IMD format.
• The HPDrive software can emulate an external disk drive, but this requires a PC with a GPIB interface card.
• The IALDOWN utility in the IAL development package transmits IA files to an analyzer over RS232.  It must be run in DOSBOX with the serial port configured.

Symbol Names

In addition to the IA, a handy tool when working with microprocessors is to create a Symbol Table of known addresses, such as memory-mapped I/O units and variables.  See your analyzer operating manual for specific details of creating a symbol table.

In the Listing display under the label ADDR there is a selection for the base (format) to display addresses in.  The default is usually "Hex".  Change this to  "symbol" and any addresses that are in the symbol table will have their names substituted in the listing.  If a Symbol Table is loaded, the IA will also use these address names in its output.

Source Code Viewer

The 16700 analyzers have the B4620B Software Correlation Tool option.  The analyzer comes with the tool installed, but needs a license to use.  Fortunately, the license file is available for non-commercial use (along with licenses for the other options).

Normally, source code would be compiled with a debug option and after capturing data with the analyzer the source code could be stepped through in the Source viewer while the corresponding line is highlighted in the Listing viewer, and vice-versa.  When reverse engineering old uPs, it is unlikely the source code is available.  However, the Source viewer can still be useful if the uP's code is disassembled into a listing file that gives the addresses of each line of code.  (If a disassembler doesn't create such a listing file, an assembler can be used to re-assemble the disassembled code and generate the listing file.)

The 16700 Help Volume, page 197 gives the General-Purpose ASCII (GPA) Symbol File Format.  The symbol file is just a text file that is placed somewhere on the analyzer's drive and loaded from a Symbols tab. 

Here is an example.  Suppose a piece of assembly code in a listing file called test.lst is:

Code: [Select]

dc19 : b701d0            staa CmdTableIndex
dc1c : 86ee              ldaa #$EE
dc1e : b101d0            cmpa CmdTableIndex
dc21 : 2609              bne LDFAA ; branch if valid CmdChar
dc23 : bdd6c0            jsr subResetCmdFlags
dc26 : 7ee3a0            jmp LE768 ; set flagCmdParse bit6 and rts

The first column is the start address of each line of code.  The symbol file is given a [SOURCE LINES] section, e.g. for this piece of code:

Code: [Select]

[SOURCE LINES]
File: test.lst
...
9029 dc19
9030 dc1c
9031 dc1e
9032 dc21
9033 dc23
9034 dc26
...
The file test.lst is placed in the analyzer's /logic/source/ directory.  The first column is the decimal line number in the source file and the second column is the hexadecimal address.  (A spreadsheet can be used to manually extract the address values and add line numbers, for example.)  The symbol file is loaded in the normal way.   When run to this code, the Listing view will display (at address dc1e):


From the Listing view, on the menu bar at the top of the screen select Source/Open Source Viewer...  The viewer displays the source file and highlights the corresponding source line:


The program execution can be stepped forward and backward and the captured data can be searched to see if particular lines of source were executed.  The listing view shows data values that were passed, for instance, the CMPA (6800 Compare Accumulator A opcode) shows the value 07 was read from memory as the value of variable CmdTableIndex.  In addition, analyzer trigger points can be set at particular lines of the source, similar to breakpoints in emulators and debuggers.  The Listing Display Tool Help Volume pages 24-39 gives details.


Writing an Inverse Assembler

If you wish to write your own IA, the HP 10391B IAL Development Package includes sample source files for the 8085 and 68010 and an assembler to convert the .S source files into .R files for the analyzers.  This software needs to run on a DOS computer or in DOSBOX.  A hint on setting up this assembler.

If anyone has additional files, they can be posted as attachments and links can be added here, too.

Thanks!

Tim

[gslick]

Been looking for an inverse assembler for the MC6800.  Haven't found one yet, but thought it might be worthwhile to summarize what is available.

The file "invasm.zip" is available in the files section of the "HP/Agilent Test Equipment" Yahoo group if you search for it there in the files section. It is a restricted group and you have to join the group first to access the files section.

https://groups.yahoo.com/neo/groups/hp_agilent_equipment/info
https://groups.yahoo.com/neo/groups/hp_agilent_equipment/files

The file is small enough that I can attach it here. It contains the following set of configuration and inverse assembler files.

c68000_i
c68000_p
c68008_i
c68008_p
c6800_i
c6800_p
c68010_i
c68010_p
c68020_i.p
c6809e_p
c6809_i
c6809_p
c80186e_.i
c80186_i
c80188e_.i
c80188_i
c80286_i
c80386_8.7
c80386_i
c8085_i
c8085_p
c8086_i
c8088_i
cnsc800_.i
cz80_i

i68000_i
i68000_p
i68008_i
i68008_p
i6800_i
i6800_p
i68010_i
i68010_p
i68020_i.p
i6809e_p
i6809_i
i6809_p
i80186e_.i
i80186_i
i80188e_.i
i80188_i
i80286_i
i80386_8.7
i80386_i
i8085_ip
i8086_i
i8088_i
insc800_.i
iz80_i

In the particular case of the 6800 / 6802 CPU the 64672A 10307B preprocessor interface contains a non-trivial state machine that does some decoding of the instruction stream as it is executed to provide addition state information that is not available with the general purpose probe version of the configuration and inverse assembler.

[gslick]

When the c6800_p 6800 general purpose probe configuration file is loaded into a 16510A analyzer module the configuration is as shown in the attached screen captures.

[MarkL]

Great summary, Tim, thanks!

I'll add to the party with another zip archive.  gslick, in a different conversation, gave me enough information (thanks, gslick!) that I was able to write a text decoder for the configuration files he just posted in invasm.zip.  Attached here is invasm_configtxt.zip, which is the same as invasm.zip, but includes the text version of the config files (plus the C program that did the decoding).

In the zip file, for processor XXX:

  iXXXp - inverse assember for general (flying lead) probing
  cXXXp - 16510 configuration for general (flying lead) probing
  cXXXp.txt - text 16510 configuration for general (flying lead) probing

  iXXXi - inverse assember for pre-processors
  cXXXi - 16510 configuration for pre-processors
  cXXXi.txt - text 16510 configuration for pre-processors

The significance of having a readable form of the config files is that you now have a fighting chance to use the inverse assemblers on something other than a 16510 card.

For example, I have a 16702B with a 16752A card and I've been successful using it on a 6802 processor.  I can successfully load i6800_p, the inverse assembler for general purpose (flying lead) probes.  No problem there.  However, the IA wants to interpret the bits in the label STAT to determine what machine cycle to display.  The STAT signal assignments are contained in the companion configuration file, c6800_p.  If I had a 16510 it would be easy.

The decoded text of the configuration says:

  Title: 6800/02 CONFIG FOR GP PROBES 1_0
 
  Pod assigments (? = disabled)
  -----------------------------
  Label  0: ADDR     (16 bits):  A2: ******** ******** 
  Label  1: DATA     ( 8 bits):  A1: ........ ******** 
  Label  2: STAT     ( 3 bits):  A1: .....*** ........ 
 
  Symbols
  -------
  Label: STAT 
         INVALID MEM ACCE  00X
         MEMORY WRITE      010
         MEMORY READ       011
         DMA WRITE         1X0
         DMA READ          1X1

From this, and knowing what signals exist on the 6802, it's apparent that:

  STAT[2] = BA (bus available)
  STAT[1] = VMA (valid memory address)
  STAT[0] = R/W (read/not write)

Creating a STAT label and connecting the bits as defined above works, plus the obvious DATA and ADDR labels.  Screen capture attached.  There's other pins being monitored in the capture, but the IA only cares about DATA, ADDR, and STAT.

I haven't tried any of the other processors, but I've spot-checked the decoded configuration against a few processor datasheets and they at least make sense.  Any feedback welcome, success or not, and especially if I got something wrong with the any of the decoded configs.

Perhaps we should add known working STAT assignments to this post, like the 6802 above, for various processors as people figure them out.

The decoded configuration files for pre-processors is also included, although they're probably not very useful unless you have a pre-processor or looking to build one.


EDIT:  I should also add that in the example the clock is the falling edge of the E signal on the 6802 (or phase 2 clock on the 6800).  I haven't decoded the clocking assignments, but like the STAT assignments this could be figured out after a couple of minutes looking at the datasheet.

[gslick]

To add another note, if you have an IAL style .R relocatable file after the .S file has been run through the assembler, as far as I know there is no simple way to use the .R file with the 16900 series logic analyzer software (also including the 1680 and 1690 series).

However, if you install an older version of the Analysis AddIn Tool there is a wizard tool that lets you build a interpreter wrapper .DLL file around a .R file. It is non-trivial to get set up to do it. The old version of the wizard tool was set up at the time for Microsoft Visual Studio .NET 2003. I did manage to get it set up to build a .DLL file around an assembled .R file from the 8085 .S source from the 10391B tool. I should revisit that and write up some notes about it as I forget exactly what all was involved now.

If you don't have a .R file, or the .S source to build the .R file, I don't know if there is a way to use any of these old IAL style inverse assembler files with the 16900 series logic analyzer software. The files as they are normally distributed are after the IALDOWN tool has done some sort of undocumented transformation of the .R files. Maybe that transformation could be reverse engineered so that a tool could be written to do an inverse transformation back in .R files. Or maybe even disassemble the files back into functionally equivalent .S source files.

[TK]

The STAT bus for the Z80 inverse assembler was described by gslick here: https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg1206485/#msg1206485 and it also requires 3 clock signals (missing on the text file).

[TimInCanada]

Man, you guys are amazing.    This is great info.

I just updated the first post.  Please point out any mistakes.  I'm afraid I've got to run.  More later.

Tim

[MarkL]

...
If you don't have a .R file, or the .S source to build the .R file, I don't know if there is a way to use any of these old IAL style inverse assembler files with the 16900 series logic analyzer software. The files as they are normally distributed are after the IALDOWN tool has done some sort of undocumented transformation of the .R files. Maybe that transformation could be reverse engineered so that a tool could be written to do an inverse transformation back in .R files. Or maybe even disassemble the files back into functionally equivalent .S source files.
...

I looked at IALDOWN a while ago hoping it would provide transformation clues for the 1631D:

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

In short, all it did was copy the .R file verbatim out the serial port, along with a byte that reflected the user's answer to the number of IA sync states to allow.  This makes me think any transformation/linking happens inside the logic analyzer once the .R file is downloaded.


The .R files appear to have "82 03" for the file magic in the first two bytes.  You can find these bytes in all the iXXX files (at offset 0x227, which includes the 512-byte LIF header).  But unfortunately just extracting that chunk of the file does not seem to make a valid .R file.  The 16700 will happily run IA Format on the extracted piece, but it causes a seg fault when you try to load the result.

Further poking at this shows the IA Format utility only puts a wrapper around whatever file you give it, verbatim.  It also does a couple of sanity checks (maybe looking for 82 03), but it's not going deep enough into the data structures to validate the input.

I was hoping the .R file was still unchanged and sitting inside these iXXX package files, but given the above experiment, unfortunately it's not.  More de-transforming is needed.

Just putting this info out there if anyone wants to dig further.

[TimInCanada]

For example, I have a 16702B with a 16752A card and I've been successful using it on a 6802 processor.  I can successfully load i6800_p, the inverse assembler for general purpose (flying lead) probes. 

Hi Mark,

I've also got a 16702B, with 16712A and 16555A cards, but the i6800_p file isn't working for me.  When I try to use the INVASM function on the Listing screen, it says the file is for a 16500 analyzer and needs to be loaded through the File manager.  The file manager gives an error message about a possible filter problem.  The IA Format utility gives an error message that it's not an "IAL" file. 

I just saw your post mentioning the first two bytes being "82 03" and tried putting those in the file.  The IA Format utility now converts the file, but when trying to load the IA on the listing screen it gives an error about file manager handle not found.

Have you run into any problems like these?

The IA asm.exe file contains the text "@(mktid) 64851S006    USER DEFINABLE ASSEMBLER                 A.02.10 10Mar88 14:20:13" .  64851 happens to be HP-UX Hosted Cross Assembler/Linker User Definable, if that might help in figuring out what it does.

Tim

[MarkL]

Hi Tim,

It's true the IA needs to be loaded through the File Manager.  But you only need to do it once.  Once it's loaded, the analyzer creates a special version for itself in the /logic/ia directory with the same name.  You can then use the Lister "Invasm" pulldown to load the same IA next time around.

And when I say "File Manager", I mean the file manager utility, which is the little folder icon, and not the File pulldown.

Also, before you load it, you should define ADDR, DATA, and STAT fields in the pod Format tab.  If you don't, the IA will complain that those fields don't exist and refuse to load.  It's expecting the configuration to load first and take care of this, but the 16510 config files can't be loaded on this machine.  The IA only cares that the fields exist and have between 1 and 32 bits, so they don't have to be right to start; you can go back and fix them up before doing an actual capture.

I haven't seen any loading errors referring to a "filter", although it will tell you there's no compatible instruments if you try to load the 16510 configuration file (cXXX).  Which IA are you trying?  I haven't tried them all, but I can try the one that's giving you trouble.

I don't think it should matter what card you're using, but this works on 16752A and 16717A cards for me.  I'm running 2.90 which is the latest (and last available) version for the 16702B.


Interesting find on the 64851 User Definable Assembler.  I'm guessing it was used to generate the parsing table that asm.exe uses (in HP64700/TABLES/AIAL).  Maybe 64851 will provide some clues on the .R files.  I'll take a look.

[gslick]

I should spend some time looking at the 16900 series Analysis AddIn Tool. It might contain enough information to write a tool to decode a .R file back into something that could be assembled again with the IAL assembler.

For example it contains this instruction opcode table. The opcode bit field positions vary in the instruction word based on the values of high order bits in the instruction word.

Code: [Select]

  /* definitions for the different unique bit patterns for each instruction
   * in the different instruction groups -- used by the interpreter
   */

  /* instruction group 1 */
  const u_int16 IF_OP = 4;
  const u_int16 IF_BITS = 5;
  const u_int16 ICASE_OP = 6;
  const u_int16 ICASE_BITS = 7;

  /* instruction group 2 */
  const u_int16 IGO_TO = 4;
  const u_int16 ICALL = 5;
  const u_int16 ISTR_OUTPUT = 6;
  const u_int16 INUM_OUTPUT = 7;

  /* instruction group 3 */
  const u_int16 ILOAD_ACC = 8;
  const u_int16 IADD_ACC = 9;
  const u_int16 ISUB_ACC = 10;
  const u_int16 IAND_ACC = 11;
  const u_int16 IOR_ACC = 12;
  const u_int16 IXOR_ACC = 13;
  const u_int16 ITAG_WITH = 14;
  const u_int16 INP_ABS = 15;

  /* instruction group 4 */
  const u_int16 ISTORE_MEM = 4;
  const u_int16 INC_MEM = 5;
  const u_int16 IDEC_MEM = 6;
  const u_int16 INP_ABSQ = 7;

  /* instruction group 5 */
  const u_int16 INP_REL = 2;
  const u_int16 INP_RELQ = 3;

  /* instruction group 6 */
  const u_int16 IROT_LEFT = 8;
  const u_int16 IROT_RIGHT = 9;
  const u_int16 IEXT_BIT = 10;
  const u_int16 IPOS_ABS = 11;
  const u_int16 IPOS_REL = 12;

  /* instruction group 7 */
  const u_int16 INOP = 16;
  const u_int16 ICOMP_ACC = 17;
  const u_int16 ITWOCOMP_ACC = 18;
  const u_int16 IRETURN = 19;
  const u_int16 ION_TRACE = 20;
  const u_int16 IOFF_TRACE = 21;
  const u_int16 IABORT = 22;
  const u_int16 IFNOT_MAP = 23;
  const u_int16 IMARKLINE_O_NA = 24;
  const u_int16 IMARKLINE_S_NA = 25;
  const u_int16 IMARKLINE_O_A = 26;
  const u_int16 IMARKLINE_S_A = 27;
  const u_int16 IMARKSTATE_DISP = 28;
  const u_int16 IMARKSTATE_SUP = 29;
  const u_int16 INEWLINE = 30;
  const u_int16 IFETCH_POSITION = 31;

If I have this correct, the mapping from opcode words to instructions in .R files is the following:

Code: [Select]

/* instruction group 1 */
/* conditional instruction -- bit 15 is set */
/* instruction = (opcode >> 13) */

100x xxxx xxxx xxxx     IF_OP = 4
101x xxxx xxxx xxxx     IF_BITS = 5
110x xxxx xxxx xxxx     ICASE_OP = 6
111x xxxx xxxx xxxx     ICASE_BITS = 7

/* instruction group 2 */
/* transfer/output instruction -- bit 14 is set */
/* instruction = (opcode >> 12) */

0100 xxxx xxxx xxxx     IGO_TO = 4
0101 xxxx xxxx xxxx     ICALL = 5
0110 xxxx xxxx xxxx     ISTR_OUTPUT = 6
0111 xxxx xxxx xxxx     INUM_OUTPUT = 7

/* set immediate instruction -- bit 13 is on */

001x xxxx xxxx xxxx

/* instruction group 3 */
/* math instruction -- bit 12 is on */
/* instruction = (opcode >> 9) */

0001 000x xxxx xxxx     ILOAD_ACC = 8
0001 001x xxxx xxxx     IADD_ACC = 9
0001 010x xxxx xxxx     ISUB_ACC = 10
0001 011x xxxx xxxx     IAND_ACC = 11
0001 100x xxxx xxxx     IOR_ACC = 12
0001 101x xxxx xxxx     IXOR_ACC = 13
0001 110x xxxx xxxx     ITAG_WITH = 14
0001 111x xxxx xxxx     INP_ABS = 15

/* instruction group 4 */
/* single variable instruction -- bit 11 is on */
/* instruction = (opcode >> 9) */

0000 100x xxxx xxxx     ISTORE_MEM = 4
0000 101x xxxx xxxx     INC_MEM = 5
0000 110x xxxx xxxx     IDEC_MEM = 6
0000 111x xxxx xxxx     INP_ABSQ = 7

/* instruction group 5 */
/* input relative instruction -- bit 10 is on */
/* instruction = (opcode >> 9) */

0000 010x xxxx xxxx     INP_REL = 2
0000 011x xxxx xxxx     INP_RELQ = 3

/* instruction group 6 */
/* single operand instruction -- bit 9 is on */
/* instruction = (opcode >> 6) */

0000 0010 00xx xxxx     IROT_LEFT = 8
0000 0010 01xx xxxx     IROT_RIGHT = 9
0000 0010 10xx xxxx     IEXT_BIT = 10
0000 0010 11xx xxxx     IPOS_ABS = 11
0000 0011 00xx xxxx     IPOS_REL = 12

/* instruction group 7 */
/* implied operand instruction - bits 15-5 off, bit 4 on */

0000 0000 0001 0000     INOP = 16
0000 0000 0001 0001     ICOMP_ACC = 17
0000 0000 0001 0010     ITWOCOMP_ACC = 18
0000 0000 0001 0011     IRETURN = 19
0000 0000 0001 0100     ION_TRACE = 20
0000 0000 0001 0101     IOFF_TRACE = 21
0000 0000 0001 0110     IABORT = 22
0000 0000 0001 0111     IFNOT_MAP = 23
0000 0000 0001 1000     IMARKLINE_O_NA = 24
0000 0000 0001 1001     IMARKLINE_S_NA = 25
0000 0000 0001 1010     IMARKLINE_O_A = 26
0000 0000 0001 1011     IMARKLINE_S_A = 27
0000 0000 0001 1100     IMARKSTATE_DISP = 28
0000 0000 0001 1101     IMARKSTATE_SUP = 29
0000 0000 0001 1110     INEWLINE = 30
0000 0000 0001 1111     IFETCH_POSITION = 31


[MarkL]

I should spend some time looking at the 16900 series Analysis AddIn Tool. It might contain enough information to write a tool to decode a .R file back into something that could be assembled again with the IAL assembler.

I think we're starting to find enough pieces.

The link to the manual that Tim posted above on the HP-UX Hosted Cross Assembler/Linker describes the format for relocatable files in Appendix D.  I haven't sat down to write a parser for it (yet), but the IA .R files appear to use at least some of the described record types.

I'm also looking at agIalEngine.cpp from the Analysis AddIn Wizard (which I think is where you got that snippet), and it looks like the parser might already be in there.  If I'm reading it right, "CagIalEngine::read_hdr()" starts right off with validating the "82 03" I found before.

agIalEngine.cpp appears to be a complete implementation of the IA interpreter.

[gslick]

Yes, I extracted that opcode information from the agIalEngine.cpp file in the Analysis AddIn Wizard.

Comparing a listing file produced by running 10391B ASM.EXE on the sample I8085.S file against the a hex dump of the resulting I8085.R file I see some blocks that match between the two but also some extra bytes in the .R file between matching blocks that are not in the listing file. Maybe that has to do with the .R file being broken up into records, with a 128 word maximum per record, where the extra bytes in the .R file are part of the record structure wrapped around the raw instruction words.

I'll have to spend some time looking at the record structure documentation in 64851-97000_HP-UX_Cross-Assembler_Jun89.pdf and the record reading code in the agIalEngine.cpp file.

EDIT: Oh, I'm starting to see now that at least some of the extra bytes in the .R file that are not in the ASM.EXE output listing file are 0x5555 T-parameters before a set of 8 words in a double record, where the 0x5555 indicates that each of the following 8 words is two bytes absolute with no modifications.

[gslick]

Hmm, maybe I figured out what happens to a .R file during the IALDOWN transformation, which apparently occurs inside of the analyzer, not inside of the IALDOWN program itself.

It appears that first a 0x200-byte LIF header is inserted at the beginning of the file. Then a description header is inserted. I'm not sure if that is fixed or variable length. In the couple of files I looked at quickly it was 0x25 (37 decimal) bytes in length. Then the original .R file contents follow beginning with the 0x82 0x03 header bytes.

However, starting immediately after the initial 0x200-byte LIF header the remainder of the file is broken up into 0x00FE (254 decimal) byte length records, except for the final record of the file which may be shorter. Each record begins with the record length word inserted in MSB first order. After the final partial length record it appears that the file is padded out to a 0x100-byte boundary with essentially random data.

So it appears that an IA file that has gone through the IALDOWN transformation could be transformed back into an equivalent .R file by first deleting the 0x200-byte LIF header, then for each record delete the record length word at the beginning of the record, and for the final partial length record delete any extraneous data at the end of the record. Then go back and delete the description header at the beginning preceding the 0x82 0x03 header bytes.

I haven't verified that this is entirely correct yet. This is just from a quick look in a hex editor at a couple of IA files. I should try writing some code to do this reverse transformation process and run it on all of the IA files in the INVASM.ZIP collection, then run them through the IALDOWN process, and see if that results in identical IA files again.

[MarkL]

Ah, very interesting.  I found this same structure of a record length of 0x00fe in the 16510 config files, including a short one at the end, all after the LIF header.

The C program I wrote in invasm_configtxt.zip already parses the 0x00fe records for the config files.  I don't know why I didn't think of looking for it in the IA files also.  It should be simple to modify it to handle the IA files.

[gslick]

If we can successfully transform IA files back into equivalent .R files then we should be able to use the 16900-series Analysis AddIn wizard tool to build those into .R files .DLL files to use on that platform. That would be nice. I wonder why Agilent / Keysight never bothered to provide such tools. Maybe they just thought the old IAs were obsolete enough they didn't think anyone would be interested in using them.

It would also be cool if we can write tools to based on the agIalEngine.cpp interpreter engine to disassemble the .R files back into something that can be assembled again to understand how some of the IAs work, and modify them for various reasons if desired.

[MarkL]

Ok, attached is an extracted version of i6800_p as a test using a horribly hacked version of the configtxt tool.

It works for me.  I copied it onto my 16702B and used the IAL format utility on it.  It created the expected package in /logic/ia and I was able to load that into the Listing window, and this time *without* a segfault.  So, I think you figured it out!

Do you want to try it on your 16900?

I can polish up the extractor and convert the rest of them in the morning if you're successful.

And yes, I agree it would be great to be able to go all the way back to the .S so anyone can customize the IA as desired.

[gslick]

It might take me a while to get setup with the 16900 tools again. I think I had that on an 64-bit Windows 7 system where I installed an XP-mode VM so I could install Microsoft Visual Studio .NET 2003, which might not install or run correctly on Windows 7, or something like that. I might have pulled that drive out of that system. I'll have to see what I did with that. I'd rather not have to get all of the tools set up from scratch again.

OK, found the drive that I had set up with the 16900-series Analysis AddIn Tool wizard that I used to build a 16900-series version of the 10391B I8085 sample IA. I'll have to install that drive back in the system and see if I can get the tools running again and try building a 6800 IA.

[gslick]

One quick note about the 0x25 (37 decimal) byte IA file description header that follows the 0x200-byte LIF header at the beginning of an IA file. The IA file description header contains a 0x20 (32 decimal) length IA file description text field. The field is padded with space characters if necessary.

Immediately after the IA file description text field there is a single byte corresponding to the IALDOWN "Invasm" Field Options:
0xFF: A = No "Invasm" Field
0x00: B = "Invasm" Field with no pop-up
0x01: C = "Invasm" Field with pop-up. 2 choices in pop-up.
0x02: D = "Invasm" Field with pop-up. 8 choices in pop-up.

Field Option A means the IA should always have enough status information to be able to (re)synchronize which states are the beginning of instruction fetch cycles. The other Field Options mean the IA may need input from the user to indicate which states should be considered as the beginning of instruction fetch cycles. See Appendix B, Microprocessors with Incomplete Status, in the 10391B reference manual for more information.

For example in the case of the i6800_i IA the preprocessor interface has logic to provide extra status information and the Field Option is A, while the i6800_p IA for the general purpose probes does not have that status information and the Field Option is B.

For the IA files in the original INVASM.ZIP:

Code: [Select]

IA File: i68000_i
IA Description: "68000 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i68000_p
IA Description: "68000 IA FOR GP PROBES       1_0"
IA Field Option: B

IA File: i68008_i
IA Description: "68008 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i68008_p
IA Description: "68008 IA FOR GP PROBES       1_0"
IA Field Option: B

IA File: i6800_i
IA Description: "6800/02 IA FOR INTERFACE     1_0"
IA Field Option: A

IA File: i6800_p
IA Description: "6800/02 IA FOR GP PROBES     1_0"
IA Field Option: B

IA File: i68010_i
IA Description: "68010 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i68010_p
IA Description: "68010 IA FOR GP PROBES       1_0"
IA Field Option: B

IA File: i68020_i.p
IA Description: "68020 INVERSE ASSEMBLER      1_0"
IA Field Option: C

IA File: i6809e_p
IA Description: "6809E IA FOR GP PROBES       1_0"
IA Field Option: B

IA File: i6809_i
IA Description: "6809/9E IA FOR INTERFACE     1_0"
IA Field Option: A

IA File: i6809_p
IA Description: "6809 IA FOR GP PROBES        1_0"
IA Field Option: B

IA File: i80186e_.i
IA Description: "80186 ENHANCED IA            1_0"
IA Field Option: B

IA File: i80186_i
IA Description: "80186 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i80188e_.i
IA Description: "80188 ENHANCED IA            1_0"
IA Field Option: B

IA File: i80188_i
IA Description: "80188 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i80286_i
IA Description: "80286 IA FOR INTERFACE       1_0"
IA Field Option: B

IA File: i80386_8.7
IA Description: "80386 IA WITH 80X87          1_0"
IA Field Option: D

IA File: i80386_i
IA Description: "80386 IA FOR INTERFACE       1_0"
IA Field Option: D

IA File: i8085_ip
IA Description: "8085 INVERSE ASSEMBLER       1_0"
IA Field Option: A

IA File: i8086_i
IA Description: "8086 IA FOR INTERFACE        1_0"
IA Field Option: B

IA File: i8088_i
IA Description: "8088 IA FOR INTERFACE        1_0"
IA Field Option: B

IA File: insc800_.i
IA Description: "NSC800 IA FOR INTERFACE      1_0"
IA Field Option: A

IA File: iz80_i
IA Description: "Z80 IA FOR INTERFACE         1_0"
IA Field Option: A


[MarkL]

I finished up the .R extractor and ran it on all the files in invasm.zip.  Attached is invasm_v3.zip which has the results as well as the previous output from configtxt.

As before, the source is included for reference.  (You can hate my pointer manipulation if it makes you feel better.  It is a one-time hack and not a good example.)

For each inverse assembler iXXX, there is now:

  iXXX.r - The extracted relocatable .R file.  Starts with .R magic 82 03.

  iXXX.info - The additional info in the header: The description and the Invasm Field Options (as per the previous post).

I'm posting this with the caveat that it's for testing since none of it, except for i6800_p.r, has been verified.

Any feedback welcome from anyone who wants to try loading the .r files via IALDOWN, IA Format, or any other utilities.

[gslick]

I finished up the .R extractor and ran it on all the files in invasm.zip.  Attached is invasm_v3.zip which has the results as well as the previous output from configtxt.

I also started writing a file manipulation tool to help improve my own understanding of the file format and did my own version of a .R file from downloaded to analyzer format IA file extractor. I downloaded your invasm_v3.zip files and verified that all of the .R files I extracted binary compare with what you did. So that is a good checkpoint that we are in agreement there.

For the configuration text, have you looked at trying to decode the Master and Slave clock specifications, and the Normal, Demultiplex, or Mixed Clocks modes for each pod?

For 16510 modules the five J, K, L, M, and N clocks are available. Each of those 5 clocks can be specified as either Off, Negative Edge, Positive Edge, Either Edge, Qualifier Low, or Qualifier High, in any combination in a clock specification. The clocks are combined by OR'ing and AND'ing them. Clock edges are ORed to clock edges, clock qualifier levels are ORed to clock qualifier levels, and clock edges are ANDed to clock qualifier levels.

For example you could have (J↓ + K↑) • (M=1 + N=0) as a clock specification.

If all of the pods are clocked in Normal mode then only the Master clock specification applies. If any pods are clocked in either Demultiplex or Mixed Clocks modes then the Slave clock specification also applies.

As far as I know the 16510 Demultiplex and Mixed Clocks modes which split a 16 channel pod into two 8 channel halves are not implemented in the same way in any of the state modules newer than the 16510. In any newer state modules an entire pod is either Master or Slave clocked, or in Demultiplex mode a pod is both Master and Slave clocked but then the other pod in the pod pair becomes unavailable. These differences are probably why a mainframe will not load 16510 configuration files in newer state modules when there is no direct mapping between the 16510 and newer state modules in some configurations.

For example, can you extract the clock specifications and pod clock modes from the c8085_i file?

Code: [Select]

Title: 8085 CONFIG FOR INTERFACE    1_0

Pod assigments (? = disabled)
-----------------------------
Label  0: ADDR     (16 bits):  A2: ******** ******** 
Label  1: DATA     ( 8 bits):  A1: ........ ******** 
Label  2: STAT     ( 4 bits):  A1: ....**** ........

[gslick]

I made some progress in trying to understand the implementation details of an assembled IAL .R binary file.

I hacked up some proof of concept Python code that can read a .R binary file and parse it into the three binary segments, the Program, Data, and Common segments. The segment names are misleading. The Program segment is where the IAL system variables and user defined variables are located. The Common segment is where strings and output format specifications are located, and the Data segment is where instruction opcodes are located.

Using only the I8085.S sample from the 10391B kit for testing so far it appears that the data that is being populated into the three segments from parsing the assembled I8085.R binary file matches the binary data that is shown in the listing file.

The next step would be to try to hack up some proof of concept code than can unassemble the instruction opcodes in the Data segment and try to produce a functionally equivalent .S source file, which would also include declarations of the variables in the Program segment and the strings in the Common segment, and corresponding references to those variables and strings as instruction operands.

It might take a bit more time working my way through the agIalEngine.cpp code to completely understand all of the details of instruction opcode decoding than it did to get my current understanding of the .R binary file segment and relocation data details. But it does look promising now that this is doable.

[MarkL]

...
For the configuration text, have you looked at trying to decode the Master and Slave clock specifications, and the Normal, Demultiplex, or Mixed Clocks modes for each pod?
...

I looked at this with your posting and the user manual in hand.  Unfortunately, it's not immediately obvious where the clocking information lies or how it's encoded in the configuration file.

I think the only way to accomplish this is to actually have a 16510, change one clocking choice at a time, and then observe the resulting change in the saved configuration file.

If we limit the set of relevant clocking configurations to only the ones that are in invasm.zip, it would probably be a lot faster to manually transcribe them by looking at the screen, or from a screen capture.

I think familiarity with a specific processor can also quickly lead a user to the correct clocking configuration to derive the DATA, ADDR, and STAT labels.

For the 8085 specifically, one glance at the datasheet shows that it requires demultiplexing to create the separate fields for DATA and ADDR.  ALE would be the slave clock for demultiplexing.  Looking at the timing diagram and the breakout of the STAT bits show that we need to be able to clock the master on RD, WR, and the special case of INTA.

Knowing the 16510 configuration can help, say if there's complicated qualifiers and OR'd clocks, but in some cases the configuration may not be directly translatable anyway due to the differences in the way the 16510 does it, as you point out.

I guess I'm not convinced that it's going to be worth the investment in time to figure out and write a generalized clocking decoder for the 16510.  I would, however, pony up time to manually transcribe the clock settings for all of the IA configurations in invasm.zip, if you or someone were to provide the screen captures from a 16510.

Or maybe skip the transcribing step completely, and provide complete captures of the configurations and be done with it.  (Which kind-of obviates the work I already did on the config decoder, but that's ok.)

[DIPLover]

Just wanted to point out that the IA files compatible with 1650/16500 are also compatible with 1660/1670 series, maybe the top post should reflect that.

[gslick]

I'm making some progress in being able to decode an IAL style inverse assembler back into equivalent source code that could be assembled with the 10391B ASM.EXE assembler.

Below is what I currently get from processing the "6800/02 IA FOR GP PROBES     1_0" inverse assembler file  i6800_p. I still need to handle declaring variables and constants with their initial values, and declaring strings and format strings instead of putting them inline.

Interesting that it turns out that the "6800/02 IA FOR GP PROBES     1_0" inverse assembler file  i6800_p is the same as the "6800/02 IA FOR INTERFACE     1_0" inverse assembler file  i6800_i file, except that the i6800_p version does this, which selects which status decoding is used (except in the TASK = 3 case):

Code: [Select]

LABEL_0015
    GOTO LABEL_0016


while the i6800_i version does this:

Code: [Select]

LABEL_0015
    GOTO LABEL_0026


Code: [Select]

"IAL"

    IF TASK = 3 THEN GOTO LABEL_0010
    IF TASK = 4 THEN GOTO LABEL_0015
    IF TASK = 5 THEN GOTO LABEL_0015
    OUTPUT "Illegal Task Request"
    ABORT
    OUTPUT "Data Error"
    ABORT

LABEL_000D
    POSITION ABS,1
    OUTPUT "Illegal Opcode"
    ABORT

LABEL_0010
    LOAD ID_CODE
    IF 7,0 = VAR_0048 THEN GOTO LABEL_0016
    GOTO LABEL_0026

LABEL_0015
    GOTO LABEL_0016

LABEL_0016
    LOAD INPUT_TAG
    IF 17,16 = 0 THEN GOTO LABEL_0043
    LOAD INPUT_STATUS
    IF 2,2 = 1 THEN GOTO LABEL_0043
    LOAD INPUT_TAG
    CASE_OF 1,0
        GOTO LABEL_01A2
        GOTO LABEL_0043
        GOTO LABEL_0054
        NOP
    CASE_END
    RETURN

LABEL_0026
    LOAD INPUT_STATUS
    IF 3,0 = 9 THEN GOTO LABEL_005B
    LOAD INPUT_DATA
    POSITION ABS,3
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    POSITION REL,1
    LOAD INPUT_STATUS
    CASE_OF 3,0
        OUTPUT "Illegal Opcode"
        OUTPUT "operand fetch"
        OUTPUT "stack read"
        OUTPUT "stack write"
        OUTPUT "stack read"
        OUTPUT "stack write"
        OUTPUT "halt"
        OUTPUT "vector"
        OUTPUT "unused"
        OUTPUT "opcode fetch"
        OUTPUT "DMA read"
        OUTPUT "DMA write"
        OUTPUT "memory write"
        OUTPUT "memory read"
        OUTPUT "out of synch"
        OUTPUT "interrupt ack"
    CASE_END
    SET RETURN_FLAGS,0
    RETURN

LABEL_0043
    LOAD INPUT_DATA
    POSITION ABS,3
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    POSITION REL,1
    LOAD INPUT_STATUS
    CASE_OF 2,0
        OUTPUT "non valid cycle"
        OUTPUT "non valid cycle"
        OUTPUT "memory write"
        OUTPUT "memory read"
        OUTPUT "dma or halt"
        OUTPUT "dma or halt"
        OUTPUT "dma or halt"
        OUTPUT "dma or halt"
    CASE_END
    SET RETURN_FLAGS,0
    RETURN

LABEL_0054
    LOAD INPUT_DATA
    POSITION ABS,3
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    POSITION REL,1
    OUTPUT "unused cycle"
    SET RETURN_FLAGS,0
    RETURN

LABEL_005B
    SET RETURN_FLAGS,1
    INPUT REL,0
    LOAD INITIAL_DATA
    CASE_OF 7,7
        GOTO LABEL_0062
        GOTO LABEL_0103
    CASE_END

LABEL_0062
    CASE_OF 7,4
        GOTO LABEL_006C
        GOTO LABEL_008C
        GOTO LABEL_009F
        GOTO LABEL_00C4
        GOTO LABEL_00E2
        GOTO LABEL_00E2
        GOTO LABEL_00E2
        GOTO LABEL_00E2
    CASE_END

LABEL_006C
    CASE_OF 3,0
        GOTO LABEL_000D
        OUTPUT "NOP"
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        OUTPUT "TAP"
        OUTPUT "TPA"
        OUTPUT "INX"
        OUTPUT "DEX"
        GOTO LABEL_007F
        GOTO LABEL_0081
        GOTO LABEL_007F
        GOTO LABEL_0081
        GOTO LABEL_007F
        GOTO LABEL_0081
    CASE_END
    RETURN

LABEL_007F
    OUTPUT "CL"
    GOTO LABEL_0082

LABEL_0081
    OUTPUT "SE"

LABEL_0082
    IF 2,1 = 1 THEN OUTPUT "V"
    IF 2,1 = 2 THEN OUTPUT "C"
    IF 2,1 = 3 THEN OUTPUT "I"
    RETURN

LABEL_008C
    CASE_OF 3,0
        OUTPUT "SBA"
        OUTPUT "CBA"
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        OUTPUT "TAB"
        OUTPUT "TBA"
        GOTO LABEL_000D
        OUTPUT "DAA"
        GOTO LABEL_000D
        OUTPUT "ABA"
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
    CASE_END
    RETURN

LABEL_009F
    OUTPUT "B"
    CASE_OF 3,0
        OUTPUT "RA"
        GOTO LABEL_000D
        OUTPUT "HI"
        OUTPUT "LS"
        OUTPUT "CC"
        OUTPUT "CS"
        OUTPUT "NE"
        OUTPUT "EQ"
        OUTPUT "VC"
        OUTPUT "VS"
        OUTPUT "PL"
        OUTPUT "MI"
        OUTPUT "GE"
        OUTPUT "LT"
        OUTPUT "GT"
        OUTPUT "LE"
    CASE_END

LABEL_00B2
    INCREMENT INPUT_ADDRESS
    LOAD INPUT_ADDRESS
    ADD 1
    STORE VAR_003E
    INPUT ABS,INPUT_ADDRESS
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_017C
    LOAD INPUT_DATA
    POSITION ABS,6
    IF 7,7 = 1 THEN INCLUSIVE_OR VAR_0046
    ADD VAR_003E
    AND VAR_0042
    IF_NOT_MAPPED THEN OUTPUT ACCUMULATOR,FORMAT=16,HEX,4
    RETURN

LABEL_00C4
    CASE_OF 3,0
        OUTPUT "TSX"
        OUTPUT "INS"
        GOTO LABEL_00D7
        GOTO LABEL_00D7
        OUTPUT "DES"
        OUTPUT "TXS"
        GOTO LABEL_00D7
        GOTO LABEL_00D7
        GOTO LABEL_000D
        OUTPUT "RTS"
        GOTO LABEL_000D
        OUTPUT "RTI"
        GOTO LABEL_000D
        GOTO LABEL_000D
        OUTPUT "WAI"
        OUTPUT "SWI"
    CASE_END
    RETURN

LABEL_00D7
    IF 2,2 = 0 THEN OUTPUT "PUL"
    IF 2,2 = 1 THEN OUTPUT "PSH"
    CASE_OF 0,0
        GOTO LABEL_00FF
        GOTO LABEL_0101
    CASE_END
    RETURN

LABEL_00E2
    CASE_OF 3,0
        OUTPUT "NEG"
        GOTO LABEL_000D
        GOTO LABEL_000D
        OUTPUT "COM"
        OUTPUT "LSR"
        GOTO LABEL_000D
        OUTPUT "ROR"
        OUTPUT "ASR"
        OUTPUT "ASL"
        OUTPUT "ROL"
        OUTPUT "DEC"
        GOTO LABEL_000D
        OUTPUT "INC"
        OUTPUT "TST"
        GOTO LABEL_00F5
        OUTPUT "CLR"
    CASE_END
    GOTO LABEL_00F9

LABEL_00F5
    CASE_OF 5,5
        GOTO LABEL_000D
        OUTPUT "JMP"
    CASE_END

LABEL_00F9
    CASE_OF 5,4
        GOTO LABEL_00FF
        GOTO LABEL_0101
        GOTO LABEL_016B
        GOTO LABEL_0170
    CASE_END

LABEL_00FF
    OUTPUT "A"
    RETURN

LABEL_0101
    OUTPUT "B"
    RETURN

LABEL_0103
    CASE_OF 3,0
        OUTPUT "SUB"
        OUTPUT "CMP"
        OUTPUT "SBC"
        GOTO LABEL_000D
        OUTPUT "AND"
        OUTPUT "BIT"
        OUTPUT "LDA"
        GOTO LABEL_0116
        OUTPUT "EOR"
        OUTPUT "ADC"
        OUTPUT "ORA"
        OUTPUT "ADD"
        GOTO LABEL_011E
        GOTO LABEL_0126
        GOTO LABEL_0138
        GOTO LABEL_0141
    CASE_END
    GOTO LABEL_0150

LABEL_0116
    IF 7,4 = 8 THEN GOTO LABEL_000D
    IF 7,4 = 12 THEN GOTO LABEL_000D
    OUTPUT "STA"
    GOTO LABEL_0150

LABEL_011E
    IF 7,4 >= 12 THEN GOTO LABEL_000D
    OUTPUT "CPX"
    IF 5,4 = 0 THEN GOTO LABEL_0161
    GOTO LABEL_0156

LABEL_0126
    IF 7,4 = 9 THEN GOTO LABEL_000D
    IF 7,4 >= 12 THEN GOTO LABEL_000D
    IF 5,4 = 0 THEN GOTO LABEL_0136
    OUTPUT "JSR"
    IF 5,4 = 2 THEN GOTO LABEL_016B
    IF 5,4 = 3 THEN GOTO LABEL_0170

LABEL_0136
    OUTPUT "BSR"
    GOTO LABEL_00B2

LABEL_0138
    OUTPUT "LD"
    CASE_OF 6,6
        OUTPUT "S"
        OUTPUT "X"
    CASE_END
    IF 5,4 = 0 THEN GOTO LABEL_0161
    GOTO LABEL_0156

LABEL_0141
    IF 7,4 = 8 THEN GOTO LABEL_000D
    IF 7,4 = 12 THEN GOTO LABEL_000D
    OUTPUT "ST"
    CASE_OF 6,6
        OUTPUT "S"
        OUTPUT "X"
    CASE_END
    IF 5,4 = 0 THEN GOTO LABEL_0161
    GOTO LABEL_0156

LABEL_0150
    IF 6,6 = 0 THEN CALL LABEL_00FF
    IF 6,6 = 1 THEN CALL LABEL_0101

LABEL_0156
    CASE_OF 5,4
        GOTO LABEL_015C
        GOTO LABEL_0166
        GOTO LABEL_016B
        GOTO LABEL_0170
    CASE_END

LABEL_015C
    POSITION ABS,6
    OUTPUT "#"
    CALL LABEL_0175
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    RETURN

LABEL_0161
    POSITION ABS,6
    OUTPUT "#"
    CALL LABEL_017E
    OUTPUT ACCUMULATOR,FORMAT=16,HEX,4
    RETURN

LABEL_0166
    POSITION ABS,6
    CALL LABEL_0175
    IF_NOT_MAPPED THEN OUTPUT ACCUMULATOR,FORMAT=16,HEX,4
    RETURN

LABEL_016B
    POSITION ABS,6
    CALL LABEL_0175
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    OUTPUT ",X"
    RETURN

LABEL_0170
    POSITION ABS,6
    CALL LABEL_017E
    IF_NOT_MAPPED THEN OUTPUT ACCUMULATOR,FORMAT=16,HEX,4
    RETURN

LABEL_0175
    INCREMENT INPUT_ADDRESS
    INPUT ABS,INPUT_ADDRESS
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_017C
    LOAD INPUT_DATA
    RETURN

LABEL_017C
    OUTPUT "**"
    ABORT

LABEL_017E
    INCREMENT INPUT_ADDRESS
    LOAD INPUT_ADDRESS
    STORE VAR_003C
    INPUT ABS,INPUT_ADDRESS
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_0192
    LOAD INPUT_DATA
    ROTATE LEFT,8
    AND VAR_0044
    STORE VAR_0034
    INCREMENT INPUT_ADDRESS
    INPUT ABS,INPUT_ADDRESS
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_019D
    LOAD INPUT_DATA
    AND VAR_004A
    INCLUSIVE_OR VAR_0034
    RETURN

LABEL_0192
    OUTPUT "**"
    LOAD VAR_003C
    STORE INPUT_ADDRESS
    INCREMENT INPUT_ADDRESS
    INPUT ABS,INPUT_ADDRESS
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_01A0
    LOAD INPUT_DATA
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2
    ABORT

LABEL_019D
    LOAD VAR_0034
    ROTATE RIGHT,8
    OUTPUT ACCUMULATOR,FORMAT=8,HEX,2

LABEL_01A0
    OUTPUT "**"
    ABORT

LABEL_01A2
    SET VAR_0040,0

LABEL_01A3
    LOAD INPUT_STATUS
    IF 1,0 = 3 THEN GOTO LABEL_01AE
    TAG_WITH 2
    INCREMENT VAR_0040
    INPUT REL,VAR_0040
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_005B
    GOTO LABEL_01A3

LABEL_01AE
    LOAD INPUT_DATA
    CASE_OF 7,0
        GOTO LABEL_000D
        LOAD 56
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        LOAD VAR_004C
        LOAD VAR_004E
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0050
        GOTO LABEL_000D
        LOAD VAR_0052
        LOAD VAR_0054
        LOAD VAR_0056
        LOAD VAR_0058
        LOAD VAR_005A
        LOAD VAR_005C
        LOAD VAR_005E
        LOAD VAR_0060
        LOAD VAR_0062
        LOAD VAR_0064
        LOAD VAR_0066
        LOAD VAR_0068
        LOAD VAR_006A
        LOAD VAR_006C
        LOAD VAR_006E
        LOAD VAR_0070
        LOAD VAR_0072
        LOAD VAR_0074
        LOAD VAR_0076
        LOAD VAR_0078
        LOAD VAR_007A
        LOAD VAR_007C
        GOTO LABEL_000D
        LOAD VAR_007E
        GOTO LABEL_000D
        LOAD VAR_0080
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0082
        LOAD VAR_0084
        LOAD 56
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD 56
        GOTO LABEL_000D
        LOAD 56
        LOAD VAR_0086
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0088
        LOAD VAR_008A
        GOTO LABEL_000D
        LOAD VAR_008C
        LOAD VAR_008E
        LOAD VAR_0090
        LOAD VAR_0092
        LOAD VAR_0094
        GOTO LABEL_000D
        LOAD VAR_0096
        LOAD VAR_0098
        LOAD VAR_009A
        LOAD VAR_009C
        LOAD VAR_009E
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_00A0
        LOAD VAR_00A2
        GOTO LABEL_000D
        LOAD VAR_00A4
        LOAD VAR_00A6
        LOAD VAR_00A8
        LOAD VAR_00AA
        LOAD VAR_00AC
        GOTO LABEL_000D
        LOAD VAR_00AE
        LOAD VAR_00B0
        LOAD VAR_00B2
        LOAD VAR_00B4
        LOAD 52
        LOAD 52
        LOAD 52
        GOTO LABEL_000D
        LOAD 52
        LOAD 52
        LOAD 52
        GOTO LABEL_000D
        LOAD 52
        LOAD 52
        LOAD 52
        LOAD 52
        LOAD VAR_00B6
        LOAD VAR_00B8
        LOAD VAR_00BA
        GOTO LABEL_000D
        LOAD VAR_00BC
        LOAD VAR_00BE
        LOAD VAR_00C0
        GOTO LABEL_000D
        LOAD VAR_00C2
        LOAD VAR_00C4
        LOAD VAR_00C6
        LOAD VAR_00C8
        LOAD VAR_00CA
        LOAD VAR_00CC
        LOAD VAR_00CE
        LOAD VAR_00D0
        LOAD VAR_00D2
        GOTO LABEL_000D
        LOAD VAR_00D4
        LOAD VAR_00D6
        LOAD VAR_00D8
        LOAD VAR_00DA
        LOAD VAR_00DC
        GOTO LABEL_000D
        LOAD VAR_00DE
        LOAD VAR_00E0
        LOAD VAR_00E2
        LOAD VAR_00E4
        LOAD VAR_00E6
        LOAD VAR_00E8
        LOAD VAR_00EA
        LOAD VAR_00EC
        LOAD VAR_00EE
        LOAD VAR_00F0
        LOAD VAR_00F2
        LOAD VAR_00F4
        LOAD VAR_00F6
        LOAD VAR_00F8
        LOAD VAR_00FA
        GOTO LABEL_000D
        LOAD VAR_00FC
        LOAD VAR_00FE
        LOAD VAR_0100
        LOAD VAR_0102
        LOAD VAR_0104
        LOAD VAR_0106
        LOAD VAR_0108
        LOAD VAR_010A
        LOAD VAR_010C
        LOAD VAR_010E
        LOAD VAR_0110
        LOAD VAR_0112
        LOAD 52
        LOAD 52
        LOAD 52
        GOTO LABEL_000D
        LOAD 52
        LOAD 52
        LOAD 52
        GOTO LABEL_000D
        LOAD 52
        LOAD 52
        LOAD 52
        LOAD 52
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0114
        GOTO LABEL_000D
        LOAD VAR_0116
        LOAD VAR_0118
        LOAD VAR_011A
        GOTO LABEL_000D
        LOAD VAR_011C
        LOAD VAR_011E
        LOAD VAR_0120
        LOAD VAR_0122
        LOAD VAR_0124
        LOAD VAR_0126
        LOAD VAR_0128
        LOAD VAR_012A
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_012C
        LOAD VAR_012E
        LOAD VAR_0130
        LOAD VAR_0132
        LOAD VAR_0134
        GOTO LABEL_000D
        LOAD VAR_0136
        LOAD VAR_0138
        LOAD VAR_013A
        LOAD VAR_013C
        LOAD VAR_013E
        LOAD VAR_0140
        LOAD VAR_0142
        LOAD VAR_0144
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0146
        LOAD VAR_0148
        LOAD VAR_014A
        LOAD VAR_014C
        LOAD VAR_014E
        GOTO LABEL_000D
        LOAD VAR_0150
        LOAD VAR_0152
        LOAD VAR_0154
        LOAD VAR_0156
        LOAD VAR_0158
        LOAD VAR_015A
        LOAD VAR_015C
        LOAD VAR_015E
        GOTO LABEL_000D
        GOTO LABEL_000D
        LOAD VAR_0160
        LOAD VAR_0162
    CASE_END

LABEL_02B1
    STORE VAR_0036
    AND 3
    STORE VAR_003A
    IF 1,0 = 3 THEN GOTO LABEL_005B
    TAG_WITH VAR_003A

LABEL_02B8
    INCREMENT VAR_0040
    INPUT REL,VAR_0040
    IF INPUT_ERROR <> 0 THEN GOTO LABEL_005B
    LOAD INPUT_STATUS
    IF 2,2 = 1 THEN GOTO LABEL_02B8
    LOAD VAR_0036
    ROTATE RIGHT,2
    GOTO LABEL_02B1