| back |  | Last regenerated: 2022-04-20 17:31:36 kio

# zasm - Z80 Assembler – Version 4.4

# Targets

[<prev] [next>]

| ### #target RAM (old: BIN) and ROM These are the simplest and most common targets. ROM is intended for creating rom files while RAM is intended to be downloaded somehow into the ram of a target system. One difference between ROM and RAM is the default #code: Fill Byte #code: Fill Byte fill byte used to fill 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. The main difference (since version 4.2.8) are the addresses stored in hex files. Target RAM stores addresses based on the origin of each segment while ROM stores consecutive addresses starting at $0000 suitable for an eprom burner. ##### #target ROM This is also the default target Assembler directives: #if, #elif, #else, #endif Pseudo instructions: if, endif if no target is Pseudo instructions: defl, set and '=' Labels: SET set, e.g. in legacy source. This file is a plain rom or eprom image intended to be used with an eprom burner. The default #code: Fill Byte #code: Fill Byte fill byte for .defs and for padding segments is $FF. Multiple code segments are simply concatenated to create the binary output file. Hex files are also created by simply concatenating all code segments. The padding at the Pseudo instructions: end, .end 8080 pseudo instructions: END end of each segment (Assembler directives: #if, #elif, #else, #endif Pseudo instructions: if, endif if any) is not stored. The addresses in the hex files start at $0000 and define the code storage position in the eprom or memory file, suitable for use by an eprom burner. #target ROM files can include multiple segments mapping to the same cpu address. (paging)
    #target rom
    Assembler directives: #code
    Including C Source Files: #code#code   <name>,<start>,<size>
            ...
#insert: Examples: #assert: Example: incbin: Examples: #assert: Example: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 at address $C000:
    #target rom
    Assembler directives: #code
    Including C Source Files: #code#code   PAGE1, $C000, $4000
            ...
    Assembler directives: #code
    Including C Source Files: #code#code   PAGE2, $C000, $4000
            ...
##### #target RAM until version 4.2.7: Target RAM behaves identical to target ROM except for the default #code: Fill Byte #code: Fill Byte fill byte which is is $00. since version 4.2.8: This file is a plain memory dump intended to be loaded by a ram loader on the target system. The default #code: Fill Byte #code: Fill Byte fill byte for .defs and for padding segments is $00. Binary files for ROM and RAM are identical except for the default fill pattern: multiple code segments are simply concatenated. Hex files are created by simply concatenating all code segments. The padding at the Pseudo instructions: end, .end 8080 pseudo instructions: END end of each segment (Assembler directives: #if, #elif, #else, #endif Pseudo instructions: if, endif if any) is not stored. Addresses in hex files are based on the origins of the Assembler directives: #code Including C Source Files: #code#code segments, making it suitable for a ram loader. Cave at: Multiple segments are loaded differently for binary and hex files! A binary file is just a concatenation of all segments in order of definition in the source file, disregarding the segment start addresses. Eventually the segments are copied to their final position by the bootstrap code. A hex file will most likely be directly loaded to the final position by a ram loader using the addresses in the hex file, even Assembler directives: #if, #elif, #else, #endif Pseudo instructions: if, endif if segments are defined in arbitrary order or with unused space between them.
    #target ram
    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 RAM and ROM targets can be written in the Intel Hex format. These files look like this:
    :200000003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED787B
    :090020000F0F30FADB70321027DB
    :00000001FF
Trailing #code: Fill Byte #code: Fill Byte fill bytes (0xFF for ROM and 0x00 for RAM) 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. Therefore the target system should erase the ram to 0x00 before downloading a hex file. Eproms must be erased before they can be burned and they are erased to 0xFF. That's why the #code: Fill Byte #code: Fill Byte 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 RAM and ROM targets can be written in the Motorola S-Record format. These files look like this:
    S00F00007320323031352D30312D313178
    S12C00003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED780F0F30FADB7032102772
    S5030001FB
    S9030000FC
Trailing #code: Fill Byte #code: Fill Byte fill bytes are handled as for the Intel hex format. |

[<prev] [top] [next>]