-
Notifications
You must be signed in to change notification settings - Fork 1
/
extdsk.html
410 lines (378 loc) · 10.1 KB
/
extdsk.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
<!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>