News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

DSK format - Sector Size Q

Started by aidano, 15:26, 21 October 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

aidano

Hi folks,

I'm learning a new programming language and scratching my retro itch at the same time by making some tools to read the DSK format. 

Using the documentation at CPC Wiki, and trying out my code on a few (non-extended type/single side) DSK files, I notice the 'sector size' is always 2 for me. Sector count is 9 in my testing so far, and given that the sector data (which is stored at &100 to end of track block) is much larger than 18 bytes, the maths isn't adding up for me...so I'm sure I'm misunderstanding something.

I expected the sector data size per track to be equal to the sector size * sector count listed in the track info block..but it's obviously not. I think my code is fine because I can eyeball the raw data and see that it looks right. 

So, what is the purpose of sector size and count?

Aidan

roudoudou

you may have different sector size or number (keeping track size the same as requested by non extended format)
My pronouns are RASM and ACE

GeoffB17

The normal sector size would be 512 bytes.  Not sure where you've got the '2' from, but this might be 2 x ? referring to a CP/M standard 'Physical' record as opposed to a 'logical' record.

The sector count is usually 9, but there are utilities that can format disks with 10 sectors per track.

If you divide the track length by 9, what do you get?

Geoff

robcfg

The name "sector size" is a bit misleading.

Ok, it's the sector size but you need to convert it to bytes via the following formula:

dataSize = (256 << (tib.sectorSize - 1));
So, a sector size of 2, translates to 256 << (2-1), or 512 bytes.

aidano

Aha! So sector size unit is 256 bytes. I'll see if I can update the wiki to reflect that.

@GeoffB17 dividing the track length by 9 (and accounting for the first &100 bytes which is for track+sector info) gives 512, so this all lines up now.

pelrun

No, it's not a unit; the values go up by powers of two. I.e. 128,256,512,1024,2048,4096,8192 are the possible sizes (although the last one is the difficult to duplicate 8k sector protection where only about 6144? bytes are actually present.)

sizeinbytes = 1 << (tib.sectorSize + 7)

Is an equivalent definition.

roudoudou

in fact there is no formula because...

format a track with 0 size sector will write 128 bytes sectors BUT FDC can write/read only 80 bytes on 0 sized sectors
then formula is correct up to 8, after, there is a maximum :)

0     |    80 octets
1     |   256 octets
2     |   512 octets
3     |  1024 octets
4     |  2048 octets
5     |  4096 octets
6     |  8192 octets
7     | 16384 octets
8-255 | 32768 octets

My pronouns are RASM and ACE

aidano

#7
Ok, *now* this all makes sense to me. When viewed from the physical disk perspective, it's almost obvious in hindsight: sectors are angular blocks for a given track, which is a ring of data at a given radius. Maybe the max exists to account for some finitely-sized drive buffer..

A lookup table it is, then.  :)

Powered by SMFPacks Menu Editor Mod