File Formats - Revision history

Foenix at 01:35, 3 February 2024

2024-02-03T01:35:58Z

← Older revision		Revision as of 21:35, 2 February 2024
Line 117:		Line 117:


	~~<nowiki>~~== PGZ ==~~</nowiki>~~		== PGZ (more details) ==

	(More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)		(More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)

Foenix: /* PGZ */

2024-02-03T01:35:00Z

PGZ

← Older revision		Revision as of 21:35, 2 February 2024
Line 116:		Line 116:
	<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md		<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md

	<nowiki>== PGZ ~~(better explanation)~~ ==</nowiki>
			<nowiki>== PGZ ==</nowiki>

	(More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)		(More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)

Foenix: /* PGZ */

2024-02-03T01:34:33Z

PGZ

← Older revision		Revision as of 21:34, 2 February 2024
Line 116:		Line 116:
	<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md		<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md

	== PGZ == (More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)		<nowiki>== PGZ (better explanation) ==</nowiki>

			(More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)

	PGZ is a multi-segment file format that can load data into multiple areas in memory. The format is derived from binary format used by Western Design Center's C compiler.		PGZ is a multi-segment file format that can load data into multiple areas in memory. The format is derived from binary format used by Western Design Center's C compiler.

Foenix: /* PGZ */

2024-02-03T01:33:52Z

PGZ

← Older revision		Revision as of 21:33, 2 February 2024
Line 115:		Line 115:

	<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md		<br />''Original Information Source:'' https://github.com/FoenixRetro/Documentation/blob/main/f256/programming-file-formats.md

			== PGZ == (More Complete Explanation ) - To be Re-Edited to form only one clear explanation of what the PGZ file format does. (This is the explanation coming from wiki.c256foenix.com)

			PGZ is a multi-segment file format that can load data into multiple areas in memory. The format is derived from binary format used by Western Design Center's C compiler.

			* The first byte of the PGZ format is the ASCII code for "Z". This serves as the file type signature.
			<span style="color:red">* Big "Z" = 24bits Addresse Pointers and Sizes. Small "z" = 32bits Addresse Pointers and Sizes.</span>
			* Next comes any number of segments, each following right after the previous segment with no separator. Each segment has the following format:
			** Three bytes of address, in little endian format. This is the starting address for writing the data of the segment.
			** Three bytes indicating the size of the segment, in little endian format.
			** The bytes of data in the segment (same number of bytes as specified in the size).
			* If final segment has a size of $000000 and no data bytes, then address specifies the starting address of the executable.

			{\| class="wikitable"
			! Segment !! Offset !! Count !! Example !! Purpose
			\|-
			\| N/A \|\| 0 \|\| 1 \|\| "Z" \|\| Signature
			\|-
			\|rowspan="3"\| 1 \|\| 1 \|\| 3 \|\| $010000 \|\| Address of segment #1
			\|-
			\| 4 \|\| 3 \|\| $000009 \|\| Size of segment #1
			\|-
			\| 7 \|\| ... \|\| ... \|\| Data of Segment #1
			\|-
			\|rowspan="3"\| 2 \|\| 16 \|\| 3 \|\| $020000 \|\| Address of segment #2
			\|-
			\| 19 \|\| 3 \|\| $000008 \|\| Size of segment #2
			\|-
			\| 22 \|\| ... \|\| ... \|\| Data of Segment #2
			\|-
			\|rowspan="2"\| 3 \|\| 30 \|\| 3 \|\| $010000 \|\| Starting address
			\|-
			\| 33 \|\| 3 \|\| $000000 \|\| 0 to indicate start address
			\|}

Draconian: /* PGX */

2024-01-12T22:19:38Z

PGX

← Older revision		Revision as of 18:19, 12 January 2024
Line 80:		Line 80:
	* The first three bytes are the ASCII codes for “PGX”.		* The first three bytes are the ASCII codes for “PGX”.
	* The fourth byte is the CPU and version identification byte. Bits 0 through 3 represent the CPU code, and bits 4 through 7 represent the version of PGX supported. At the moment, there is just version 0. The CPU code can be 1 for the WDC65816, or 3 for the 65c02.		* The fourth byte is the CPU and version identification byte. Bits 0 through 3 represent the CPU code, and bits 4 through 7 represent the version of PGX supported. At the moment, there is just version 0. The CPU code can be 1 for the WDC65816, or 3 for the 65c02.
	* The next four bytes (that is, bytes 4 through 7) are the address of the destination, in little-endian format (~~most~~ significant byte first). This address is both the address of the location in which to load the first byte of the data and is also the starting address for the file.		* The next four bytes (that is, bytes 4 through 7) are the address of the destination, in little-endian format (least significant byte first). This address is both the address of the location in which to load the first byte of the data and is also the starting address for the file.

	All bytes after the header are the contents of the file to be loaded into memory.		All bytes after the header are the contents of the file to be loaded into memory.

Draconian: PGX - fix CPU code and little-endian format

2024-01-12T22:18:51Z

PGX - fix CPU code and little-endian format

