Format:Xexor ARC file format - Revision history

MacDeath at 19:20, 17 December 2010

2010-12-17T19:20:33Z

← Older revision		Revision as of 19:20, 17 December 2010
Line 1:		Line 1:
			[[Category:Cpctech.org]]
	<div style="border: 1px solid rgb(228, 222, 222); margin: 0px 0px 5px; padding: 0.5em 1em; background-color: rgb(249, 249, 249);"><center>'''''This article originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].'''''</center></div>		<div style="border: 1px solid rgb(228, 222, 222); margin: 0px 0px 5px; padding: 0.5em 1em; background-color: rgb(249, 249, 249);"><center>'''''This article originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].'''''</center></div>

Executioner: /* Structure of the "ARC" file */

2009-09-28T00:43:10Z

Structure of the "ARC" file

← Older revision		Revision as of 00:43, 28 September 2009
Line 69:		Line 69:
	If the image is double-sided, alternate heads are stored for each cylinder.		If the image is double-sided, alternate heads are stored for each cylinder.

	ARC files written by older versions of Xexor have the following header (ie. XA missing):		ARC files written by older versions of Xexor have the following header (ie. XA and DDB missing):

	{\| border="1"		{\| border="1"

Executioner: /* Structure of the "ARC" file */ Added Drive Definition Byte information

2009-09-28T00:42:11Z

Structure of the "ARC" file: Added Drive Definition Byte information

@@ Line 38: / Line 38: @@
 |-
 | 1
-| 0
+| Drive Definition Byte
 |-
 | 1
@@ Line 47: / Line 47: @@
 |}
-ARC files written by Xexor have the following header:
+The drive definition byte is as follows:
 {| border="1"

Executioner: /* Structure of the "ARC" file */

2009-09-28T00:33:27Z

Structure of the "ARC" file

← Older revision		Revision as of 00:33, 28 September 2009
Line 139:		Line 139:
	\|-		\|-
	\| 14		\| 14
	\| Sector has Deleted Data Address Mark (DDAM)		\| Sector has Deleted Data Address Mark if set (DDAM)
	\|-		\|-
	\| 13		\| 13
	\| Sector data is present (not empty)		\| Sector data is present if set (not empty)
	\|}		\|}

			Sector data is also assumed to be present if bit 14 is set, regardless of bit 13.

	== Compression scheme ==		== Compression scheme ==

Executioner: /* Structure of the "ARC" file */ Clarified Sector Size and Flags

2009-09-28T00:32:17Z

Structure of the "ARC" file: Clarified Sector Size and Flags

← Older revision		Revision as of 00:32, 28 September 2009
Line 115:		Line 115:
	! Description		! Description
	\|-		\|-
	\| 1		\| 2
	\| Flags?		\| Sector Size and Flags
	\|-		\|-
	\| 1		\| ?
	~~\| Flags?~~
	\|-
	~~\|  ~~?
	\| Compressed sector data		\| Compressed sector data
	\|}		\|}

	~~9 means same byte for entire~~ sector~~? 80~~ is the ~~byte? then there~~ is no compressed ~~sector~~ data		The Sector Size and Flags are stored as a word (LSB first), containing the stored data length (when not empty), compression flag, and deleted data address mark.

			The top 3 bits of the Size are flags, with the bottom 13 bits containing the size of the stored data (when not empty).

			A sector which does not have a deleted data address mark and contains only E5 bytes is considered empty. In this case, the top 3 bits will be 100 and the size is ignored. WinAPE stores this as #8009, but it could be any value from #0000 to #1FFF or #8000 to #9FFF.

			For all other sectors:

			{\| border="1"
			\|-
			! Bit
			! Description
			\|-
			\| 15
			\| RLE compressed if set (see below)
			\|-
			\| 14
			\| Sector has Deleted Data Address Mark (DDAM)
			\|-
			\| 13
			\| Sector data is present (not empty)
			\|}

	== Compression scheme ==		== Compression scheme ==

Prodatron at 22:44, 15 January 2009

2009-01-15T22:44:20Z

← Older revision		Revision as of 22:44, 15 January 2009
Line 1:		Line 1:
	'''''This ~~artikel~~ originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].'''''		<div style="border: 1px solid rgb(228, 222, 222); margin: 0px 0px 5px; padding: 0.5em 1em; background-color: rgb(249, 249, 249);"><center>'''''This article originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].'''''</center></div>

	= The Xexor ARC file format =		= The Xexor ARC file format =

	Xexor is a powerful disc utility written by Richard Wilson for the Amstrad CPC/CPC+.		Xexor is a powerful disc utility written by Richard Wilson for the Amstrad CPC/CPC+.
