h3	#target RAM (old: BIN) and ROM
	bin, ram, rom

p	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 fill byte used to fill gaps, e.g. in the 'defs' pseudo instruction or for the padding at the and of a #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.

h5	#target ROM

p	This is also the default target if no target is set, e.g. in legacy source.
p	This file is a plain rom or eprom image intended to be used with an eprom burner.
p	The default fill byte for .defs and for padding segments is $FF.
p	Multiple code segments are simply concatenated to create the binary output file.
p	Hex files are also created by simply concatenating all code segments.
	The padding at the end of each segment (if any) is not stored.
	<b>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.</b>
p	#target ROM files can include multiple segments mapping to the same cpu address. (paging)

pre	#target	rom
	#code	<name>,<start>,<size>
			...

p	Example for a rom which is paged into the Z80 address space in 2 pages at address $C000:

pre	#target	rom
	#code	PAGE1, $C000, $4000
			...
	#code	PAGE2, $C000, $4000
			...


h5	#target RAM

p.i until version 4.2.7:

p	Target RAM behaves identical to target ROM except for the default fill byte which is is $00.

p.i	since version 4.2.8:

p	This file is a plain memory dump intended to be loaded by a ram loader on the target system.
p	The default fill byte for .defs and for padding segments is $00.
p	Binary files for ROM and RAM are identical except for the default fill pattern:
	multiple code segments are simply concatenated.
p	Hex files are created by simply concatenating all code segments.
	The padding at the end of each segment (if any) is not stored.
	<b>Addresses in hex files are based on the origins of the #code segments, making it suitable for a ram loader.</b>

p.b	Cave at: Multiple segments are loaded differently for binary and hex files!

p	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.

p	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 if segments are defined in arbitrary order or with unused space between them.

pre	#target	ram
	#code	<name>,<start>,<size>
			...


h5	Writing Intel Hex files

p	Using command line option '-x' the RAM and ROM targets can be written in the Intel Hex format. These files look like this:

pre	:200000003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED787B
	:090020000F0F30FADB70321027DB
	:00000001FF

p	Trailing 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 fill byte for ROM is 0xFF.

h5 	Writing Motorola S-Record format

p	Using command line option '-s' the RAM and ROM targets can be written in the Motorola S-Record format. These files look like this:

pre	S00F00007320323031352D30312D313178
	S12C00003E00ED79ED79ED793E40ED793EDAED793E37ED79ED780F30FB3A1027D370ED780F0F30FADB7032102772
	S5030001FB
	S9030000FC

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