From Newsgroup: comp.sys.apple2

Hello,

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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Michael Pender" <mpender@hotmail.com> wrote in message news:rLOPa.250$Y%3.201@nwrddc03.gnilink.net...

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.

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 - willy46pa@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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

"Michael Pender" <mpender@hotmail.com> wrote in message news:<rLOPa.250$Y%3.201@nwrddc03.gnilink.net>...

Hello,

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

You might want to check wotsit.org out; they tend to have a lot of info.
-Ian
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Michael Pender <mpender@hotmail.com> wrote:

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 fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Michael Pender" <mpender@hotmail.com> wrote in message news:rLOPa.250$Y%3.201@nwrddc03.gnilink.net...

Hello,

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.

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




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:beppol026me@enews2.newsguy.com...

"Michael Pender" <mpender@hotmail.com> wrote in message news:rLOPa.250$Y%3.201@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.

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 - willy46pa@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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Bill Garber <willy46pa@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.

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.

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Bill Garber" <willy46pa@comcast.net> wrote in message news:myqdnVYa1ach4o2iXTWJhw@comcast.com...

"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:beppol026me@enews2.newsguy.com...

"Michael Pender" <mpender@hotmail.com> wrote in message news:rLOPa.250$Y%3.201@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.

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.

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




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


Andy McFadden <fadden@fadden.com> wrote in message news:lr0Qa.1241$dk4.53908@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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Michael Pender <mpender@hotmail.com> wrote:

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?

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.

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <myqdnVYa1ach4o2iXTWJhw@comcast.com>,
Bill Garber <willy46pa@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.

Well, first of all, the track/sector/byte numbering stars with 0,
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, 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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <lr0Qa.1241$dk4.53908@typhoon.sonic.net>,
Andy McFadden <fadden@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.

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 ?

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Paul Schlyter <pausch@saaf.se> 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.

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.

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Andy McFadden <fadden@fadden.com> wrote in message news:<S_gQa.1437$dk4.64825@typhoon.sonic.net>...

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.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

CPM: i've got all the C++ routines to set/read all these items too,
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
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Michael Pender" <mpender@hotmail.com> wrote in message news:8dmQa.8407$qn1.3646@nwrddc04.gnilink.net...

Andy McFadden <fadden@fadden.com> wrote in message news:OU7Qa.1395$dk4.59598@typhoon.sonic.net...

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?

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




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Charlie <charlied@NOSPAMbboard.com> wrote in message news:besupt01lc@enews4.newsguy.com...

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




--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


Charlie <charlied@NOSPAMbboard.com> wrote in message news:besupt01lc@enews4.newsguy.com...

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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Michael Pender <mpender@hotmail.com> wrote:

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.

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.

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In comp.sys.apple2 Lazarus I. Long <me@lazilong.com> wrote:

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?

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2



"Andy McFadden" <fadden@fadden.com> wrote in message news:jfrQa.1595$dk4.78076@typhoon.sonic.net...

In comp.sys.apple2 Michael Pender <mpender@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 - willy46pa@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 fadden@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/

---
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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Bill Garber noted:

"Andy McFadden" <fadden@fadden.com> wrote in message >news:jfrQa.1595$dk4.78076@typhoon.sonic.net...

In comp.sys.apple2 Michael Pender <mpender@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.

I have also noticed a tendency of some sites to prepend a header
unless a binary mode FTP transfer is done. Then there is the
occasional MacBinary header or the Binary II header--both of
which are completely redundant for archives and disk images.
(Yes, I remember the "gotta put a Binary II header on ShrinkIt
archives" dicta, but the truth is that ShrinkIt is smart enough
to not need one. All the needed info is internal to the archive,
and ShrinkIt doesn't care _what_ its "type" is, as long as the
data is a valid archive.)

While it would be nice to eliminate this behavior, it seems unlikely
to me that universal compliance with the desired conventions can
be obtained.

What is more likely to work is to adopt the convention that most
utilities or emulators that work with disk images or file archives
skip over up to, say, 512 bytes of meaningless header searching
for the signature of a good archive or image. This is admittedly
another heuristic, and is not foolproof--but it is pretty good.

Of course, a stand-alone utility to header-strip archives/images
is a great contribution to this cross-platform, 5%-never-get-the-
word world that we live in. This could also be useful in adapting
newer image formats with headers to older software expecting
a raw image.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page: http://members.aol.com/MJMahon/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Paul Schlyter <pausch@saaf.se> wrote:

