AMSDOS catalog and file format

[AugustoRuiz]

Hi All!


I'm trying to load AMSDOS files from disk, without using the firmware. Arnoldemu has posted a great example on how to load a sector here, but it requires to know several parameters:

   
• Sector Id
• Track
• File size

I'm having a look at the firmware disassembly, available here, and having a look at CAS IN OPEN, I can't figure out the catalog format nor how files are laid out in the DSK file, so I can find the sector, track and size from a file name.


Is this documented anywhere? I've tried googling about it, but couldn't find any results

[arnoldemu]

Hi All!


I'm trying to load AMSDOS files from disk, without using the firmware. Arnoldemu has posted a great example on how to load a sector here, but it requires to know several parameters:

   
• Sector Id
• Track
• File size

I'm having a look at the firmware disassembly, available here, and having a look at CAS IN OPEN, I can't figure out the catalog format nor how files are laid out in the DSK file, so I can find the sector, track and size from a file name.


Is this documented anywhere? I've tried googling about it, but couldn't find any results

it's a cpm 2.2 based file system.

CP/M information archive : disc formats

for data, directory is on track 0, sector c1, and is 4 sectors long.
"clusters"/"data" starts at track 0 sector c5.
each "cluster" is 2 sectors.

Cluster 0 is first directory block, cluster 1 is second directory block, cluster 2 is first directory block.

[AugustoRuiz]

Thank you!

I found this other reference...

Ubuntu Manpage: cpm - CP/M disk and file system format

I think the extent part is explained better?

Regards,

[AugustoRuiz]

for data, directory is on track 0, sector c1, and is 4 sectors long.
"clusters"/"data" starts at track 0 sector c5.
each "cluster" is 2 sectors.

Cluster 0 is first directory block, cluster 1 is second directory block, cluster 2 is first directory block.

Excuse me, what do you mean with "cluster"? Is it the same thing the documentation calls "Extents"?

I cannot relate the info in the header to track/sectors...

This is what I have understood so far from the docs:

The list of files is stored in the catalog (track 0, sector C1, 4 sectors long, so 2Kb in size). A file can appear several times in the catalog, if the file size is higher than what a catalog entry can index (16Kb). If so happens, each catalog entry will have the same name and user number, and different (consecutive?) extent bytes.

The size of the catalog entry is measured in records, whose size is 128 bytes. The catalog entry indicates the size of the entry in its RC byte.
So the size of the file is the sum of all sizes of its catalog entries. If an entry in the catalog has a record count of 128 (so the size of the catalog entry is 16Kb), then there might be more entries for the current file.

Disk sectors are 512 bytes long, so a sector can hold up to 4 records.

What I don't get is how to operate with the allocation bytes, because those will probably be the ones that tell me which track/sector should I read from. In the docs it says that each byte tells us which block holds a 1kb fragment of the entry, with 0 meaning not allocated. So my guess is that for each non-zero byte in the allocation bytes, I will have to convert the block index to a pair of track/sectors.

I think I'm almost there. The DPB has a block mask and a block shift. And my guess is that DPB values for CPC are:
Block shift = 3, Block mask = 7 (so 1Kb per block?) So that's what you mean by "each cluster is 2 sectors"? That each "block" is stored in 2 sectors?

Or probably I'm completely wrong...

[arnoldemu]

The allocation bytes I call "Clusters".

A cluster is 2 sectors in this case.

Cluster 0 starts at track 0, sector c1.

so allocation index of 2 is track 0, sector c5.

does this help?

[AugustoRuiz]

The allocation bytes I call "Clusters".

A cluster is 2 sectors in this case.

Cluster 0 starts at track 0, sector c1.

so allocation index of 2 is track 0, sector c5.

does this help?

Yes! A lot

Cluster 0 is first directory block, cluster 1 is second directory block, cluster 2 is first directory block.

So, what you meant here was:
Cluster 0 is first directory block, cluster 1 is second directory block, cluster 2 is first data block.

[rpalmer]

AugustoRuiz,The disk format used by AMSDOS is very basic, so may be my explanation may help.
1. Disks are made up of tracks with a number of sectors on them.
2. The disks maybe double sided.
3. All information is stored in blocks (or as some, like micorosoft, refer to them as 'clusters'). These are a collection of consecutive sectors. For now I will assume single sided disk, but double sided disks can make it complicated as to the allocation of sectors to a block. Also assume the block size is 1K.

4. The "directory" of a disk is stored at the first available track/sector (for System format this is after the reserved tracks, which is normally the first sector of track #2).

5. An entry in the directory is made up of 32 bytes and so for large files multiple entries are tagged with extents to help with block allocations. The directory format is:
{UserNumberByte}{filename}{RecordNumber}{Extent}{blockNumbers}
where user number is a byte, filename is 11 bytes, record number is 3 bytes, extent is a byte and block numbers occupy 16 bytes.
If the size of the disk is less than a certain size the block indexing is in "byte" index (e.g if < 256K bytes the index for each block is 1 byte) else the index is in 2 bytes. The disk size is based in the Extended Disk Parameter Block (XDPB).

This means that for a 64 entry directory the number of blocks required would be 2.

So to access the file's content you would have to convert the block number to actual track and sector numbers. I assume you can do the math.

The use of the "extent" byte in a directory is to allow for more blocks to be allocated to the file and the files with an "extent" are hidden from view in the catalog display (as they serve no purpose to the user). For example a 32K file would occupy 2 entries as each entry references a 16K portion of the 32K file. If the file was 1 byte larger, then there would be 3 entries. Extent's for files less than (or equal to) 16K is always zero.

The directory entry flags an end of file with a block number known to not be allocatable, namely zero.

rpalmer

[AugustoRuiz]

Yes, I can do the math. And I've found some fast divide-by-9 routine:

http://map.grauw.nl/articles/mult_div_shifts.php#divby9.

Thank you!