DSK format specification
Michael Pender
I'm thinking about adding DSK format support to a program I wrote. Can
anyone direct me to a specification for the most current version of the file
format?
I've read the FAQ, but I need to know the internals of the format, e.g. what
fields are present, sector ordering, etc.
Thanks,
- Mike
Bill Garber
"Michael Pender" <mpe...@hotmail.com> wrote in message
news:rLOPa.250$Y%3....@nwrddc03.gnilink.net...
AFAIK, a DSK is simply a raw copy of the disk itself.
The file is exactly the same size as a complete disk.
A 140k comes out 143,360 and an 800k will be 819,200.
Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - will...@comcast.net
---
This email ain't infected, dude!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 6/30/03
Michael Pender
Seriously though, I thought the format would be a bit more complex.
- Mike
Bill Garber <will...@comcast.net> wrote in message
news:rIGcnTjBDLH...@comcast.com...
Ian Gowen
You might want to check wotsit.org out; they tend to have a lot of info.
-Ian
Andy McFadden
> Omigosh!! ProBlock version 1.0 could do that back in 1990!!
>
> Seriously though, I thought the format would be a bit more complex.
Nope. Common Apple II disk formats:
- Universal Disk Images (.2mg)
Spec available on www.a2central.com as FTN $e0/0130.
- DiskCopy 4.2 (.dsk)
Spec available as FTN $e0/0005.
- Copy II Plus (.img)
Unadorned sectors, but in "raw" order.
- Sim //e HDV images (.hdv)
Unadorned sectors with a header.
- Dalton's Disk Disintegrator (DDD v2.1+, DDD Pro v1.1+) (.ddd)
Not described anywhere, but a source code disassembly is available.
- Unadorned sector-format files (.po, .do, .raw, .hdv)
The "DSK" format, which is usually in DOS or ProDOS sector order.
DiskCopy 6 (.dc6) is usually just this.
- Unadorned nibble-format files (.nib, .nb2)
Raw nibbles, with 6384 or 6656 bytes per track.
- ShrinkIt (NuFX) compressed disk images (.shk, .sdk)
Spec available as $e0/8002.
There are a few others (e.g. Davex archived volumes, $e0/8004), and I think
Apple Oasis has its own. The above are often stored with gzip compression
or (ick) in a ZIP archive on FTP sites.
The real trick is figuring out whether an unadorned 5.25" image is in
DOS, ProDOS, or "physical" order. Also, don't make the mistake I made in
CiderPress 1.0 and assume that all volumes are going to be multiples of
something nice, like 4K. It's possible to have odd-sized ProDOS volumes,
mostly from Windows/Mac/UNIX utilities that create a full-sized HD volume
but don't actually write the blocks until necessary.
--
Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
Charlie
"Michael Pender" <mpe...@hotmail.com> wrote in message
news:rLOPa.250$Y%3....@nwrddc03.gnilink.net...
The "DSK" image format(images that have the extension ".dsk") doesn't seem to
have any written specifications. As mentioned in Andy McFadden's post some
have different sector orders. What is really confusing is that there are some
that use a different sector order than the one used by the operating system on
the disk. In other words there are ProDOS DSK images with DOS order and DOS
3.3 DSK images with ProDOS order as well as DSK images where the order matches
the OS. ProDOS order means the blocks (512 bytes of unencoded data/block) are
arranged in numerical order. DOS order is the skewed sector (256 bytes/sector)
arrangement used by DOS 3.3. Unfortunately, I have run across several DSK
images that have headers (I have no idea how these are used). Most "DSK"
images are 143,360 bytes in length but again as Andy mentioned there are a few
that have more or less.
Charlie
Bill Garber
"Charlie" <char...@NOSPAMbboard.com> wrote in message
news:beppo...@enews2.newsguy.com...
>
> "Michael Pender" <mpe...@hotmail.com> wrote in message
> news:rLOPa.250$Y%3....@nwrddc03.gnilink.net...
to
> have any written specifications. As mentioned in Andy McFadden's post
some
> have different sector orders. What is really confusing is that there are
some
> that use a different sector order than the one used by the operating
system on
> the disk. In other words there are ProDOS DSK images with DOS order and
DOS
> 3.3 DSK images with ProDOS order as well as DSK images where the order
matches
> the OS. ProDOS order means the blocks (512 bytes of unencoded data/block)
are
> arranged in numerical order. DOS order is the skewed sector (256
bytes/sector)
> arrangement used by DOS 3.3. Unfortunately, I have run across several DSK
> images that have headers (I have no idea how these are used). Most "DSK"
> images are 143,360 bytes in length but again as Andy mentioned there are a
few
> that have more or less.
You all are making DSK too complicated. All they are is this.
Track 1, sector 1, byte 1 is byte 1 of the file, and so on each byte
from the disk is sequential in the file. Nothing more.
Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - will...@comcast.net
---
This email ain't infected, dude!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.500 / Virus Database: 298 - Release Date: 7/10/03
Andy McFadden
> You all are making DSK too complicated. All they are is this.
> Track 1, sector 1, byte 1 is byte 1 of the file, and so on each byte
> from the disk is sequential in the file. Nothing more.
Track 0, sector 0, byte 0 starts at byte 0 of the file. This is because,
for all possible sector skews, sector 0 is always in the same place.
Track 0, sector 1, byte 0 could be in one of three different places.
That's the difference between .PO, .DO, and Copy ][+ .IMG. If there
were a CP/M disk-image utility you'd have four possibilities.
A DOS utility will read sector 0 through sector 15 and write them out
in that order. A ProDOS utility will read block 0 through block 7 and
write them out as 512-byte blocks. Unfortunately, block 0 is track 0
sector 0 combined with track 0 sector 2, *not* track 0 sector 1. This
means that disk images created with DOS RWTS-based utilities are
different from images created with ProDOS utilities like ShrinkIt.
CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in
"DOS", "ProDOS", and "physical" sector ordering every time you open a
disk image. If the file has a helpful extension (like ".do"), it knows to
try that first. However, until it successfully identifies a filesystem, it
can't know the sector ordering, which is why for disks with no recognizable
filesystem (like games with custom loaders) it will ask you to choose one.
Because sector 0 is always in the right place, finding a DOS 3.3 VTOC isn't
sufficient... we know it's DOS 3.3, but we don't know what order the
sectors are, so it's necessary to examine the rest of the catalog track.
Which gets even more fun when you deal with 32-sector images on 800K disks.
Some formats, such as 2MG, are kind enough to tell you the order. Others,
like ShrinkIt, are always ProDOS-order. In general, though, you have to
keep poking at it until something looks familiar.
Charlie
Well, even assuming that you mean track 0, sector 0, and byte 0 this would only
be true of ProDOS order DSK images and I believe that the majority of DSK
images are DOS order. The bottom line here is that the DSK format isn't really
a format at all. It is a catch-all for several kinds of formats. If the
original poster used the sequential order that you describe for his program it
would only work with some DSK images.
Charlie
Michael Pender
Andy McFadden <fad...@fadden.com> wrote in message
news:lr0Qa.1241$dk4....@typhoon.sonic.net...
>
> Track 0, sector 0, byte 0 starts at byte 0 of the file. This is because,
> for all possible sector skews, sector 0 is always in the same place.
>
> Track 0, sector 1, byte 0 could be in one of three different places.
> That's the difference between .PO, .DO, and Copy ][+ .IMG. If there
> were a CP/M disk-image utility you'd have four possibilities.
>
> A DOS utility will read sector 0 through sector 15 and write them out
> in that order. A ProDOS utility will read block 0 through block 7 and
> write them out as 512-byte blocks. Unfortunately, block 0 is track 0
> sector 0 combined with track 0 sector 2, *not* track 0 sector 1. This
> means that disk images created with DOS RWTS-based utilities are
> different from images created with ProDOS utilities like ShrinkIt.
I remember that back-in-the-day (BITD?) there were disk utilities that
changed the interleave between DOS disk sectors to speed up file transfer.
That is, physical sector 0 and logical sector 0 are always the same, but
physical sector 1 and logical sector 1 could be different. Is this a
similar problem?
- Mike
Andy McFadden
> changed the interleave between DOS disk sectors to speed up file transfer.
> That is, physical sector 0 and logical sector 0 are always the same, but
> physical sector 1 and logical sector 1 could be different. Is this a
> similar problem?
It's similar. Sectors have a physical order (by default written straight
from 0 to 15) and a logical order (skewed around). The mapping between
them is fixed for each filesystem, and is different for DOS, Pascal/ProDOS,
and CP/M. (It happens that logical sector 0 is mapped to physical sector
0 in all established formats, which means that you'll see track 0 sector 0
at the start of every disk image regardless of ordering.)
The "fast skew" programs couldn't change the mapping between physical and
logical sectors, but they could write the physical sectors in a different
order by reformatting the tracks. Quality Software's Bag of Tricks was
one such utility. This sort of re-skewing would only be noticeable by
software that handles nibble images, because an RWTS read of sector 5
will always map to the same physical sector.
The trouble with ".DSK" images is that they were either written as a
series of 256-byte sectors (sector 0, 1, 2, 3, ...) or a series of 512-byte
ProDOS/Pascal blocks (sector 0, 2, 4, 6, ...). If you assume that track 0
sector 1 starts 256 bytes into the disk image file, you may be disappointed.
Naming 5.25" disk images with ".DSK" is a mistake, IMHO. They should be
".PO" or ".DO" to identify the contents unambiguously. If I recall
correctly, early versions of KEGS assumed that 5.25" disks were in DOS
order and 3.5" disks were in ProDOS order, so failing to label a disk
image could get you into trouble.
Paul Schlyter
Andy McFadden <fad...@fadden.com> wrote:
>
>The trouble with ".DSK" images is that they were either written as a
>series of 256-byte sectors (sector 0, 1, 2, 3, ...) or a series of 512-byte
>ProDOS/Pascal blocks (sector 0, 2, 4, 6, ...).
...and of course a Pascal 512-byte block was mapped into two 256-byte
sectors....
In CP/M, there was a further mapping done, into the 128-byte logical
sectors used by CP/M. Naturally two 128-byte CP/M sectors was mapped
into one 256-byte Apple sector. Nevertheless, CP/M had TWO levels
of sector interleave: one specificed within CP/M itself and executed
by Z80 code (it existed in all CP/M implementations), and another within
the BIOS code of Apple CP/M and executed by 6502 code; the latter was
Apple II specific.
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://www.stjarnhimlen.se/
http://home.tiscali.se/pausch/
Paul Schlyter
Bill Garber <will...@comcast.net> wrote:
> You all are making DSK too complicated. All they are is this.
> Track 1, sector 1, byte 1 is byte 1 of the file, and so on each byte
> from the disk is sequential in the file. Nothing more.
not with 1.
However, even though Track 0, sector 0, byte 0 was the first byte of
the DSK/.DO/.PO disk images, subsequent sectors (such as sector 1)
could be positioned differently. When you say "sector 1", do you
mean physical sector 1 or logical sector 1? If the latter, there
were three major sector interleaving schemes: Apple DOS 3, Apple
Pascal (which also was used by ProDOS), and Apple CP/M. Thus,
"sector 1" could have four different meanings.
In .DSK/.DO/.PO disk images logicla sector numbers were used. .DO
images used DOS 3 sector interleaving while .PO images used
Pascal/ProDOS sector interleaving. .DSK images _usually_ used DOS 3
sector interleaving, but could sometimes use Pascal/ProDOS sector
interleaving. I've never seen CP/M sector interleaving be used in
these disk images. The Apple II Oasis emulator emulates Microsoft's
Z80 card too and thus can run Apple II CP/M -- it runs fine from disk
images with DOS 3 sector interleaving.
Paul Schlyter
Andy McFadden <fad...@fadden.com> wrote:
> CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in
> "DOS", "ProDOS", and "physical" sector ordering every time you open a
> disk image. If the file has a helpful extension (like ".do"), it knows to
> try that first. However, until it successfully identifies a filesystem, it
> can't know the sector ordering, which is why for disks with no recognizable
> filesystem (like games with custom loaders) it will ask you to choose one.
> Because sector 0 is always in the right place, finding a DOS 3.3 VTOC isn't
> sufficient... we know it's DOS 3.3, but we don't know what order the
> sectors are, so it's necessary to examine the rest of the catalog track.
> Which gets even more fun when you deal with 32-sector images on 800K disks.
>
> Some formats, such as 2MG, are kind enough to tell you the order. Others,
> like ShrinkIt, are always ProDOS-order. In general, though, you have to
> keep poking at it until something looks familiar.
disk images (no files ever written to the disk, no CP/M system on the
system tracks)? Such a disk will have all bytes in each and every
sector set to hex E5. Perhaps in such a case you just assume DOS 3
sector order, since that's what works best with those Apple II emulators
which also emulates a Z80 ?
Andy McFadden
>> CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in
>> "DOS", "ProDOS", and "physical" sector ordering every time you open a
>> disk image.
> Then how do you determine the sector interleaving on a blank Apple CP/M
> disk images (no files ever written to the disk, no CP/M system on the
> system tracks)? Such a disk will have all bytes in each and every
> sector set to hex E5. Perhaps in such a case you just assume DOS 3
> sector order, since that's what works best with those Apple II emulators
> which also emulates a Z80 ?
I scan the volume directory and look for weirdness. If the disk were
completely empty there'd be nothing to scan and I'd get the wrong answer,
but since CP treats CP/M as read-only it's not like you'll miss out on
anything. :-)
I would have preferred to examine blocks in the boot area (the first 3
tracks), but it looks like AE and Microsoft had different implementations.
The saving grace with CP/M is that it does allocations in 1K blocks,
it appears to start allocating from the front, and it doesn't fill the
entire "catalog track". This means that the first file you create will
have data on the catalog track itself. So if you load the entire catalog
into memory, scan it, and find anything other than valid entries and 0xe5
values, you know you have the order wrong. (If the files stored in the
catalog track happen to be filled with 0xe5 or look like valid catalog
entries, then you're in trouble. In that case, having the correct label
on the disk image is essential, or you're going to have to use "query
image format" to override the automatic detection.)
Overall the CP/M code in CiderPress is the weakest of the filesystems,
since nobody ever wrote a "Beneath Apple CP/M". (Oddly enough, there is
the equivalent of a "Beneath SSI RDOS".) There are some bit fields in
the catalog entries that I still don't understand. Fortunately I was
able to find some large text files and compare the output on an Apple II
to the output from CP to verify that all was well.
Dosius
> Overall the CP/M code in CiderPress is the weakest of the filesystems,
> since nobody ever wrote a "Beneath Apple CP/M". (Oddly enough, there is
> the equivalent of a "Beneath SSI RDOS".) There are some bit fields in
> the catalog entries that I still don't understand. Fortunately I was
> able to find some large text files and compare the output on an Apple II
> to the output from CP to verify that all was well.
Maybe not, but you might find some useful stuff on www.cpm.z80.de
-uso.
Michael Pender
>
> It's similar. Sectors have a physical order (by default written straight
> from 0 to 15) and a logical order (skewed around). The mapping between
> them is fixed for each filesystem, and is different for DOS,
Pascal/ProDOS,
> and CP/M. (It happens that logical sector 0 is mapped to physical sector
> 0 in all established formats, which means that you'll see track 0 sector 0
> at the start of every disk image regardless of ordering.)
When I wrote the routine in ProBlock to copy a disk to a file, I never
proposed the file as a standard type because I thought the file format
should include header information to deal with some of these variations
first. I knew about the variations between DOS and ProDOS, but I never even
considered CP/M or Pascal.
One thing I did have in mind to add as a feature is a block/sector list to
support sparsely populated disks. Often many of the sectors or blocks on a
data disk will be unused and copying them into the archive file is just a
waste of space. Also, it would be helpful to have information about the
physical media format.
For example, ProDOS would automatically recognize the 1 Meg memory area or
my Laser 128 as a slot 5 ram disk (/RAM5 ?). Before I started any heavy
programming work with HyperC, I would copy the disk image from my 5.25" or
3.5" drive to the ram disk because the speed of ram access *far* exceeded
the speed of a 5.25" drive or 3.5" drive.
The downside is that a literal block-by-block copy from one disk to another,
e.g. the floppy to the ramdisk, would leave the target disk thinking it was
only the size of the source disk, vis the ~1024 K actually available. This
could be fixed easily enough by copying only the populated blocks from the
5.25" disk or 3.5" disk and setting the used block map of the ram disk.
I think its time for a new DSK format that includes at least these features:
- support for 256 byte, 512 byte, and 1024 byte blocks
- a used-block map for supporting sparse disks
- other information such as the date the media was formatted, original name
of the volume, etc.
The new format would be a super-set of other formats and the embedded
information would help eliminate many of the problems of dealing with
archived media from 4+ different operating systems (DOS 3.3, ProDOS, Pascal,
CP/M, etc.) However, I haven't spent much time thinking about support for
copy-protected disks of the era. I'm not sure there is a good way to deal
with those.
Any thoughts? Any recommendations for other features to be added to the new
format?
- Mike
Lazarus I. Long
if you want them, lemme know
// CpmStructs.h
#ifndef _H_CpmStructs
#define _H_CpmStructs
#include "GenStructs.h"
#include "CpmDiskLocSpec.h"
#include "FileSystemTypes.h"
#ifndef ushort
typedef unsigned short ushort;
#endif
#pragma options align = packed
typedef Cpm_BlockSpec Cpm_BlockNum;
typedef ushort Cpm_EntryIndex;
#define Cpm_GetBlock(imageRec, blockNum) \
&(imageRec->image.cpm->userType.block[blockNum])
/*
for access bits, they are stored in the hi-bit of
the corresponding character position.
eg: to see if a file is locked, look in the
Cpm_kAccessChar_READ_ONLY char of the file name,
if it's hi bit is set, it's locked.
the bits are propagated thru all the dir entries for a
single file, not just set on the first entry
*/
enum {
Cpm_kAccessChar_ILLEGAL_0,
Cpm_kAccessChar_PUBLIC,
Cpm_kAccessChar_DATESTAMP,
Cpm_kAccessChar_ILLEGAL_3,
Cpm_kAccessChar_ILLEGAL_4,
Cpm_kAccessChar_ILLEGAL_5,
Cpm_kAccessChar_ILLEGAL_6,
Cpm_kAccessChar_WHEEL_PROTECT, Cpm_kNameLength,
Cpm_kAccessChar_READ_ONLY = Cpm_kNameLength,
Cpm_kAccessChar_SYSTEM,
Cpm_kAccessChar_ARCHIVE, Cpm_kNameAndTypeLength,
Cpm_kTypeLength = Cpm_kNameAndTypeLength - Cpm_kNameLength
};
typedef short Cpm_AccessChar;
#define FOR_EACH_ACCESS_CHAR(_IDX) \
for ( charIndex = Cpm_kAccessChar_ILLEGAL_0; \
charIndex <= Cpm_kAccessChar_ARCHIVE; \
charIndex++)
enum {
Cpm_kAccessBit_ILLEGAL_0 = 1 << Cpm_kAccessChar_ILLEGAL_0,
Cpm_kAccessBit_PUBLIC = 1 << Cpm_kAccessChar_PUBLIC,
Cpm_kAccessBit_DATESTAMP = 1 << Cpm_kAccessChar_DATESTAMP,
Cpm_kAccessBit_ILLEGAL_3 = 1 << Cpm_kAccessChar_ILLEGAL_3,
Cpm_kAccessBit_ILLEGAL_4 = 1 << Cpm_kAccessChar_ILLEGAL_4,
Cpm_kAccessBit_ILLEGAL_5 = 1 << Cpm_kAccessChar_ILLEGAL_5,
Cpm_kAccessBit_ILLEGAL_6 = 1 << Cpm_kAccessChar_ILLEGAL_6,
Cpm_kAccessBit_WHEEL_PROTECT = 1 << Cpm_kAccessChar_WHEEL_PROTECT,
Cpm_kAccessBit_READ_ONLY = 1 << Cpm_kAccessChar_READ_ONLY,
Cpm_kAccessBit_SYSTEM = 1 << Cpm_kAccessChar_SYSTEM,
Cpm_kAccessBit_ARCHIVE = 1 << Cpm_kAccessChar_ARCHIVE
};
typedef short Cpm_AccessBits;
typedef char Cpm_FileName[Cpm_kNameLength];
typedef char Cpm_FileNameStr[Cpm_kNameLength + 1];
typedef char Cpm_FileType[Cpm_kTypeLength];
typedef char Cpm_FileTypeStr[Cpm_kTypeLength + 1];
// room for "dot" and the "\0"
typedef char Cpm_FileNameAndTypeStr[Cpm_kNameAndTypeLength + 2];
#define Cpm_IsAccessCharSet(_foo) \
(((_foo) & 0x80) != 0)
#define Cpm_SetAccessChar(_char, _setB) \
if (_setB) { \
(_char) |= 0x80; \
} else { \
(_char) &= 0x7F; \
}
#define Cpm_SetAccessBit(_bits, _bit, _setB) \
if (_setB) { \
(_bits) |= _bit; \
} else { \
(_bits) &= ~_bit; \
}
#define Cpm_GetAccessBit(_bits, _bit) \
(((_bits) & _bit) != 0)
#define Cpm_kMaxTotalDirEntries 64
#define Cpm_kMaxUseableDirEntries 48
#define Cpm_kUserNumber 0
#define Cpm_kIllegalBlock 0xFF
#define Cpm_kErasedSentinel 0xE5
#define Cpm_kTextFileEnd 0x1A // ctrl-Z
#define Cpm_kBytesPerRecord 128L
#define Cpm_kRecordsPerBlock 8
#define Cpm_kBytesPerBlock /* 1024 */ (Cpm_kBytesPerRecord *
Cpm_kRecordsPerBlock)
#define Cpm_kBlocksPerExtent 16
#define Cpm_kBlocksPerTrack 4
#define Cpm_kSectorsPerBlock 4
#define Cpm_kRecordsPerExtent /* 128 */ (Cpm_kBlocksPerExtent *
Cpm_kRecordsPerBlock)
#define Cpm_kHeaderBlocksPerDisk ((Cpm_BlockNum)12)
#define Cpm_kUserBlocksPerDisk ((Cpm_BlockNum)128)
#define Cpm_kBlocksPerDisk (Cpm_kHeaderBlocksPerDisk +
Cpm_kUserBlocksPerDisk)
typedef struct {
Byte userNumber;
Cpm_FileName name;
Cpm_FileType fileType;
Byte extentNum;
RboShort system;
Byte numRecords;
Cpm_BlockSpec extent[Cpm_kBlocksPerExtent];
} Cpm_DirEntry;
typedef Cpm_DirEntry Cpm_Directory[Cpm_kMaxTotalDirEntries];
typedef struct {
Byte byte[Cpm_kBytesPerRecord];
} Cpm_Record;
typedef union {
Cpm_Record record[Cpm_kRecordsPerBlock];
Byte byte[Cpm_kBytesPerBlock];
Gen_Sector sector[Cpm_kSectorsPerBlock];
} Cpm_Block;
typedef Cpm_Block Cpm_HeaderArea[Cpm_kHeaderBlocksPerDisk];
typedef Cpm_Block Cpm_UserArea[Cpm_kUserBlocksPerDisk];
typedef struct Cpm_Disk {
Cpm_HeaderArea header;
union {
Cpm_UserArea block;
Cpm_Directory directory;
} userType;
} Cpm_Disk;
#define Cpm_kNumBootBlocks ((Cpm_BlockNum)0)
#define Cpm_kDirStartBlock ((Cpm_BlockNum)0)
#define Cpm_kNumDirBlocks /* 2 */
((Cpm_BlockNum)(sizeof(Cpm_Directory) / Cpm_kBytesPerBlock))
#define Cpm_kDirEndBlock /* 1 */ ((Cpm_BlockNum)Cpm_kDirStartBlock +
Cpm_kNumDirBlocks - 1)
#define Cpm_kFreeUserArea /* ????? */ (sizeof(Cpm_Disk) -
sizeof(Cpm_HeaderArea) - sizeof(Cpm_Directory));
#define Cpm_kMaxFileSize /* ????? */ (Cpm_kMaxUseableDirEntries *
Cpm_kBlocksPerExtent * Cpm_kBytesPerBlock)
#define Cpm_kMaxExtentNum (Cpm_kUserBlocksPerDisk /
Cpm_kBlocksPerExtent)
#pragma options align = reset
Boolean Cpm_IsCpm(DiskImageRec *imageRec);
void Cpm_Catalog(DiskImageRec *imageRec);
#endif
Charlie
Rather than creating an entirely new "DSK" format, I would suggest that you add
your features to the Universal Disk Image (2IMG) format. It is, in my opinion,
the most flexible format. It uses a header. Specific information can be found
at:
http://www.a2central.com/programming/filetypes/ftne00130.html
Charlie
Michael Pender
>
> Rather than creating an entirely new "DSK" format, I would suggest that
you add
> your features to the Universal Disk Image (2IMG) format. It is, in my
opinion,
> the most flexible format. It uses a header. Specific information can be
found
> at:
>
> http://www.a2central.com/programming/filetypes/ftne00130.html
>
> Charlie
Thats not a bad suggestion; it looks like the changes could be incorporated
by using a new version number for the image file format.
However, I'm concerned that adding a sub-type to an existing file type may
do more harm than good. A person could not tell from the suffix that this
is a new file format that may be incompatible with older utilities.
- Mike
Michael Pender
Charlie <char...@NOSPAMbboard.com> wrote in message
>
> Rather than creating an entirely new "DSK" format, I would suggest that
you add
> your features to the Universal Disk Image (2IMG) format. It is, in my
opinion,
> the most flexible format. It uses a header. Specific information can be
found
> at:
>
> http://www.a2central.com/programming/filetypes/ftne00130.html
>
> Charlie
That's not a bad suggestion; it looks like the changes could be incorporated
by using a new version number for the image file format.
However, I'm concerned that adding a sub-type to an existing file type may
do more harm than good. A person could not tell from the suffix that this
is a new file format that may be incompatible with older utilities.
I think that at least the sub-type should be changed, i.e. $E0/$0130 -->
$E0/$0131
I think we should also deal with the ProDOS ambiguous date problem by using
at least an 8-bit field for the archive creation date.
Proposed date logic:
0 --> <no date>, otherwise
1900 + value of 8-bit field --> range from 1901 to 2155
I think 8 bits should adequately cover the lifespan of the Apple II, but I
suppose we could use a 16-bit field... :-)
- Mike
Andy McFadden
> - support for 256 byte, 512 byte, and 1024 byte blocks
> - a used-block map for supporting sparse disks
> - other information such as the date the media was formatted, original name
> of the volume, etc.
>
> The new format would be a super-set of other formats and the embedded
> information would help eliminate many of the problems of dealing with
> archived media from 4+ different operating systems (DOS 3.3, ProDOS, Pascal,
> CP/M, etc.) However, I haven't spent much time thinking about support for
> copy-protected disks of the era. I'm not sure there is a good way to deal
> with those.
I should probably point out that you get most of that with ShrinkIt.
Empty blocks can be "zapped" with ProDOS 8 ShrinkIt, and then compress
down to nothing. Date and volume name info are stored. It's always
ProDOS-ordered, so there's no confusion. There's a widely-tested utility
for creating and unpacking images on the Apple II, and (if I may say so
myself) solid support under pretty much every other platform via NuLib2.
The only copy-protected disks worth saving are 5.25", for which we have
NIB (though see the recent discussion about things NIB doesn't have).
Preserving copy-protected 3.5" disks doesn't seem to be all that important
to people.
Rather than finding an uber-format that handles everything, I think
it's best to reduce as many formats as possible down to a single approach.
Resolving the DOS vs. ProDOS ordering ambiguity can either be done like
2MG does it (adding a flag to support both and requiring all programs
to handle them) or by simply defining things to be one way, and letting
format conversion programs take the burden of swapping sectors around.
Andy McFadden
> CPM: i've got all the C++ routines to set/read all these items too,
> if you want them, lemme know
Great stuff. This will come in handy.
Out of curiosity, how did you get the information for all this? Is there
a reference available that explains the Apple II CP/M filesystem layout?
Bill Garber
"Andy McFadden" <fad...@fadden.com> wrote in message
news:jfrQa.1595$dk4....@typhoon.sonic.net...
> In comp.sys.apple2 Michael Pender <mpe...@hotmail.com> wrote:
> I should probably point out that you get most of that with ShrinkIt.
> Empty blocks can be "zapped" with ProDOS 8 ShrinkIt, and then compress
> down to nothing. Date and volume name info are stored. It's always
> ProDOS-ordered, so there's no confusion. There's a widely-tested utility
> for creating and unpacking images on the Apple II, and (if I may say so
> myself) solid support under pretty much every other platform via NuLib2.
But even SHK files give us trouble as Andy and I found out earlier
today, or was that yesterday as of now, anyway, apparently people
have uploaded files thru a browser or were not posted to the folder
properly on GROUND and the files ended up with an HTML header.
128 bytes of it. Once removed the file is fine, but does not work without
taking off the header. We must be careful of how we treat all archive
files, or there will be even more problems than we now have. Just
my 2 cents worth. ;-)
Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - will...@comcast.net
> The only copy-protected disks worth saving are 5.25", for which we have
> NIB (though see the recent discussion about things NIB doesn't have).
> Preserving copy-protected 3.5" disks doesn't seem to be all that important
> to people.
>
> Rather than finding an uber-format that handles everything, I think
> it's best to reduce as many formats as possible down to a single approach.
> Resolving the DOS vs. ProDOS ordering ambiguity can either be done like
> 2MG does it (adding a flag to support both and requiring all programs
> to handle them) or by simply defining things to be one way, and letting
> format conversion programs take the burden of swapping sectors around.
>
> --
> Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
> CD-Recordable FAQ - http://www.cdrfaq.org/
> CiderPress Apple II archive utility for Windows -
http://www.faddensoft.com/
> Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
Scott Alfter
Hash: SHA1
In article <myqdnVYa1ac...@comcast.com>,
Bill Garber <will...@comcast.net> wrote:
>You all are making DSK too complicated. All they are is this.
>Track 1, sector 1, byte 1 is byte 1 of the file, and so on each byte
>from the disk is sequential in the file. Nothing more.
If all you're dealing with is DOS 3.3 (ick), that might work. ProDOS
doesn't work that way, though, and a disk image created one way but restored
the other way will be thoroughly scrambled.
_/_ Scott Alfter
/ v \ sal...@salfter.dyndns.org
(IIGS( http://alfter.us Top-posting!
\_^_/ pkill -9 /bin/laden >What is the most annoying thing on Usenet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE/Etw+VgTKos01OwkRAvd7AKD6xMDjZau27Un8wXLcFlHkhQJTewCgmDxK
6ieiCfh5U+OJIMGtwqJuFAo=
=CZ3j
-----END PGP SIGNATURE-----
Scott Alfter
Hash: SHA1
In article <XPmcnegnDrh...@comcast.com>,
Bill Garber <will...@comcast.net> wrote:
>"Andy McFadden" <fad...@fadden.com> wrote in message
>news:jfrQa.1595$dk4....@typhoon.sonic.net...
>> In comp.sys.apple2 Michael Pender <mpe...@hotmail.com> wrote:
>
>> I should probably point out that you get most of that with ShrinkIt.
>> Empty blocks can be "zapped" with ProDOS 8 ShrinkIt, and then compress
>> down to nothing. Date and volume name info are stored. It's always
>> ProDOS-ordered, so there's no confusion. There's a widely-tested utility
>> for creating and unpacking images on the Apple II, and (if I may say so
>> myself) solid support under pretty much every other platform via NuLib2.
>
>But even SHK files give us trouble as Andy and I found out earlier
>today, or was that yesterday as of now, anyway, apparently people
>have uploaded files thru a browser or were not posted to the folder
>properly on GROUND and the files ended up with an HTML header.
>128 bytes of it. Once removed the file is fine, but does not work without
>taking off the header.
That would most likely be a Binary II header, not an "HTML header" (no such
thing exists in the context of Apple II archives). Apple II files residing
in binary form on non-Apple II systems should have them. ShrinkIt reads
right through them. NuLib can read them as well:
nulib bx foo.bxy
produces FOO.SHK (or FOO.SDK if it's a disk image), which can be passed back
into NuLib to decompress.
There are other methods for stripping a Binary II header off a file; for
instance, you could use dd under Linux, Cygwin, Mac OS X, etc. to start
copying a file from position 128 instead of position 0.
_/_ Scott Alfter
/ v \ sal...@salfter.dyndns.org
(IIGS( http://alfter.us Top-posting!
\_^_/ pkill -9 /bin/laden >What is the most annoying thing on Usenet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE/Et7AVgTKos01OwkRAq+AAKD6ysl8u/q4hUV6ppsGz70Macq0hwCg36v8
THrh+CsmwRz8NeIlNEB1pjQ=
=SEQB
-----END PGP SIGNATURE-----
Bill Garber
"Scott Alfter" <sal...@salfter.dyndns.org> wrote in message
news:49BQa.6467$Bp2.1452@fed1read07...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <XPmcnegnDrh...@comcast.com>,
> Bill Garber <will...@comcast.net> wrote:
> >"Andy McFadden" <fad...@fadden.com> wrote in message
> >news:jfrQa.1595$dk4....@typhoon.sonic.net...
> >> In comp.sys.apple2 Michael Pender <mpe...@hotmail.com> wrote:
>
> That would most likely be a Binary II header, not an "HTML header" (no
such
> thing exists in the context of Apple II archives). Apple II files
residing
> in binary form on non-Apple II systems should have them. ShrinkIt reads
> right through them. NuLib can read them as well:
>
> nulib bx foo.bxy
>
> produces FOO.SHK (or FOO.SDK if it's a disk image), which can be passed
back
> into NuLib to decompress.
>
> There are other methods for stripping a Binary II header off a file; for
> instance, you could use dd under Linux, Cygwin, Mac OS X, etc. to start
> copying a file from position 128 instead of position 0.
Scott, no offense, but I think the least knowledgeable person here would
know an HTML header when they see one, especially when it says HTML
right in the thing, plus when you click on it it opens as a web page instead
of opening a download dialog box. Give me some credit. Also, I used a hex
editor to remove the 128 byte header, and it works in a few seconds. I do
admit
though that Mr. McFadden steered me right on the first 3 bytes of the SHK so
now I can rip them off really quickly. We shouldn't need any program to
strip
off unwanted bytes, because frankly there shouldn't be any, but hey things
like
this happen.
Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - will...@comcast.net