The structure and contents of the CP/M system tracks are indeed
completely implementation specific. It doesn't even have to be 3
tracks: om the classic CP/M disk format (8" SSSD) the system tracks
were only 2 tracks; otoh each track on 8" SSSD disks contained more
than each track on an Apple II 5.25" disk.

[... lots of stuff removed ...]

So it sounds like a program that processes disk images needs a set of
DPBs, from which it chooses one based on the physical characteristics of
the drive. For the Apple II world there are separate DPBs for 13-sector
and 16-sector disks.

Above the BIOS level, the file system area (i.e. everything except
the system tracks) on the disk are regarded just as a data area of
some specific size. CP/M doesn't care where a new tracks start; that's
a business only for the BIOS.

CiderPress has to be the BIOS as well as the operating system, which is
part of what makes all this so much fun. :-)

(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.

Consult the CP/M Alteration Guide in the CP/M manual:

http://www.cpm.z80.de/manuals/archive/index.htm http://www.cpm.z80.de/manuals/archive/cpm22htm/index.htm

This one I have seen, but I couldn't find details of filesystem structure
or directory layout in it. It has command references, boot loaders, and
what amounts to an RWTS system, but none of that helps much.

http://home.tiscali.se/pausch/apple2/CPM.ref.txt http://home.tiscali.se/pausch/apple2/Apple.CPM.ref.txt

The DPB info is useful. Now, if somebody has a .NIB of a 13-sector CP/M
disk, I can try to make that work...

--
Send mail to fadden@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/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <myqdnVYa1ach4o2iXTWJhw@comcast.com>,
Bill Garber <willy46pa@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 \ salfter@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-----
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2



"Scott Alfter" <salfter@salfter.dyndns.org> wrote in message news:49BQa.6467$Bp2.1452@fed1read07...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <XPmcnegnDrhixo-iXTWJkw@comcast.com>,
Bill Garber <willy46pa@comcast.net> wrote:

"Andy McFadden" <fadden@fadden.com> wrote in message >news:jfrQa.1595$dk4.78076@typhoon.sonic.net...

In comp.sys.apple2 Michael Pender <mpender@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 - willy46pa@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


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <tqAQa.1678$dk4.84051@typhoon.sonic.net>,
Andy McFadden <fadden@fadden.com> wrote:

Paul Schlyter <pausch@saaf.se> wrote:

The structure and contents of the CP/M system tracks are indeed
completely implementation specific. It doesn't even have to be 3
tracks: om the classic CP/M disk format (8" SSSD) the system tracks
were only 2 tracks; otoh each track on 8" SSSD disks contained more
than each track on an Apple II 5.25" disk.

[... lots of stuff removed ...]

So it sounds like a program that processes disk images needs a set of
DPBs, from which it chooses one based on the physical characteristics of
the drive. For the Apple II world there are separate DPBs for 13-sector
and 16-sector disks.

Yes. But in practice you can forget about the 13-sector CP/M disks
because they were rarely used. Early versions of the Z80 Softcard
came with a 13-sector floppy (I still have it), but all subsequent
Apple II software I ever saw for sale came on only 16-sector disks.

Above the BIOS level, the file system area (i.e. everything except
the system tracks) on the disk are regarded just as a data area of
some specific size. CP/M doesn't care where a new tracks start; that's
a business only for the BIOS.

CiderPress has to be the BIOS as well as the operating system, which is
part of what makes all this so much fun. :-)

Otoh in a disk image there are no tracks and sectors either, only a
data area of some specific size.

(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.

Consult the CP/M Alteration Guide in the CP/M manual:

http://www.cpm.z80.de/manuals/archive/index.htm
http://www.cpm.z80.de/manuals/archive/cpm22htm/index.htm

This one I have seen, but I couldn't find details of filesystem structure
or directory layout in it. It has command references, boot loaders, and
what amounts to an RWTS system, but none of that helps much.

OK -- a directory entry has the following structure:

1 byte User number, or E5h if it's a free entry
11 bytes Filename + extension: 8+3 characters
2 bytes Extent number of this entry
2 bytes Number of 128-byte records used in last alloc. block
16 bytes Allocation map for this directory entry

A few comments:

Extent number: large files in CP/M receives several directory
entries, called "extents" - as many as needed to store the
full allocation map for the file. On Apple CP/M (with 1K
allocation blocks and singe bytes in the allocation maps),
each directory extent is enough to define 16 Kbytes if the file.
Thus, any file larger than 16K will get more than one extent,
any file larger than 32K more than two extents etc. If 2K
allocation blocks had been used instead, each allocation
map would define 32K of the file, etc. The extent number
defines the order between the different directory entries with
the same name (e.g. MBASIC.COM on an Apple CP/M master diskette).

Number of 128-byte records used in last allocation blocks: the
CP/M file system defines the file length only in units of
128-byte "records" or "logical sectors". Since an allocation
block usually contains several 128-byte records, this field
defines how many records are in use in the last block allocated
to that file.

Allocation map of directory entry: single bytes of the disk has
256 allocation blocks or less, double bytes (little endian order)
if the disk has more than 256 allocation blocks. In the latter
case, each directory extent will only be able to map 8 allocation
blocks to the file.

Note that CP/M allows spares files -- these are marked by 00 in the corresponding position in the allocation map and since allocation
block 00 always contains the directory, it cannot be a valid file
allocation. Interestingly, the CP/M utility PIP fails to properly
copy a sparse file -- only the data up to the first "hole" in the
allocation map is copied.

http://home.tiscali.se/pausch/apple2/CPM.ref.txt
http://home.tiscali.se/pausch/apple2/Apple.CPM.ref.txt

The DPB info is useful. Now, if somebody has a .NIB of a 13-sector CP/M disk, I can try to make that work...

Don't bother.... the 13-sector CP/M disks were almost never used.

Instead, try to make CiderPress able to also transfer files to CP/M
disk images - that would be immensely more useful.

--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <hcEQa.1743$dk4.87984@typhoon.sonic.net>,
Andy McFadden <fadden@fadden.com> wrote:

The part I couldn't figure out is the part you labeled "number of
128-byte records used". The values I'm finding don't quite match up
with what you show.

OK, it appears the book I looked this up in (Andy Johnson-Laird's
"The Programmer's CP/M Handbook") wasn't quite accurate here. That
book probably defines the contents of the FCB instead (which is more
or less a mirror of the first 16 bytes of the directory entry;
however there are some differences). FCB = File Control Block, a
data area the application provides to CP/M when dealing with files:
you fill in the filename when opening the file, and give a pointer to
the FCB to CP/M, and then CP/M uses that area as a "scratchpad" for
its file operations. This is vaguely corresponding to the "buffers"
in Apple DOS, with the difference that the application, not the OS,
provides space for these buffers (a separate buffer must also be
provided for the data read from and written to the files). This had
the disadvantage of more trouble for the application, but also had
the advantage that there was no limit of concurrently open files in
CP/M, since the application could provide as many FCB's and buffers
as it needed. All within the 64K limit of RAM for the application
plus CP/M itself, of course.....


I did a Google search for "CP/M directory entry", and found a site
with info which agrees with your findings:

http://www.seasip.demon.co.uk/Cpm/format22.html
Describes the format of CP/M 2.2 disks

http://www.seasip.demon.co.uk/Cpm/formats.html
Has links to similar descriptions of CP/M 1.4, CP/M 3 and CP/M 4.
Ver 1.4 and 4 were never used on the Apple II, and ver 3 was
rarely used (by "The CP/M Card", which had its own 64K RAM _and_
used Apple's RAM, which that card could access from the Z80 as well,
by bank switching. CP/M 3 could use more than 64K of RAM, through
bank switching, and put the CCP, BDOS and part of BIOS in the other
memory bank if available).

http://www.seasip.demon.co.uk/Cpm/
Look under "Technical information" here.....

On http://www.seasip.demon.co.uk/Cpm/format22.html
you can find this info (note: exm=0 on all Apple II CP/M floppies,
including my own 80-track double-sided 640K Apple II CP/M floppies): --------------------------------------------------------------------
CP/M 2.2 directory
The CP/M 2.2 directory has only one type of entry:

UU F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC .FILENAMETYP....
AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL ................

UU = User number. 0-15 (on some systems, 0-31). The user number allows
multiple files of the same name to coexist on the disc.
User number = 0E5h => File deleted
Fn - filename
Tn - filetype. The characters used for these are 7-bit ASCII.
The top bit of T1 (often referred to as T1') is set if the file is
read-only.
T2' is set if the file is a system file (this corresponds to "hidden"
on other systems).
EX = Extent counter, low byte - takes values from 0-31
S2 = Extent counter, high byte.

An extent is the portion of a file controlled by one directory entry.
If a file takes up more blocks than can be listed in one directory entry,
it is given multiple entries, distinguished by their EX and S2 bytes. The
formula is: Entry number = ((32*S2)+EX) / (exm+1) where exm is the
extent mask value from the Disc Parameter Block.
(my note: on Apple II, exm=0)

S1 - reserved, set to 0.
RC - Number of records (1 record=128 bytes) used in this extent, low byte.
The total number of records used in this extent is

(EX & exm) * 128 + RC

(my note: since exm=0 on Apple II, this will always be equal to RC.
exm will be different from 0 only on large disks such as harddisks)

If RC is 80h, this extent is full and there may be another one on the
disc. File lengths are only saved to the nearest 128 bytes.

AL - Allocation. Each AL is the number of a block on the disc. If an AL
number is zero, that section of the file has no storage allocated to it
(ie it does not exist). For example, a 3k file might have allocation
5,6,8,0,0.... - the first 1k is in block 5, the second in block 6, the
third in block 8.
AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
disc) or 16-bit (stored low byte first).


--
----------------------------------------------------------------

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/

--- Synchronet 3.18b-Win32 NewsLink 1.113