|
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 Bytefill byte used to fill gaps, e.g. in the 'defs' Pseudo instructions
8080 Assembler: 8080 pseudo instructionspseudo 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.
This is also the default target Assembler directives: #if, #elif, #else, #endif
Pseudo instructions: if, endifif no target is Pseudo instructions: defl, set and '='
Labels: SETset, 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 Bytefill 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: ENDend of each segment (Assembler directives: #if, #elif, #else, #endif
Pseudo instructions: if, endifif 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 Z80Z80 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
...
until version 4.2.7:
Target RAM behaves identical to target ROM except for the default #code: Fill Byte
#code: Fill Bytefill 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 Bytefill 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: ENDend of each segment (Assembler directives: #if, #elif, #else, #endif
Pseudo instructions: if, endifif 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, endifif 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>
...
Using Differences from v3 to v4: Command line options
Command Line Options
Command Line Options: Command line optionscommand 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 Bytefill 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 Bytefill byte for ROM is 0xFF.
Using Differences from v3 to v4: Command line options
Command Line Options
Command Line Options: Command line optionscommand 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 Bytefill bytes are handled as for the Intel hex format.
| 
