Subject: CF7 file system: Number of allocated sectors

From: "Michael Zapf" <[email-masked]>
Date: Sat, 16 Apr 2011 23:50:44 -0000

Hi all,

I seem to have come across an interesting difference in the file systems of the CF7 and HFDC/SCSI. I had a problem with displaying files that I got from a dump of a CF card which was written to in a CF7 device. Almost all text files had additional characters at the end. 

The reason was that I calculated a higher length for the file. Interestingly, I never had problems with HFDC or SCSI images.

I found the following difference:

The File Descriptor Record is the sector that contains information about a specific file. At offset 0x0e there is the "number of allocated sectors", at offset 0x12 there is the number of level 3 records. 

For HFDC/SCSI, both numbers are always the same for DIS/VAR files. 

For the CF7 (+, don't know), these numbers differ. It seems as if the number of allocated sectors is always a multiple of the AU size, while the number of level 3 records actually tells the length of the file by the number of sectors within this AU that belong to this file.

Example:

From my SCSI drive:

0072000: 4750 4c32 3030 5f52 4d20 0000 9003 0007  GPL200_RM ......
0072010: 3050 0700 8b68 bc86 4db0 bc88 0000 0000  0P...h..M.......
0072020: 0000 0001 0004 0000 1927 1927 0000 0000  .........'.'....
0072030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

(note that the level 3 record count is swapped in byte order)

From the CF card:

0015000: 5453 5432 3536 5241 434b 0000 8003 0010  TST256RACK......
0015010: 4d50 0f00 0000 0000 0000 0000 4649 0000  MP..........FI..
0015020: 0000 0001 0004 0000 0819 0819 0000 0000  ................
0015030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

----------

So for determining the actual length of the file I suppose one must use the level 3 records count, not the number of allocated sectors?

Michael

---

From: "fredkaal" <[email-masked]>
Date: Sun, 17 Apr 2011 13:00:45 -0000

> So for determining the actual length of the file I suppose
> one must use the level 3 records count, not the number of
> allocated sectors?

That is correct. Allocated record count can be greater than the level 3 record count when for instance creating a file with a predefined size. When writing to the file the number of level 3 record count will increase until the number of allocated AU. This method can prevent fragmented files.

> It seems as if the number of allocated sectors is always a
> multiple of the AU size.

This is also correct. One can't allocate a fraction of an AU like one can't allocated a fraction of a sector.

When using the IDE DSR and when a data file is created, then the DSR always allocates >10 AU's for the file. When a file is copied than the number of level3 record count is used.

Fred ;-)

---

From: "Michael Zapf" <[email-masked]>
Date: Sun, 17 Apr 2011 13:42:23 -0000

Hi Fred,
 
> This is also correct. One can't allocate a fraction of an AU like one can't allocated a fraction of a sector.

this indeed makes sense to me. But this would also mean that the behavior of the SCSI DSR or MDOS does not make sense in that respect. It always sets the number of allocated sectors equal to the number of L3 records, regardless of the fact that AUs are longer than 1 sector.

I checked this on a copy of my SCSI drive contents (created on the real machine, not emulated): The file size of VAR files is always the value of "allocated sectors" plus the AU size, and the L3 value is swap-equal to allocated sectors.

For instance,

007c000: 5253 3233 3244 2020 2020 0000 9003 0053  RS232D    .....S
007c010: c550 5300 7ca9 c293 7cca c293 0000 0000  .PS.|...|.......
007c020: 0000 0006 0004 0000 195c 1961 0000 0000  .........\.a....

is reported as 

RS232D     99 Dis/Var 80

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Sun, 17 Apr 2011 14:52:10 -0000

Hi Fred,

> This is also correct. One can't allocate a fraction of an AU like one can't allocated a fraction of a sector.

This seems not to be true for PROGRAM files. Those have an allocated sector count which is not a multiple of the AU size.

From a CF dump:

000d000: 4d47 5232 2020 2020 2020 0000 0100 001e  MGR2      ......
000d010: 0c00 0000 0000 0000 0000 0000 4649 0000  ............FI..
000d020: 0000 0002 0004 0000 080d 080e 0000 0000  ................

so this has 1e sectors with 0c bytes in the last sector.

In contrast, for data files (VAR or FIX), the allocated sector count  always seems to be a multiple of the AU size.

Michael

---

From: "fredkaal" <[email-masked]>
Date: Mon, 18 Apr 2011 17:03:47 -0000

Hi Michael,

Never looked that close to HFDC and SCSI DSR in MDOS. When creating the IDE DSR I always uses ROMPAGE doing comparisons. ALso did this when creating Dm2k and Du2k. I found out that the allocated sector count is maybe slightly misinterpreted in the SCSI DSR (in some low level function(s)).

I suuppose the HFDC and SCSI DSR in MDOS are both based on the same code (or functions) and therefore show the same error.

Tha HFDC manual says:

NUMBER OF SECTORS CURRENTLU ALLOCATED:
Contains the number of sectors allocated to this file.

(This must by a multiple of AU's)

NUMBER OF LEVEL 3 RECORDS ALLOCATED:
In the case of fixed length record files, this contains the highest record actually written to. In the case of variable length record files it contains the highest sector actually written to. (NOTE: the bytes are in reversed order).

One field is talking about sectors, while the other is talking about records or sectors. So be aware what you are comparing.

In the case of a program file the number of sectors and file offset tells the length of the file and because the number of sectors per AU is known everything is known about the file.

Fred ;-)

---

From: Insane Multitasker <[email-masked]>
Date: Mon, 18 Apr 2011 16:24:53 -0500

You are correct in stating that the SCSI and HFDC code within MDOS is the same, except for the low level IO and DSK1 emulation. The IDE test code also uses the same routines, so you could say all three devices use the same core code.
 
I also recall the SCSI DSR EPROM 1.5/1.6 erroneously uses some of the pointers.  As for the MDOS error, a specific example is necessary if you are indeed saying there is a problem.   Since the MDOS DSR is based on the HFDC DSR, I find it unlikely though not impossible that the interpretation changed.   ;0

> To: [email-masked]
> From: [email-masked]
> Date: Mon, 18 Apr 2011 17:03:47 +0000
> Subject: [TI994A] Re: CF7 file system: Number of allocated sectors
> 
> Hi Michael,
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

---

From: "fredkaal" <[email-masked]>
Date: Tue, 19 Apr 2011 17:04:48 -0000

Tim,

As I said "I always used rompage ..." so the problem I found must be in the SCSI DSR on the SCSI card. It is a long time ago: It was something with copying data files (only DIS/VAR as far as I remember) to a floppy. The file on the floppy always had carbage at the end and I figured out it was just as much garbage to fill up the last AU used by the file on a 100Mb ZIP disk.

It is too long ago ... I hava to check it all again.

Fred ;-)

--- In [email-masked], Insane Multitasker <insane_m@...> wrote:
> > From: fgkaal@...
> > --- In [email-masked], "Michael Zapf" <newsmail09@> wrote:
> > >
> > > 
> > > 
> > > Hi Fred,
> > >