<--  back   Last regenerated: 2018-05-23 16:12:32 kio

zasm - Z80 Assembler – Version 4.2

Targets

#target BIN and ROM

These are the simplest and most common targets. ROM is intended for creating rom files while BIN is intended to be downloaded somehow into the ram of a target system. The only difference between ROM and BIN is, that for ROMs zasm uses 0xFF as the default fill byte for gaps, e.g. in the 'defs' Pseudo instructions
8080 Assembler: 8080 pseudo instructions
pseudo instruction or for the padding at the and of a Assembler directives: #code
Including C Source Files: #code
#code segment.

#target ROM

This file is a plain rom or eprom image.

Segments are padded with $FF to the defined size, Assembler directives: #if, #elif, #else, #endif
Pseudo instructions: if, endif
if the size wasn't omitted.

The address should be the address at which it is visible to the CPU, the so-called 'physical' address.

#target rom
Assembler directives: #code
Including C Source Files: #code
#code <name>,<start>,<size> ...

#insert: Examples:
#assert: Example:
incbin: Examples:
Example for a rom which is paged into the Command Line Options: --z80
Pseudo instructions: .z80, .z180 and .8080
Targets: #target Z80
Z80 address space in 2 pages:

#target rom
Assembler directives: #code
Including C Source Files: #code
#code _PAGE1,0,0x4000 ... Assembler directives: #code
Including C Source Files: #code
#code _PAGE2,0,0x4000 ...
#target BIN

Pretty the same as a rom file, but rather expected to be loaded somewhere into ram.

Segments are padded with $00, Assembler directives: #if, #elif, #else, #endif
Pseudo instructions: if, endif
if the size wasn't omitted.

#target bin
Assembler directives: #code
Including C Source Files: #code
#code <name>,<start>,<size> ...
Writing Intel Hex files

Using Differences from v3 to v4: Command line options
Command Line Options
Command Line Options: Command line options
command line option '-x' the BIN and ROM targets can be written in the Intel Hex format. These files look like this:

:200000003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED787B
:090020000F0F30FADB70321027DB
:00000001FF

Trailing fill bytes (0xFF for ROM and 0x00 for BIN) in each segment are not stored in the file. This generally reduces file size and the time to burn the file into an eprom or to transmit it to the host system. The disadvantage is that in rare cases some last bytes are not stored and consequently not written into the ram of the target system, thus leaving these ram positions in an unset state. The target system should therefore always erase the ram before downloading the file! For eproms this is not such a problem because eproms must be erased before they can be burned and they are erased to … 0xFF of course. That's the reason why the fill byte for ROM is 0xFF.

Writing Motorola S-Record format

Using Differences from v3 to v4: Command line options
Command Line Options
Command Line Options: Command line options
command line option '-s' the BIN and ROM targets can be written in the Motorola S-Record format. These files look like this:

S00F00007320323031352D30312D313178
S12C00003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED780F0F30FADB7032102772
S5030001FB
S9030000FC

Trailing fill bytes are handled as for the Intel hex format.

Valid HTML   Valid CSS