mirror of
https://github.com/AppleWin/AppleWin.git
synced 2025-04-17 15:40:59 +00:00
95 lines
4.0 KiB
HTML
95 lines
4.0 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 SOME 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. It is useful for making images of ALL copy protected software.
|
|
</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>
|