[Coco] values other than 0 or 1 for byte 14 of decb dir entry

[Aaron Wolfe]

On Sun, Mar 25, 2012 at 2:23 PM,  <hhos at st-tel.net> wrote:
>> Hi,
>>
>> According to my docs, bytes 14 and 15 are the number of bytes used in
>> the last sector of the file.
>> Since we have sectors of only 256 bytes, I think that means you'd
>> either see 0 in 14 and any value in 15, or 1 in 14 with 0 in 15.
>>
>> That rule holds true for a vast majority of the disk images I have
>> here, however there are some disks with files that seem to be claiming
>> to use more than 256 bytes in their last sector.  I'm not sure what
>> this means.  Am I misinterpreting the docs?
>>
>> I've values of 2, 7 and 8 in byte 14, and a couple instances of a 1 in
>> 14 and a non zero value in 15.
>>
>> -Aaron
>
> I am definitely confused here. Are any of these images you're looking at
> showing a value over $900? It's been a while since I looked at
> documentation about this subject, but my memories tell me that DECB uses
> granule sizes of 2304 bytes. I remember that number quite well mainly
> because it is one of the main reasons why I despise the DECB file
> structure. Wouldn't the value in bytes 14/15 therefore be the # of bytes
> used in the last GRANULE, not the last sector, and could be as high as
> $900?
>

According to my documentation, no.  We are talking about the number of
bytes used in the last sector.


"A  granule data byte,  which has been allocated,  will  contain a
value,  which is the number   of the next granule
	in the granule chain for that file. If the two   most significant
bits (6,7) of a  granule data byte  are set, then
	that  granule is the last  granule in a  file’s granule chain.  The
low   order four bits  will  contain the
	number   of sectors in the last  granule which the  file uses."

So the # of sectors used is already stored right in the granule data,
seems no reason to store it again.  The documentation also refers to
bytes 14-15 of the directory entry specifically as "bytes used in the
last sector of the file":

"	Byte Description
	0—7 Filename, which is left justified and blank, filled. If byte0 is 0,
	then the file has been ‘KILL’ed and the directory entry is available
	for use. If byte0 is $FF, then the entry and all following entries
	have never been used.
	8—10 Filename extension
	11 File type: 0=BASIC, 1=BASIC data, 2=Machine language, 3= Text editor
	source
	12 ASCII flag: 0=binary or crunched BASIC, $FF=ASCII
	13 Number of the first granule in the file
	14—15 Number of bytes used in the last sector of the file
	16—31 Unused (future use)	Byte Description
	0—7 Filename, which is left justified and blank, filled. If byte0 is 0,
	then the file has been ‘KILL’ed and the directory entry is available
	for use. If byte0 is $FF, then the entry and all following entries
	have never been used.
	8—10 Filename extension
	11 File type: 0=BASIC, 1=BASIC data, 2=Machine language, 3= Text editor
	source
	12 ASCII flag: 0=binary or crunched BASIC, $FF=ASCII
	13 Number of the first granule in the file
	14—15 Number of bytes used in the last sector of the file
	16—31 Unused (future use)"

These docs could be wrong, but a vast majority of disks do seem to
work as they describe.  It is only 8 files on 2 disks out of some
hundreds that are not seeming to follow this spec.