pastarchivesThis my projects page. Here you'll find materials or works i decide to publish on the web.

 

 

 


 

Available projects:

 

doc-1-48filler22 

CP/M Newsgroups Archive

 

Project aimed to have a backup of the whole CP/M newsgroups availables on the usenet archives

   
software-1-48 filler22

MZT My Z80 Tools

 

A cross-assembler, a linker/librarian and a "smart" disassembler for Z80 binaries in a unique integrated package.

   
hw-1-48filler22

Z80NE Where it all began United Kingdom flag icon 26 Z80NE dove tutto è iniziato Italy Flag icon 26

 

Dedicated to the Z80 computer that changed my life. It was the year 1979...
Dedicato al computer Z80 che ha cambiato la mia vita. Era l'anno 1979...

 
hw-1-48

Z80NE 2006 una nuova vita Italy Flag icon 26

Dopo anni di paziente attesa si torna alla vita!

 

Accesso veloce alle pagine - Quick page access

  • La eprom da 4K e il SONE prima del SONE
  • Il CP/M 3 o CP/M+
  • Tips & Tricks

MZT

My Z80 Tools

 

MZT or My Z80 Tools is a complete set of cross-assembly tools targeted at the Z80 cpu in a Linux enviroment. It includes a macro assembler (mzmac), a linker/librarian (mld80) and a disassembler (mdz80).
The components of MZT are designed to provide a set of well-integrated tools capable to operate in the most recent versions of 64-bit Linux.

All the software si derived by a fork of existing projects. See in the sections relative to each tool for original authors credits.

MZT needs cmake to compile. Cmake is available on all major Linux distributions and you can always visit project site www.cmake.org for additional informations.

 

Why MZT?
I could answer with a simple "why not?", but the point is that the tools available do not usually make a unique environment, or do not have all the features that I want, or simply they do not fit my tastes and way of working, and since i still spent much time on Z80 projects this is more then enough for me to write a new one. Wink

 

If you are of those in a hurry, you can jump directly to the downloads, or you can read more in each tool's section: mzmac, mld80, mdz80.

 

Installation

Install cmake, if you do not already have it on your system.

Extract MZT tar file in a working subdirectory and then do:

$ make; make install

By default MZT will be installed in /usr/local, if this is not what you want, in MZT top directory you can edit the Makefile and change the value of the variable INSTALL_PREFIX to your desired installation path.

Depending on where you decide to install MZT executables, you may need root permissions to do "make install".

 

Mzmac is a macro cross-assembler for the Z80 and is based onthe well-known zmac of which it inherits all the features. In particular mzmac is based onthe highly advanced version of zmac developed by George Phillips that includes, among other features, cycle counting and various output formats including the most important ".rel".

Mzmac differs from its predecessor in management of output formats, the format of listing and in management of options from command line.

It also has a better support for 64-bit environments, reformatted source code and some minor improvements/bug fixing.
At present mzmac is able to successfully compile almost every kind of source including CP/M 3.
An integral partof mzmac is its support for macro directives in style of m80, rmac or SLR.
In the current version however, are not yet supported the following directives: IRP, IRPC, REPT and EXITM.
The implementation of these directives has the highest priority among the objectives of the next release.

Mzmac exactly as zmac has a long list of credits: Bruce Norskog wrote the original version in 1978 and then it was updated by John Providenza, Colin Kelley, Russell Marks, Mark Rison, Chris Smith, Matthew Phillips and Tim Mann.

Finally George Phillips has written the versions on which mzmac is based.