Line 17:		Line 17:
	This will create a file called "disc.arc" which will contain the data from tracks 1 to 13 inclusive.		This will create a file called "disc.arc" which will contain the data from tracks 1 to 13 inclusive.

	== Structure of the "ARC" file ==		== Structure of the "ARC" file ==

	The "ARC" file is a binary file and will have an AMSDOS header.		The "ARC" file is a binary file and will have an AMSDOS header.
Line 127:		Line 127:
	9 means same byte for entire sector? 80 is the byte? then there is no compressed sector data		9 means same byte for entire sector? 80 is the byte? then there is no compressed sector data

	== Compression scheme ==		== Compression scheme ==

	The compression method is "run length encoding".		The compression method is "run length encoding".

Prodatron: New page: '''''This artikel originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].''''' = The Xexor ARC file format = Xexor is a powerful disc util...

2009-01-15T22:16:57Z

New page: '''''This artikel originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].''''' = The Xexor ARC file format = Xexor is a powerful disc util...

New page

'''''This artikel originally came from Kevin Thackers' archive at [http://www.cpctech.org.uk http://www.cpctech.org.uk].'''''

= The Xexor ARC file format =

Xexor is a powerful disc utility written by Richard Wilson for the Amstrad CPC/CPC+.

This document describes the structure of the "ARC" file written by the "ARCHIVE" command of this utility program and his Winape emulator.

The syntax of the archive command is:

<nowiki>|ARCHIVE <filename> <track range> </nowiki>

An example of it's usage is:

<nowiki>|ARCHIVE "disc.arc" 1-13</nowiki>

This will create a file called "disc.arc" which will contain the data from tracks 1 to 13 inclusive.

== Structure of the "ARC" file ==

The "ARC" file is a binary file and will have an AMSDOS header.

In addition, "ARC" files written by the Winape emulator have a different header.

If you are reading an "ARC" file into an emulator be aware that there may be an AMSDOS header, and that the file may have been created by Winape.

The ARC file data starts with a header which describes the start and end range of tracks stored in the file:

ARC files written by Winape have the following header:

{| border="1"
|-
! Length
! Description
|-
| 2
| 'XA' identifier
|-
| 1
| 0
|-
| 1
| First track
|-
| 1
| Last track
|}

ARC files written by Xexor have the following header:

{| border="1"
|-
! Length
! Description
|-
| 1
| First track
|-
| 1
| Last track
|}

Following this is the data for each track, starting with the first track, in ascending numeric order. All tracks between the first track and last track are stored in the file. No tracks may be omitted.

The length of data for each track varies and is dependant on the number of sectors in the track. Each track has the same header layout which gives the number of tracks, and the IDs of these sectors.

The data for each sector is stored in the order given by the sector IDs.

i.e. if there are 9 sectors per track and the sector IDS are listed as &C1,&C2,&C3, &C4,&C5,&C6,&C7,&C8 and &C9, then the data for sector &C1 will be first, and this will be followed by the data for sector &C2 and so on until sector &C9.

The data for each sector is compressed seperatly using a run-length encoding method.

Track data:

{| border="1"
|-
! Length
! Description
|-
| 1
| Number of sectors
|-
| 4*Number of sectors
| Sector ID information (see below)
|-
|  ?
| Sector data (see below)
|}

Sector ID information:

{| border="1"
|-
! Length
! Description
|-
| 1
| C from ID field
|-
| 1
| H from ID field
|-
| 1
| R from ID field
|-
| 1
| N from ID field
|}

Sector data:

{| border="1"
|-
! Length
! Description
|-
| 1
| Flags?
|-
| 1
| Flags?
|-
|  ?
| Compressed sector data
|}

9 means same byte for entire sector? 80 is the byte? then there is no compressed sector data

== Compression scheme ==

The compression method is "run length encoding".

"run length encoding" is a simple compression algorithm which can compress sequences of the same repeated byte.

The compressed will contain single data bytes and run-length packets.

A "marker" byte of &E5 is used to identify a run-length packet. (&E5 is the byte used to fill empty sectors when a disc is formatted to the standard SYSTEM, DATA and IBM formats).

Run-length packets:

{| border="1"
|-
! Byte sequence
! Result
|-
| &E5,&00
| Output a single &E5 byte
|-
| &E5,<count>,<data>
| Output the byte <data> <count> times. e.g. &E5,&03,&25 -> &25,&25,&25
|-
| <value>
| <value> must not be &E5. Output <value> once
|}