mirror of
https://github.com/AppleWin/AppleWin.git
synced 2024-12-26 05:31:30 +00:00
95 lines
3.9 KiB
HTML
95 lines
3.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
<title>Disk Image Formats</title>
|
|
|
|
|
|
</head>
|
|
|
|
|
|
<body style="background-color: rgb(255, 255, 255); font-family: verdana;" alink="#008000" link="#008000" vlink="#008000">
|
|
|
|
<h2><font color="#008000" face="Arial">Disk
|
|
Image Formats</font></h2>
|
|
|
|
<hr size="4">
|
|
<p>Disk images can be in a number
|
|
of different
|
|
formats, depending on how they were created.</p>
|
|
|
|
<p style="font-weight: bold;">DOS Order Images:</p>
|
|
|
|
<p>DOS order disk images contain the data from
|
|
each sector, stored in the same order that DOS 3.3 numbers
|
|
sectors. If you run a DOS program on the Apple which reads in
|
|
sectors one by one and then transfers them over a serial line to
|
|
the PC, you will get a DOS order disk image. </p>
|
|
|
|
<p>Apple floppy disks contained 35 tracks with
|
|
16 sectors per track, for a total of 560 sectors. Each of these
|
|
sectors contained 256 bytes of information, for a total of
|
|
143,360 bytes per disk. Therefore, DOS order disk images are
|
|
always at least 143,360 bytes long. Sometimes on the Internet you
|
|
will see a disk image that is 143,488 or 143,616 bytes long; this
|
|
is probably a DOS order image with extra header information
|
|
before or after the image. In most cases, AppleWin can
|
|
automatically detect this and handle it. </p>
|
|
|
|
<p style="font-weight: bold;">ProDOS Order
|
|
Images: </p>
|
|
|
|
<p>ProDOS order disk images are very similar
|
|
to DOS order images, except that they contain the sectors in the
|
|
order that ProDOS numbers them. If you compress a disk with
|
|
Shrinkit on an Apple, then transfer it over a modem and
|
|
uncompress it on the PC, you will get a ProDOS order disk image. </p>
|
|
|
|
<p>Since ProDOS order disk images contain the
|
|
same information as DOS order disk images, simply in a different
|
|
order, they are also about 143,360 bytes long. When you use a
|
|
disk image of this size, AppleWin attempts to automatically
|
|
detect whether it is in DOS order or ProDOS order by examining
|
|
the contents of the disk. If the disk was formatted with a
|
|
standard operating system such as DOS or ProDOS, AppleWin will
|
|
successfully detect the format. Otherwise, it will revert to DOS
|
|
order, which is by far the most common format. To force ProDOS
|
|
order, give the file an extension of ".PO". </p>
|
|
|
|
<p style="font-weight: bold;">Nibble Images:</p>
|
|
|
|
<p>Nibble images contain all of the data on a
|
|
disk; not just the data in sectors but also the sector headers
|
|
and synchronization areas, all stored in the same encoded format
|
|
that would be recorded on a real disk's surface. At 232,960
|
|
bytes, nibble images are bigger than other images, but they can
|
|
be useful for making images of copy protected software. </p>
|
|
|
|
<p style="font-weight: bold;">2mg Images:</p>
|
|
|
|
<p>2mg (or 2img) images are a wrapper around DOS, ProDOS or Nibble images.
|
|
They contain extra meta-data describing for example, DOS volume number and
|
|
write-protection.
|
|
</p>
|
|
|
|
<p style="font-weight: bold;">WOZ Images:</p>
|
|
|
|
<p>The WOZ Disk Image format is an offshoot of the <A href="https://applesaucefdc.com/woz">Applesauce project</A>. Capturing highly accurate bit data is of no use if you don't have a container to hold the data. The WOZ format was designed to be able to contain every possible Apple ][ disk structure and layout. It can be so accurate that even copy protected software can't tell that it isn't an original disk.
|
|
</p>
|
|
|
|
<p style="font-weight: bold;">Compressed Images :</p>
|
|
|
|
<p>All of the above can optionally be either gzip'ed or zipped. If a zip archive
|
|
contains multiple files, then AppleWin only supports using the first file. For best results
|
|
with hard disk images, uncompress first, as writing back to the image requires a full
|
|
image re-compression after every block write. Examples of typical extensions are:
|
|
<ul>
|
|
<li>.gz, .dsk.gz, .nib.gz, .2mg.gz, .woz.gz</li>
|
|
<li>.zip, .dsk.zip, .nib.zip, .2mg.zip, .woz.zip</li>
|
|
</ul>
|
|
</p>
|
|
|
|
</body>
|
|
</html>
|