Usage:

 It has the following options:

        --version show version number
        -8      use 8080 interpretation of mnemonics
        -b      no binary (.hex,.cmd,.cas, etc.) output
        -c      add cycle counts in listing
        -d      make the listing discontinuous.
        -e      error list only
        -f      print if skipped lines
        -g      do not list extra code
        -h      show this information about options and quit
        -i      do not list include files
        -I dir  add 'dir' to include file search path
        -j      promote relative jumps to absolute as needed
        -J      warn when a jump could be relative
        -l      no list
        -L      force listing of everything
        -m      print macro expansions
        -n      put line numbers off
        -p      put out four \n's for eject
        -s      don't produce a symbol list
        -t      output error count instead of list of errors
        -x      generate listing to `listfile' (`-' for stdout)
        -z      use Z-80 interpretation of mnemonics

        --bin   output .bin file (default)

        --ams   output .ams file
        --bds   output .bds file
        --cas   output .cas file
        --cmd   output .cmd file
        --hex   output .hex file
        --lcas  output .lcas file
        --rel   output .rel file

        --dep   list files included

        --mras  limited MRAS/EDAS compatibility
        --help  show detailed help
        --html  output detailed help in HTML format

Using --help or --html, produce a much more informative help page, respectively in (coloured) text or in HTML format that you can also read here.

Apart its ability to produce .rel format output, mzmac can perform accurate timing evaluation (cycle counting) on assembled code. George Phillips has written an interesting tutorial on this at his site.

 

Known bugs:

Equates of this kind:

TRUE        EQU    0FFFFH
FALSE       EQU    0

are not always evaluated correctly.

Replace with this to be sure:

TRUE        EQU    -1
FALSE       EQU    0

 

Mld80 is the linker/librarian tool of MZT toolset.

While it is a replacement for the Micrososft L80 linker for CP/M and incorporates almost all of its capabilities, mld80 has also extra features.

Mld80 accepts object (.rel) files produced by mzmac or by original m80, rmac or compatible assemblers as well as library (.rel) files made by LIB80.

In this initial release it does not support any of expected librarian function (create or add/change/remove members). It is also not capable to produces .SPR, .PRL or .OVL files.

All this features will be in the next release.

Mld80 is a derivative of ld80 by Gábor Kiss.

 

Usage:

mld80 -o outfile [options] objectfile ...

 

Addresses must be in the range 0-FFFF and expressed in hexadecimal notation. Addresses prefixed by a percent (%), as %NNNN, are not absolute and instructs mld80 to place following segments on a NNNN-boundary.

E.g. -D%10 causes the following data segments to be located on a 16 byte boundary.

-Paddress

specify the address where code segment of the following object files will be placed. If an object file specification is not preceded by -P option, code segment will be appended to the previous one. If no -P option specified before the first object file, its code segment will be placed to 0000.

-Daddress

specify where data segment of the following object files will be placed. If an object file specification is not preceded by -D option, data segment will be appended to the previous one. If no -D option specified before the first object file, its data segment will be appended after the last code segment.

-Cname,address

address is the address where common block name will be placed. If block name name is empty string or it begins with space it will be treated as blank common block. However no extra whitespace character around of comma (,) are allowed. Name is not case sensitive. Common blocks of unspecified location will be appended to the last data segment.

-Uname

Common block named name will be "uncommon". Normally common blocks of the same name are located on the same address. However blocks marked as uncommon will be concatenated like code or data segments. In this way you can spread your code/data over several region of physical memory. Name is case insensitive.

-llibrary

The following object file is a library. Mld80 will scan the library loading only modules that satisfies unresolved external references. If a new reference is encoutered to an already extracted module than the newer module will not loaded again. It is possible to specify the same library more than once in order to resolve backward references.

-c

Suppress data segments. The output file will contain just code and absolute segments only.

-Ooformat

Output format specification. Possible values of oformat are:

    • ihex: Intel hex. This is the default format.
    • bin: Raw binary, gaps filled with X'00'.
    • binff: Raw binary, gaps filled with X'ff'.

-Wwarns   

Request for warning messages. Possible value of warns is (only):

extchain: Warn if ambigous external reference found.

-ssymfile