← Older revision		Revision as of 18:18, 12 January 2024
Line 79:		Line 79:

	* The first three bytes are the ASCII codes for “PGX”.		* The first three bytes are the ASCII codes for “PGX”.
	* The fourth byte is the CPU and version identification byte. Bits 0 through 3 represent the CPU code, and bits 4 through 7 represent the version of PGX supported. At the moment, there is just version 0. The CPU code can be 1 for the WDC65816, or 2 for the ~~M680x0~~.		* The fourth byte is the CPU and version identification byte. Bits 0 through 3 represent the CPU code, and bits 4 through 7 represent the version of PGX supported. At the moment, there is just version 0. The CPU code can be 1 for the WDC65816, or 3 for the 65c02.
	* The next four bytes (that is, bytes 4 through 7) are the address of the destination, in ~~big~~-endian format (most significant byte first). This address is both the address of the location in which to load the first byte of the data and is also the starting address for the file.		* The next four bytes (that is, bytes 4 through 7) are the address of the destination, in little-endian format (most significant byte first). This address is both the address of the location in which to load the first byte of the data and is also the starting address for the file.

	All bytes after the header are the contents of the file to be loaded into memory.		All bytes after the header are the contents of the file to be loaded into memory.

93.38.25.121: /* PGX */

2024-01-06T19:12:38Z

PGX

← Older revision		Revision as of 15:12, 6 January 2024
Line 73:		Line 73:
	This format is a simple, single segment executable, which can be loaded as low as $0200. A PGX is loaded using <code>pexec</code>. <code>pexec</code> treats PGX and PGZ in exactly the same way, and information on how PGZ is handled also applies to PGX.		This format is a simple, single segment executable, which can be loaded as low as $0200. A PGX is loaded using <code>pexec</code>. <code>pexec</code> treats PGX and PGZ in exactly the same way, and information on how PGZ is handled also applies to PGX.

	~~PGZ~~ is similar in scale to MS-DOS’s COM format, or the Commodore PRG format. It consists of a single segment of data to be loaded to		PGX is similar in scale to MS-DOS’s COM format, or the Commodore PRG format. It consists of a single segment of data to be loaded to
	a specific address, where that address is also the starting address.		a specific address, where that address is also the starting address.

Draconian: update the KUP header sample

2023-12-22T19:53:28Z

update the KUP header sample

← Older revision		Revision as of 15:53, 22 December 2023
Line 19:		Line 19:
	Byte 1 signature: $56		Byte 1 signature: $56
	Byte 2 the size of program in 8k blocks		Byte 2 the size of program in 8k blocks
	Byte 3 the starting slot of the program (ie where to map it)		Byte 3 the starting slot of the program (i.e. where to map it)
	Bytes 4-5 the start address of the program		Bytes 4-5 the start address of the program
	Byte 6 header structure version (indicates version of header, current 0 or 1)		Byte 6 header structure version (indicates version of header, current 0 or 1)
	Bytes 7-9 reserved		Bytes 7-9 reserved
	Bytes ?-? zero-terminated name of the program.		Bytes 10-? zero-terminated name of the program.
	Bytes ?-? zero-terminated string describing the arguments. (in version >= 1)		Bytes ?-? zero-terminated string describing the arguments. (in version >= 1)
	Bytes ?-? zero-terminated string describing the program's function. (in version >= 1)		Bytes ?-? zero-terminated string describing the program's function. (in version >= 1)

Draconian: definition for KUP

2023-12-22T19:47:20Z

definition for KUP

← Older revision		Revision as of 15:47, 22 December 2023
Line 8:		Line 8:
	Binary images should only be used by the developer while developing, as it is a very user-unfriendly method of distributing software, requiring tethering to a PC or Mac.		Binary images should only be used by the developer while developing, as it is a very user-unfriendly method of distributing software, requiring tethering to a PC or Mac.

	== KUP ==		== KUP - Kernel User Program ==
	KUPs are very simple and can contain 40 KiB code/data when run from flash, or 32 KiB when run from disk. Contained in their header is an entry point address, and the slot number of where they should be mapped into, the first possible slot being #1 ($2000).		KUPs are very simple and can contain 40 KiB code/data when run from flash, or 32 KiB when run from disk. Contained in their header is an entry point address, and the slot number of where they should be mapped into, the first possible slot being #1 ($2000).

Draconian at 07:09, 18 December 2023

2023-12-18T07:09:18Z

← Older revision		Revision as of 03:09, 18 December 2023
Line 9:		Line 9:

	== KUP ==		== KUP ==
	KUPs are very simple and can contain 40 KiB code/data when run from flash, or 32 KiB when run from disk. Contained in their header is ~~and~~ entry point address, and the slot number of where they should be mapped into, the first possible slot being #1 ($2000).		KUPs are very simple and can contain 40 KiB code/data when run from flash, or 32 KiB when run from disk. Contained in their header is an entry point address, and the slot number of where they should be mapped into, the first possible slot being #1 ($2000).

	DOS expands on the KUP header defined by the MicroKernel in a backwards compatible way.		DOS expands on the KUP header defined by the MicroKernel in a backwards compatible way.