Changes
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...
'''''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
|}
= 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
|}