Name of symbol file. `-' stands for the standard output.

-m

Generate map. A list of segment mapping will be placed into symbol file if it has been specified. Otherwise the segment list will printed on standard output.

-Ssymsize

Symbol table size. Use this option if the linker have to process more than 1024 symbols.

-V

Print version number and exit.

 

Mdz80 is a "smart" disassembler for the Z80 cpu. It has the abilty to trace input code to "guess" what kind of binary data it is, and so, to have a disassembly that correctly produce different output for data or code.

Disassembly is also controlled by a "control" file (autogenerated the first time) that lets you assign a "type" to variuous regions of code to produce highly readable code even from the first attempts of disassembly job.

Of the MZT toolset mdz80 is the most mature and heavily rewritten respect to original code.

Mdz80 is a fork of the D52 microcontroller disassembler from Jeffery L. Post.

 

The mdz80 disassembler allows the user to specify memory areas as code, binary data (8 or 16 bit), ascii text, address tables, or data that should be ignored (not disassembled). You may specify such areas in an ascii text file with the same name as the file to be disassembled, but with an extension of ctl (for example: program.ctl controls the disassembly of program.hex or program.bin).

With the use of a control file, you can, by an iterative process, get a progressively more meaningful disassembly by modifying the control file based on examination of the output of previous runs of the disassembler. You can also specify names for labels and symbols in the control file, resulting in a much more readable source file.

Labels and symbols may have as many characters as will fit in one line of the control file, but some cross assemblers (and especially cross linkers) will truncate any more than some fixed number of characters. Consult your cross development tool documentation. Labels and symbols are not case sensitive.

The control file may exist in either the current directory or the directory of the file to be disassembled. If it is in both directories, the control file in the current directory will take precedence. The output file will always be placed in the current directory.

The getting started section of this document gives some minimal information for users who are eager to try out the disassembler. For best use of the disassembler, however, you should read the sections on command line options and control file directives before proceeding.

 

Usage:

 

Usage: mdz80 [options] <filename> [-o <ofile>] [-c <cfile>] [-e <efile>]

File control options:
        -o use 'ofile' as output.
        -c use 'cfile' as control.
        -C disassemble CP/M .com file (implies -x100).
        -b force .bin format/extension on input file.
        -h force .hex format/extension on input file.
           If neither 'b', 'c', nor 'h' is specified, mdz80 will first search
           for a .hex file, then a .bin file and then the filename alone.
        -t trace and analyze code before disassembly.
        -e use asm source 'efile' to add/evaluate symbols
           (Altoghether with -t option will create/modify control file).

Disassembling options:
        -a use ascii macro instead of db/defb for text.
        -d include address and data in comment field.
        -n use C style for hexadecimal operands
        -f format hex values as '$xx' instead of xxH.
        -p put dot '.' at beginning of pseudo ops
        -s change 'defb' and 'defw' to 'db' and 'dw'.
        -l output labels, symbols, and mnemonics in lower case.
        -x [nnnn] add hexadecimal offset to program addresses.
        -8 generate 8080 mnemonics.
        -T during trace (-t) presume unidentified binary is code

General options:
        -v be verbose.
        -V print version and exit.

Options are case sensitive and may be entered in a freeform
fashion as long as a dash (-) preceeds any option (group).
Examples:
        mdz80 -bd filename
        mdz80 -d filename -b -o out_file


Getting Started


mdz80 is a command line disassembler. To disassemble a file called 'program.bin' or 'program.hex', type in (at the command line prompt):

mdz80 -d program

A control file with the same name as the file to be disassembled, but with an extension of '.ctl' can be created in which you can specify areas of memory to be ascii text, 8-bit binary data, 16-bit binary data, etc. A control file is not necessary for disassembly, but as will be seen, it will provide for a much more complete disassembly. The -t option will cause mdz80 to trace and analyze the code before disassembly, and will create a preliminary control file.

If a file extension is not provided and neither the -b option nor the -h option is specified on the command line, the disassembler will first search for a hex file and, if it is not found, will then search for a bin file. The disassembler can be forced to look for only one or the other by specifying either the binary or the hex option on the command line:

mdz80 -db program for the file program.bin, or
mdz80 -dh program for the file program.hex

If a file extension of '.hex' or '.bin' is provided in the filename (ie: mdz80 test.hex), that is equivalent to using the -h option or -b option.

mdz80 will produce a file named 'program.z80' containing the disassembly of the original hex or binary file. It is very useful on the first few disassemblies to use the -d option , which adds a comment field to every line. The comment field contains the hexadecimal address of each instruction, the hex data for each byte in the instruction, and the ascii code for each byte of the instruction.
Example:

(opcode/operands) (address) (data) (ascii)
JR X0131 ; 0100 18 2F ./

This makes it easy to spot areas of ascii text or other nonexecutable code, and you can then modify the control file to tell the disassembler that these areas should be treated as some other kind of data on subsequent disassemblies.

By examining the output file and then modifying the control file based on the information obtained, you can get a progressively better disassembly of your program. Generally, about half a dozen iterations of the disassembly are enough to produce a very readable source file that can then be modified and reassembled.


Command Line Options

Options are case sensitive and may be entered in a freeform fashion as long as a dash (-) preceeds any option or group of options:

mdz80 -bd filename

or

mdz80 -d filename -b -o out_file


Command line options are: 

-a (ascii macro)

The A option tells the disassembler to change the db/defb pseudo op to the ascii macro (pseudo op 'ascii' instead of 'db' or 'defb') for areas defined as ascii text. This will cause the disassembler to include a macro definition in the disassembly output file that should expand to 'db' for the cross assembler. To use this option, your cross assembler must be able to handle macros, and in particular, mzmac's macro format. If used in conjunction with the -s option , the -s option must come first on the command line.

There are some caveats regarding the ascii macro. The intent of this macro is to make ascii text easier to find in the output file. Once you're satisfied with the readability of the output file, you may want to run the disassembler once more without the -a option to produce a file compatible with your cross assembler.

-8 (disassemble 8080 code)

Disassembles code using 8080 opcodes instead of Z80 opcodes (that is the default).

-b (read binary file)

The -b option forces the disassembler to read a binary file (extention '.bin') instead of an Intel hex file (extention .hex). If neither the -b option nor the -h option are specified, the disassembler will first search for a file with an extention of .hex, and if not found, will then search for a binary file with an extention of .bin. 

-c (control filename)

This option lets you specify a filename for the .ctl file to be used, instead of the default that is input filename postfixed with ".ctl".

-C (disassemble CP/M .com file)

Disassembles a CP/M .com executable file beginning at address 100H. Use of this option will cause mdz80 to look for a file with a .com extension, as opposed to a .bin or .hex extension. This option also sets the offset to 100H without the need to do so with the -x option.

-d (put data in comment field)

The -d option tells the disassembler to include a comment field in each disassembled line. The comment field will contain the hexadecimal address of each instruction, the hex data for each byte in the instruction, and the ascii code for each byte of the instruction.
Example:

(opcode/operands) (address) (data) (ascii)
JR X0131 ; 0100 18 2F ./

This makes it easy to spot areas of ascii text or other nonexecutable code, and then modify the control file to tell the disassembler that these areas should be treated as some other kind of data on subsequent disassemblies. 

-e (evaluate symbols from asm source)

Use this option to feed mdz80 with an assembler source file the contains valid labels, equates and entry points in the context of what you are disassembling. In this way mdz80 will extract a list of symbols to be used in the current disassembly substituting symbols in list with the autogenerated ones.
Normally this is to be used in the very first runs of mdz80 in conjunction with -t option to trace code and generate an initial .ctl file that already contains valid labels. 

-f (use '$' prefixed operands)

Use this option to have the disassembler output hexadecimal operands using '$' prefix notation, ie: $cd instead of the default 0cdh.

-h (read hexadecimal file)

The -h option forces the disassembler to read an Intel hex file (extention '.hex') instead of a binary file (extention '.bin'). If neither the -b option nor the -h option are specified, the disassembler will first search for a file with an extention of '.hex', and if not found, will then search for a binary file with an extention of '.bin'. 

-l (lowercase case output)

Causes labels, symbols, mnemonics, etc to be output in lower case, for cross assemblers that may require lower case code. Comments, literal data values, strings, and other output are not affected by this option.

-n (use C type operands)

Use this option to have the disassembler output hexadecimal operands using C notation, ie: 0xcd instead of the default 0cdh. 

-o (output filename)

This option lets you specify the output filename, instead of the default that is input filename postfixed with ".z80".

-p (add dot in front of pseudo ops)

Some assemblers require pseudo operations to begin with a dot. Use this option to have the disassembler output ".equ" instead of "equ" and similar for org and other pseudo operations. 

-s (set string pseudo op)

This option tells the disassembler to generate the pseudo ops 'db' and 'dw' instead of 'defb' and 'defw' for those cross assemblers that may require this.Use this option for cross assemblers that do not recognize 'defb' and 'defw'. If used in conjunction with the -a option , the -s option must preceed the -a option on the command line.

-t (trace and analyze code)

This option tells mdz80 to trace and analyze the Z80 code before disassembling it. mdz80 will attempt to determine which parts of the code are actually code, and which parts are ascii text, binary data, pointers, etc. While it does a reasonably good job of analyzing the code on most files, no program can do as good a job as a human programmer. A control file with the same name as the hex or bin file, but with an extension of '.ctl', will be created before the actual disassembly is performed. You can then edit the control file to correct any erroneous directives, or to add new directives.

Warning: Using this option will overwrite any control file that may already exist for the code file being disassembled. It is intended to be used on the first disassembly only or until you combine disassembly options in the right way to have a good starting point.

-T (presume code during trace)

This option is meaningful only in conjunction with -t option during initial traces of the code. If you are disassembling very fragmented code or code that cannot clearly traced from the beginning (i.e. a library) this can easily confuse mdz80 produncing wrong output. -T option will instruct mdz80 to presume the all binary input that can't be exactly identified as code or data must be considered as code and in this way disassembled.

-v (be verbose)

Will inform you of the phases of disassembling.

-V (print version)

Will print mdz80 version and then exit.

-x (add hexadecimal offset to addresses)

This option causes the disassembler to add a hexadecimal offset to the address of every location in the code file. This may be useful for disassembling code that was read from the second (or subsequent) rom of a set of roms. For example, suppose that binary data was obtained from a set of 4K byte eproms (call them rom1 and rom2). Then the first file should be disassembled with the command line:

mdz80 -d rom1

and the second should be disassembled with the -x option:

mdz80 -d rom2 -x1000

The two files then can be combined into one and all references within the disassembled code will be to the correct addresses.

If given on the command line, the -x option overrides any -o directive in the control file.

 

The control file


The control file gives you the way to assign the proper type to regions of code in disassembly that are not (eventually) correctly identified by mdz80 during trace.

See here how to use the control file.


  •  Implements missing macro directives in mzmac (IRP, IRPC, REPT, EXITM)
  • Add librarian functions to mld80
  • Add the ability to link .PRL, .SPR files to mld80
  • Add an option to mdz80 to recognize embedded print routines and disassemble embedded ascii text in the right way.

 

Suggestions or, even better, code enhancements are more then welcome... Smile

 

Latest version (source format):

mzt-1.0.0.tar.bz2

mzt-1.0.0.tar.gz

Older versions:

- none -

 

 

 

 

Control directives tell the disassembler to treat specified areas of the code to be disassembled as something other than executable code. The user specifies control directives by editing (with any text editor) a control file with the same name as the file to be disassembled, but with a file extention of .ctl (eg: program.ctl to control the disassembly of the file program.hex or program.bin). A generic control file called 'generic.ctl' is provided to get the user started. Copy 'generic.ctl' to 'file.ctl' where 'file' is the name of the binary or Intel hex file to be disassembled, and modify as required based on the output of the disassembler. Then run the disassembler again to get a more readable disassembly of the code.

All directives consist of a character that specifies the type of data, followed by a hexadecimal number specifying the value or range of values of the data. In the case of a label or symbol directive, the hexadecimal number is followed by ascii text defining the label or symbol. See individual directives for examples. All directives must be in the first column of the line. Directives may be complete words, but only the first character is significant, ie:

Label       0       reset                   and
looney       0       reset                    

will both generate the label "reset" for address 0. Note that they are not case sensitive.

Numerical values must be in hexadecimal and may optionally be preceeded by "0x". For example, a hexadecimal number may be entered as "1234" or "0x1234". Either will be interpreted as the number 1234H.

Everything following a semi-colon (;) is a comment and will be ignored by the disassembler.

Label and symbol directives differ in that a label refers to an address and a symbol refers to any 8 or 16 bit immediate data.
Symbols apply only to immediate data. To specify a symbol for an Z80 data memory location, use the R directive , or to force name substitution for an operand at a given address, use the X directive.

Single values are specified by entering just the value; ranges of values are specified by a start and stop address separated by a dash (-), or by a start address and count separated by a plus (+), ie:

t 1000             the data at address 1000H is ascii text.
t 1000-1010             the data from address 1000H to (and including) address 1010H is ascii text.
t 1000+6             ascii text starting at 1000H for 6 bytes.

Directives are processed in the order in which they are read from the control file. Specifying an area as ascii data and then later specifying it as data to be ignored (uninitialized data) will cause that area to not be disassembled at all. Care must be taken in specifying areas in the control file. 

A Directive (address data)

Specifies that the address contains a word value corresponding to an address for which a label should be generated. For example, a vector table may be located at address 0x1000 containing four entries. The user can modify the control file by adding the following entry:

a 1000-1007

This will cause the disassembler to generate the following output lines:

defw vec1
defw vec2
defw vec3
defw vec4

assuming that the control file also contains entries for the values found at those addresses to generate the labels vec1 through vec4. The addresses referenced will be flagged so that labels will be generated in the output file at those addresses. 

B Directive (byte binary data)

Specifies that the data is to be interpreted as 8 bit binary data. For example:

b 1000-1007

tells the disassembler that the data from address 1000H to 1007H should generate the line:

defb 0,1,2,3,4,5,6,7

assuming that the data at address 1000H and up is 00H, 01H, etc. 

C Directive (code data)

Forces the disassembler to interpret the data as executable code. This may be necessary because the disassembler skips over strings of 00H or ffH bytes that occur since they are unlikely to be real code. However, sometimes programmers insert several NOPs for timing purposes. 

D Directive (define data type (label or symbol))

d address [0 or label]         search label table only
d address [1 or symbol]         search symbol table only
d address [2 or none]         don't search either table

Forces the disassembler to search only the label or symbol table. This allows you to specify a label and a symbol for the same value.
Note that the last parameter can be either a number (0, 1, or 2) or a word (label, symbol, none). If the last parameter is a word, only the first character is checked for L, S, or N, and is not case sensitive.

I Directive (ignore data)

Tells the disassembler to ignore a range of addresses that may be initialized by the input file. This is useful when the input file is a binary file generated by an eprom programmer that dumps the entire eprom space. The valid data from a 4K eprom might only be, say, 3K in length. By adding

i c00-fff

to the control file, you tell the disassembler to not disassemble the data from address 0c00H to 0fffH.  

L Directive (label definition)

Defines a label to the disassembler. Labels are generated in the output disassembly file whenever a reference to the address is found and the label exists in the label table. Suppose that address 0000H contains the code 01 43 (ajmp 0043H). Then the entry

l 43 start

in the control file will cause mdz80 to disassemble this code as:

JP start

rather than:

JP X0043

The code beginning at address 43H will then have the label 'start' in the label field rather than the label 'X0043'. See the entry for the S directive for an explanation of the difference between labels and symbols and also -e command line option that can be used to automate this task.

N Directive (suppress address label generation)


The disassembler will generate labels for addresses that are referenced by code such as

LD A,6

If the operand represents a constant rather than an address, you can suppress the automatic generation of a label (X0006) for address 6h by entering

n 6

in the control file. You'd want to make sure that address 6h isn't legitimately addressed by some other code before using this directive. 

O Directive (add hexadecimal offset to addresses)

This directive causes the disassembler to add a hexadecimal offset to the address of every location in the code file. See the -x option for details. It will be overridden by any -x option specified on the command line. If the -t option (trace and analyze code) is given on the command line, the O directive has no effect since any existing control file will be rewritten. In this case you must use the command line -x option to specify an offset. 

P Directive (patch inline code)

This directive is of dubious value, but has been added for anyone who might find it useful. The P directive is similar to the comment directive except that the user supplied string is patched into the output stream as code, not as a comment. You could, for instance, patch in a macro definition or an include statement. Patching in executable code is not a real good idea. 

S Directive (symbol definition)

Defines a symbol to the disassembler. Symbols are output to the disassembly file whenever the value is encountered in the input file and the symbol exists in the symbol table. The user can specify a symbol for a value by a line such as:

s 20 space

Code which uses this value, such as:

LD A,20h

will then be disassembled as:

LD A,SPACE

Labels and symbols differ in that a label applies to an address, whereas a symbol applies to any 8 or 16 bit immediate data. For code which can only refer to values, such as

LD A,20h

only the symbol table will be searched for a matching value. For code which could refer to either an address or a value, such as:

LD HL,(1234h)

the label table will be searched first, and only if no matching value is found will the symbol table then be searched. 

T Directive (text [ascii] data)

Forces the data in the range specified to be disassembled as text (ascii data). Thus the code: 48 69 20 74 68 65 72 65 at address 1000H will be disassembled as:

DEFB 'Hi there' or
ASCII 'Hi there' (command line option -a used)

by putting the line:

t 1000-1007

in the control file. Data specified by this directive is not checked to verify that it really is ascii data--be careful. 

W Directive (word binary data)

Specifies that the data is to be interpreted as 16 bit binary data. For example:

w 1000-1007

tells the disassembler that the data from address 1000H to 1007H should generate the lines:

DEFW 0
DEFW 1
DEFW 2
DEFW 3

assuming that the data at address 1000H and up is 00H, 00H, 00H, 01H, 00H, 02H, etc. This differs from the A (address) directive in that the A directive also causes a reference to be made to the indirect address. In other words, if the data at address 1000H is 1234H, the A directive will cause a label (X1234) to be put in the output file at address 1234H, whereas the W directive will not. 

X Directive (specify name for operand data)

Specify a name for an operand at a particular address. This is similar to the S directive except that it applies only to the given address. For example, if the symbol 'CR' is defined as 0dh, every instance of 0dh as an operand will have the symbol 'CR' substituted. It may be, however, that the value 0dh has a different meaning when used as an operand for a particular instruction. The X directive allows you to modify the interpretation of an operand at specific operand locations. Why not then use the X directive exclusively? Because that would force you to place an X directive in the control file for every instance in which that value appeared as an operand. The S directive, defined only once for an operand value, will substitute the symbol text for everyoccurrance of that operand value unless overridden by the X directive. Note that the address defined in the X directive is the address of the operand, not the address of the instruction. For example:

X 102 loopinit

forces substitution of the text 'loopinit' for the operand located at address 102h. Therefore an instruction that should be interpreted as

LD A,LOOPINIT

will not be disassembled as

LD A,CR

if the control file contains the above x directive, and also contains an S directive defining 0dh as 'CR', and the value of the operand for the mov instruction happens to also be 0dh.

Y Directive (specify name for operand data but suppress EQU generation)

This is similar to the X directive except that the disassembler will not generate an EQU statement for the operand value in the output file. This should be used when you want to specify a name for an operand that is an assembler pseudo-op such as LOW() or HIGH(). 

# Directive (header comment string)

Defines a comment string to be output prior to disassembly at the specified address. For example:

        # 95
        # 95 Start of initialization
        # 95



in the ctl file would cause the output

        ;
        ; Start of initialization
        ;
                LD  A,80H           ;0095     3E 80     >.



assuming that the code 'c2 af' was located at address 0x95. Since ASCII strings consume prodigious amounts of memory, it is wise to use this directive sparingly. It is, however, useful for marking blocks of code that have been identified in previous runs of mdz80. 

! Directive (inline comment string)

Defines a comment string to be output after disassembly at the specified address. For example:

        ! 95 Start of initialization



in the ctl file would cause the output

                LD  A,80H           ;0095     3E 80     >.    ; Start of initialization



for the above example. Note that inline comments are only available for code and word data, and will do nothing if the data at the specified address is defined as data other than code or word data (ascii text, for example).

 

To MZT main page.