mirror of
https://github.com/aaru-dps/docs.git
synced 2025-12-16 11:14:37 +00:00
Add correct dsk and extdsk docs
This commit is contained in:
Damien Guard
313
dsk.html
313
dsk.html
@@ -1,9 +1,304 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
|
||||
<html lang="en">
|
||||
<head><title>Unofficial Amstrad WWW Resource</title>
|
||||
<meta name="Keywords" content="amstrad,arnold,amstrad cpc,cpc,gx4000,cpc+,cpcplus,schneider,cpc464,cpc664,cpc6128,cpc464+,cpc6128+,464+,6128+,464plus,6128plus,kcc,kccompact,kc compact"><meta name="Author" content="Kevin Thacker"><meta name="Description" content="The main page of the web site dedicated to the Amstrad CPC464, CPC664, CPC6128, CPC464+, CPC6128+, GX4000 and VEB Mikroelectronic KC Compact"></head>
|
||||
<frameset rows="100%">
|
||||
<frame title="http://cpctech.cpc-live.com/docs/dsk.html" src="http://cpctech.cpc-live.com/docs/dsk.html" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
|
||||
<noframes>Sorry, you don"t appear to have frame support.
|
||||
Go here instead - <a href="http://cpctech.cpc-live.com/docs/dsk.html">Unofficial Amstrad WWW Resource</a></noframes>
|
||||
</frameset>
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>Disk image file format</title>
|
||||
<link rel="stylesheet" type="text/css" href="../arnold.css">
|
||||
<meta name="description" content="A description of the standard .DSK disk image file structure">
|
||||
<meta name="uawww-category" content="docs-emulation-file_formats">
|
||||
<meta http-equiv="Content-Language" content="en-gb">
|
||||
<base href="http://www.cpctech.org.uk" target="_parent" /></head>
|
||||
<body>
|
||||
<h1>Disk image file format</h1>
|
||||
|
||||
<p>This document describes the standard disk image format. It has the file
|
||||
extension ".DSK".
|
||||
|
||||
<h2>Disc Information block</h2>
|
||||
|
||||
<p>The "Disc Information block" is always at offset 0 in the disk image file.
|
||||
If track data exists, then this will immediatly follow the Disc Information Block and will start at
|
||||
offset &100 in the disc image file.
|
||||
|
||||
<p>The "Disc Information block" has the following structure:
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<td>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00-21</td>
|
||||
<td>"MV - CPCEMU Disk-File\r\nDisk-Info\r\n"</td>
|
||||
<td>34</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>22-2f</td>
|
||||
<td>name of creator</td>
|
||||
<td>14</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>30</td>
|
||||
<td>number of tracks</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>31</td>
|
||||
<td>number of sides</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>32-33</td>
|
||||
<td>size of a track
|
||||
(little endian; low byte followed by high byte)</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>34-ff</td>
|
||||
<td>not used (0)</td>
|
||||
<td>204</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>Notes:
|
||||
<ul>
|
||||
<li>Track 0 (or Track 0 side 0 for double sided disks) immediatly follows the Disk Information Block, and is at offset
|
||||
&100 in the disk image.
|
||||
<li>"MV - CPC" must be present, because it is used to identify the
|
||||
file as a disk image. It is sufficient to check this to identify
|
||||
the file as being a disk image.
|
||||
<li>"\r" is the C programming language equivalent of ASCII character 13.
|
||||
<li>"\n" is the C programming language equivalent of ASCII character 10.
|
||||
<li><b>All</b> tracks must be the same size.
|
||||
<li>"size of track" is used to calculate the location of the data for a chosen track.
|
||||
<li>"size of track" includes the &100 byte Track Information Block.
|
||||
<li><b>All</b> tracks must have a "Track Information Block"
|
||||
<li>track lengths are stored in the same order as the tracks in the image
|
||||
e.g. In the case of a double sided disk: Track 0 side 0, Track 0 side 1, Track
|
||||
1 side 0 etc...
|
||||
<li>The track blocks are stored in increasing order 0..number of tracks, with alternating
|
||||
sides interleaved if the disc image describes a double sided disk.
|
||||
e.g. if the disk image represents a double sided disk, the order of tracks is:
|
||||
track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 1.... track (number of tracks-1) side 0,
|
||||
track (number of tracks-1) side 1
|
||||
<p>The tracks are <b>always</b> ordered in this way regardless of the disc-format described by the disc
|
||||
image.
|
||||
<li>A standard disk image can be used to describe a copy-protected disk, but will often result in a file
|
||||
which is larger than the same disk described by a extended disk image. For a standard disk image to represent
|
||||
a copy-protected disk:
|
||||
<ul><li>All track sizes in the standard disk image must be the same. This value therefore would be the size of the largest track, and other tracks would have unused space
|
||||
in them.
|
||||
<li>All sector sizes within each track must be the same size, but not necessarily the same size as the sectors for another track. If a track contained different sized sectors,
|
||||
the size of the largest sector should be used. This would result in some wasted space.
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
|
||||
<h2>Track Information Block</h2>
|
||||
|
||||
<p>Each Track Block comprises a Track Information Block and sector data.
|
||||
The sector data is always at an offset of &100 bytes from the start of the
|
||||
track block. The data for the next track in the disc image immediatly
|
||||
follows the data for the current track.
|
||||
|
||||
<p>The first Track Block is located at offset &100 in the disk image file.
|
||||
The track block starts with the Track Information Block and has this form.
|
||||
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00 - 0c</td>
|
||||
<td>"Track-Info\r\n"</td>
|
||||
<td>13</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>0d - 0f</td>
|
||||
<td>unused</td>
|
||||
<td>3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10</td>
|
||||
<td>track number</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>11</td>
|
||||
<td>side number</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>12 - 13</td>
|
||||
<td>unused</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>14</td>
|
||||
<td>sector size</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>15</td>
|
||||
<td>number of sectors</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>16</td>
|
||||
<td>GAP#3 length</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>17</td>
|
||||
<td>filler byte</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>18 - xx</td>
|
||||
<td>Sector Information List</td>
|
||||
<td>xx</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Notes:
|
||||
<ul>
|
||||
<li>"number of sectors" is used to identify the number of valid entries
|
||||
in the sector information list.
|
||||
<li>"sector size" parameter is used to calculate the location of each sector's data.
|
||||
Therefore, The data allocated for each sector must be the same.
|
||||
<p>If the track contains different sized sectors, then the data allocated must be the size
|
||||
of the biggest sector. The "sector size" parameter is used to calculate
|
||||
the location of the sector data.
|
||||
<li>Sector data always follows Track Information Block at offset &100 from the start
|
||||
of the track information block.
|
||||
<li>Sector data is stored in the same order as the sectors in the sector info block.
|
||||
</ul>
|
||||
|
||||
<h3>Sector info</h3>
|
||||
|
||||
|
||||
<table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00</td>
|
||||
<td>track (equivalent to C parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>01</td>
|
||||
<td>side (equivalent to H parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>02</td>
|
||||
<td>sector ID (equivalent to R parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>03</td>
|
||||
<td>sector size (equivalent to N parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>04</td>
|
||||
<td>FDC status register 1 (equivalent to NEC765 ST1 status register)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>05</td>
|
||||
<td>FDC status register 2 (equivalent to NEC765 ST2 status register)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>06 - 07</td>
|
||||
<td>notused (0)</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Notes:
|
||||
<ul>
|
||||
<li>The following bits are used from NEC765 status register 1:
|
||||
<ul>
|
||||
<li>b7 EN (End of Cylinder)
|
||||
<li>b5 DE (Data Error)
|
||||
<li>b2 ND (No Data)
|
||||
<li>b0 MA (Missing Address Mark)
|
||||
</ul>
|
||||
<li>The following bits are used from NEC765 status register 2:
|
||||
<ul>
|
||||
<li>b5 CM (Control Mark)
|
||||
<li>b5 DD (Data Error in Data field)
|
||||
<li>b0 MD (Missing address Mark in Data field)
|
||||
</ul>
|
||||
<li>For 8k Sectors (N="6"), only 1800h bytes is stored.
|
||||
</ul>
|
||||
|
||||
<h2>General format</h2>
|
||||
|
||||
<h3>Single sided DSK images</h3>
|
||||
|
||||
<ul>
|
||||
<li>Disc Information Block
|
||||
<li>Track 0 data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
<li>Track 1 data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
.
|
||||
.
|
||||
.
|
||||
.
|
||||
<li>Track (number_of_tracks-1) data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<h3>Double sided DSK images</h3>
|
||||
|
||||
<ul>
|
||||
<li>Disc Information Block
|
||||
<li>Track 0 side 0 data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
<li>Track 0 side 1 data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
.
|
||||
.
|
||||
.
|
||||
.
|
||||
<li>Track (number_of_tracks-1) side 1 data
|
||||
<ul>
|
||||
<li>Track Information Block
|
||||
<li>Sector data
|
||||
</ul>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
419
extdsk.html
419
extdsk.html
@@ -1,9 +1,410 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
|
||||
<html lang="en">
|
||||
<head><title>Unofficial Amstrad WWW Resource</title>
|
||||
<meta name="Keywords" content="amstrad,arnold,amstrad cpc,cpc,gx4000,cpc+,cpcplus,schneider,cpc464,cpc664,cpc6128,cpc464+,cpc6128+,464+,6128+,464plus,6128plus,kcc,kccompact,kc compact"><meta name="Author" content="Kevin Thacker"><meta name="Description" content="The main page of the web site dedicated to the Amstrad CPC464, CPC664, CPC6128, CPC464+, CPC6128+, GX4000 and VEB Mikroelectronic KC Compact"></head>
|
||||
<frameset rows="100%">
|
||||
<frame title="http://cpctech.cpc-live.com/docs/extdsk.html" src="http://cpctech.cpc-live.com/docs/extdsk.html" name="mainframe" frameborder="0" noresize="noresize" scrolling="auto">
|
||||
<noframes>Sorry, you don"t appear to have frame support.
|
||||
Go here instead - <a href="http://cpctech.cpc-live.com/docs/extdsk.html">Unofficial Amstrad WWW Resource</a></noframes>
|
||||
</frameset>
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||||
<html><head>
|
||||
<title>Extended DiSK Image definition</title>
|
||||
<meta name="description" content="Description of the EXTENDED .DSK disk image file structure (.DSK)">
|
||||
<link rel="stylesheet" type="text/css" href="../arnold.css">
|
||||
<meta name="uawww-category" content="docs-emulation-file_formats">
|
||||
<meta http-equiv="Content-Language" content="en-gb">
|
||||
<base href="http://www.cpctech.org.uk" target="_parent" /></head><body>
|
||||
<h1>Extended DSK image definition</h1>
|
||||
|
||||
<p>The extended DSK image is a file designed to describe copy-protected floppy disk software.
|
||||
It's definition was defined by Marco Vieth, Ulrich Doewich and Kevin Thacker.
|
||||
<p>This format has been widely adopted and is one of the major file formats
|
||||
used (the other major format is the standard disk image with the "MV - CPC" identifier).
|
||||
<p>The extended disk image format should be used for copy-protected disc software,
|
||||
or in place of a standard disk image if the resulting image is smaller than in the standard
|
||||
disk image form.
|
||||
|
||||
<h2>Extended DiSK Format (Rev.5)</h2>
|
||||
|
||||
<p>The disc image has the following format:
|
||||
|
||||
<table border="1" >
|
||||
<tr>
|
||||
<td>DISK INFORMATION BLOCK (256 bytes)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TRACK INFORMATION BLOCK * number of tracks * number of sides</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>The track blocks are stored in increasing order 0..number of tracks, with alternating
|
||||
sides interleaved if the disc image describes a double sided disk.
|
||||
e.g. if the disk image represents a double sided disk, the order of tracks is:
|
||||
track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 1.... track (number of tracks-1) side 0,
|
||||
track (number of tracks-1) side 1
|
||||
<p>The tracks are <b>always</b> ordered in this way regardless of the disc-format described by the disc
|
||||
image.
|
||||
<p>The location of the track information block is found by using the track size table.
|
||||
<h2>DISK INFORMATION BLOCK</h2>
|
||||
|
||||
<p>The "DISK INFORMATION BLOCK" is always located at offset 0 in the disk image file, and has
|
||||
the following structure:
|
||||
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<td>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00 - 21</td>
|
||||
<td>"EXTENDED CPC DSK File\r\nDisk-Info\r\n"</td>
|
||||
<td>34</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>22 - 2f</td>
|
||||
<td>name of creator (utility/emulator)</td>
|
||||
<td>14</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>30</td>
|
||||
<td>number of tracks</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>31</td>
|
||||
<td>number of sides</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>32 - 33</td>
|
||||
<td>unused</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>34 - xx</td>
|
||||
<td>track size table</td>
|
||||
<td>number of tracks*number of sides</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>NOTES:
|
||||
<ul>
|
||||
<li>An extended DSK image is identified by the "EXTENDED" tag. The
|
||||
track size at offset 32h and 33h, used by the STANDARD disk image
|
||||
is ignored for extended format DSK images.
|
||||
<li>If track data exists, then it starts at offset 100h.
|
||||
<li>The "EXTENDED" tag is present to prevent existing emulators
|
||||
which support the standard DSK image from interpreting the data
|
||||
wrong and possibly crashing.
|
||||
<li>"\r" is the C programming language equivalent of ASCII character 13.
|
||||
<li>"\n" is the C programming language equivalent of ASCII character 10.
|
||||
</ul>
|
||||
|
||||
|
||||
<h2>TRACK OFFSET TABLE</h2>
|
||||
|
||||
<table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>01</td>
|
||||
<td>high byte of track 0 length (equivalent to track length/256)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>...</td>
|
||||
<td>...</td>
|
||||
<td>...</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>NOTES:
|
||||
<ul>
|
||||
<li>Depending on the information in the disk information block, the table contains
|
||||
<ul>
|
||||
<li>track lengths for a single sided floppy disc
|
||||
<li>track lengths for a double sided floppy disc
|
||||
</ul>
|
||||
<li>track lengths are stored in the same order as the tracks in the image
|
||||
e.g. In the case of a double sided disk: Track 0 side 0, Track 0 side 1, Track
|
||||
1 side 0 etc...
|
||||
<li>A size of "0" indicates an unformatted track. In this case there is no data,
|
||||
and no track information block for this track in the image file!
|
||||
<li>Actual length of track data = (high byte of track length) * 256
|
||||
<li>Track length includes the size of the TRACK INFORMATION BLOCK (256 bytes)
|
||||
<li>The location of a Track Information Block for a chosen track is found by summing
|
||||
the sizes of all tracks up to the chosen track plus the size of the Disc
|
||||
Information Block (&100 bytes). The first track is at offset &100
|
||||
in the disc image.
|
||||
</ul>
|
||||
|
||||
<h2>TRACK INFORMATION BLOCK</h2>
|
||||
<table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00 - 0c</td>
|
||||
<td>"Track-Info\r\n"</td>
|
||||
<td>13</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>0d - 0f</td>
|
||||
<td>unused</td>
|
||||
<td>3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>10</td>
|
||||
<td>track number</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>11</td>
|
||||
<td>side number</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>12 - 13</td>
|
||||
<td>unused</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>14</td>
|
||||
<td>sector size</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>15</td>
|
||||
<td>number of sectors</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>16</td>
|
||||
<td>GAP#3 length</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>17</td>
|
||||
<td>filler byte</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>18 - xx</td>
|
||||
<td>Sector Information List</td>
|
||||
<td>xx</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<p>NOTES:
|
||||
<ul>
|
||||
<li>Identical to the original DSK format definition.
|
||||
</ul>
|
||||
|
||||
<h2>SECTOR INFORMATION LIST</h2>
|
||||
|
||||
<table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>00</td>
|
||||
<td>track (equivalent to C parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>01</td>
|
||||
<td>side (equivalent to H parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>02</td>
|
||||
<td>sector ID (equivalent to R parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>03</td>
|
||||
<td>sector size (equivalent to N parameter in NEC765 commands)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>04</td>
|
||||
<td>FDC status register 1 (equivalent to NEC765 ST1 status register)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>05</td>
|
||||
<td>FDC status register 2 (equivalent to NEC765 ST2 status register)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>06 - 07</td>
|
||||
<td>actual data length in bytes</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>NOTES:
|
||||
<ul>
|
||||
<li>Identical to the original definition except for the addition of the
|
||||
sector data length. This value is in bytes and stored in little
|
||||
endian notation. (low byte followed by high byte)
|
||||
<li>The location of each sectors data is found by adding the size
|
||||
of the previous sectors, plus the size of the 256 byte header.
|
||||
<li>For 8k Sectors (N="6"), only 1800h bytes is stored. Please see extensions below!!!
|
||||
</ul>
|
||||
|
||||
<h2>Extensions to the above specification</h2>
|
||||
|
||||
<ol>
|
||||
<li>This extension was proposed by John Elliott.
|
||||
|
||||
<p>Extension to TRACK INFORMATION BLOCK:
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>offset</th>
|
||||
<th>description</th>
|
||||
<th>bytes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>12</td>
|
||||
<td>Data rate. (See note 1 and note 3)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>13</td>
|
||||
<td>Recording mode. (See note 2 and note 3)</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>Notes:
|
||||
<ol>
|
||||
<li>Data rate defines the rate at which data was written to the track.
|
||||
This value applies to the entire track.
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Date rate</th>
|
||||
<th>description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>0</td>
|
||||
<td>Unknown.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>Single or double density</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td>High Density</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3</td>
|
||||
<td>Extended density</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>Existing files should have zeroes in these bytes; hence the use of 0 for unknown.
|
||||
|
||||
<li>Recording mode is used to define how the data was written. It defines the encoding used to write the data to the disc
|
||||
and the structure of the data on the disc including the layout of the sectors. This value applies to the entire track.
|
||||
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Date rate</th>
|
||||
<th>description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>0</td>
|
||||
<td>Unknown.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>FM</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td>MFM</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>Existing files should have zeroes in these bytes; hence the use of 0 for unknown.
|
||||
|
||||
<li>How to determine the actual rate.
|
||||
<p>The NEC765 floppy disc controller is supplied with a single clock. When reading from and writing to a disc using the NEC765 you can choose FM or MFM
|
||||
recording modes. Use of these modes and the clock into the NEC765 define the final rate at which the data is written to the disc.
|
||||
<p>When FM recording mode is used, data is read from or written to at a rate which is double that of when MFM is used. The time for each bit will be twice the time for MFM.
|
||||
<p>Examples:
|
||||
<p><table border="1" >
|
||||
<thead>
|
||||
<tr>
|
||||
<th>NEC765 Clock</th>
|
||||
<th>FM/MFM</th>
|
||||
<th>Actual rate</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>4Mhz</td>
|
||||
<td>FM</td>
|
||||
<td>4us per bit</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4Mhz</td>
|
||||
<td>MFM</td>
|
||||
<td>2us per bit</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
</ol>
|
||||
|
||||
<li>This extension was proposed by Simon Owen.
|
||||
|
||||
<ol>
|
||||
<li>It has been found that many protections using 8K Sectors (N="6") do store more
|
||||
than &1800 bytes of useable data. It was thought that &1800 was the maximum useable limit, but
|
||||
this has proved wrong. So you should support 8K of data to ensure this data is read correctly.
|
||||
The size of the sector will be reported in the SECTOR INFORMATION LIST as described above.
|
||||
<p>For sector size N="7" the full 16K will be stored. It is assumed that sector sizes are defined
|
||||
as 3 bits only, so that a sector size of N="8" is equivalent to N="0".
|
||||
|
||||
<li>Storing Multiple Versions of Weak/Random Sectors.
|
||||
<p>Some copy protections have what is described as 'weak/random' data. Each time the sector is read one or more bytes will change, the value may be random between consecutive reads of the same sector.
|
||||
<p>To support these formats the following extension has been proposed.
|
||||
<p>Where a sector has weak/random data, there are multiple copies stored. The actual sector size field in the SECTOR INFORMATION LIST describes the size of all the copies.
|
||||
To determine if a sector has multiple copies then compare the actual sector size field to the size defined by the N parameter. For multiple copies the actual sector size field will have a value which is a multiple of the size defined by the N parameter.
|
||||
The emulator should then choose which copy of the sector it should return on each read.
|
||||
|
||||
</ul>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Reference in New Issue
Block a user