Inconsistencies in HFDC WIN sectors

[webdeck]

I'm going through the raw data I extracted from my ST-225 MFM hard drive that I used with my Geneve many, many years ago.

 

There are two things I have found so far that are inconsistent with the manual.  I wonder they were bugs in the original MDOS version or DSR.  Has anyone heard of these issues?

 

1.  Bytes 26-27 in a Directory Descriptor Record (DDR) are supposed to be a pointer to the parent DDR.  However, on my hard drive, these two bytes are seemingly random values.

 

2.  Bytes 28-29 in a File Descriptor Record (FDR) are supposed to be the ASCII characters 'F' and 'I'.  Some of the FDRs on my hard drive have that, but most of them have >0000 in those bytes.

Edited November 5, 2020 by webdeck

[+9640News]

5 hours ago, webdeck said:

I'm going through the raw data I extracted from my ST-225 MFM hard drive that I used with my Geneve many, many years ago.

 

There are two things I have found so far that are inconsistent with the manual.  I wonder they were bugs in the original MDOS version or DSR.  Has anyone heard of these issues?

 

1.  Bytes 26-27 in a Directory Descriptor Record (DDR) are supposed to be a pointer to the parent DDR.  However, on my hard drive, these two bytes are seemingly random values.

 

2.  Bytes 28-29 in a File Descriptor Record (FDR) are supposed to be the ASCII characters 'F' and 'I'.  Some of the FDRs on my hard drive have that, but most of them have >0000 in those bytes.

In regards to #1 above, MDM5 and/or the DSR has a bug that it does not point back to previous directory.  If the directory was created with MDOS, it is written correctly with the make directory command and follows the standards written in the HFDC manual.  MDOS then will also be able to remove the directory.  However, it the directory was created with MDM5, MDOS can not remove the directory.  If I am not mistaken, I think you may end up with a subdirectory name you can not delete if you created with MDM5 and tried to delete with MDOS.  I'm pretty sure it is a DSR bug on the HFDC card, not MDM5 itself however it has been a very long time since I have used another utility on the TI-99/4A side of things to confirm.  If you create and remove the directory within MDM5, then you do not have an issue.

 

Myself, I always try to make and remove directories on the MDOS side of things.

 

As far as #2 above, I do not know.  

 

Beery

 

[webdeck]

Thanks for the info, Beery.  The good news is that both of these issues are easily fixable.

[+InsaneMultitasker]

I have seen the "FI" in some files though I do not recall if it is a product of the HFDC DSR or the Geneve DSR or a random 'feature'.  This could be tested in MAME or real hardware by creating a few files from MDOS and a few files in ROMPAGE environment.   You would also want to check the various file types to see if that has any impact on the results. 

 

@BeeryMiller is spot on and i believe there may even be a problem where if you delete a folder using MDOS/Geneve Os that was created by MDM5, you may cause linkage or corruption. It has been a long time since I tried it and I don't know that anyone ever attempted to research this particular issue to the full extent.

 

Maybe @mizapf has some knowledge of these two items based on his excellent work with TIImageTool.

[+mizapf]

The easiest way is to run MAME, write some files, and then use TIImageTool and use "View file information block" in the context menu (right-click on a file). Since MAME uses the original HFDC DSR, any real issue should also show up in emulation. (And the advantage is that we're doing regular backups of our image files, right? ? Wait, while I'm talking about that, I think I should do a new backup.)

 

I just created a file in GeneveOS (MDOS) and found the FI signature. However, I also see files which don't have it. I can do a check on my real Geneve with the SCSI system to check whether these files come from the SCSI system.

 

 

 

[+mizapf]

Just checked: When I create a new file (e.g. open a new file in QDE and save it) in native mode, the FIB contains the "FI" signature (on emulation and on the real system). This is also true when you create a file in GPL mode.

 

However, when I use "copy" in GeneveOS to copy that very file, the copy lacks "FI".

 

[Edit: Real system with ASCSI card, emulation with HFDC]

Edited November 4, 2020 by mizapf

[+InsaneMultitasker]

13 minutes ago, mizapf said:

Just checked: When I create a new file (e.g. open a new file in QDE and save it) in native mode, the FIB contains the "FI" signature (on emulation and on the real system). This is also true when you create a file in GPL mode.

 

However, when I use "copy" in GeneveOS to copy that very file, the copy lacks "FI".

This is most likely in the same level 2 code section that deals with time/date stamps.  My guess is the "FI" bytes are either cleared or skipped.  Is there any merit to correcting this?  The only benefit that comes to mind is as a marker for file recovery. 

 

I would expect similar behavior with the HFDC DSR, seeing as the Geneve DSR is based in part on the HFDC code.

[webdeck]

Okay, another question - how does the volume bit map work?  I am seeing a number of sectors that should be marked as in use showing as free and vice-versa.  

 

The Myarc HFDC manual only says, "Sectors 1 to 31 contain the bit map (i.e. used / unused sectors)."  

 

The disk peripheral software spec says for floppy disks, "The Allocation Bitmap is used to indicate the availability of individual allocation units. A binary 1 in a bitposition indicates that the allocation unit associated with that bit has been allocated. The first bit (bit 0)is associated with allocation unit 0, the second bit (bit 1) with allocation unit 1, etc. During disk initialization, bits corresponding to system-reserved AUs, non-existing AUs, and bad AUs, are set to 1. All other bits are set to zero."  

 

Okay... but which is the "first bit" or "bit 0"?  Elsewhere in the spec when it talks about file status flags, it says bit 0 is the least significant bit.  So that would imply that the bits are filled from LSBit (>01) to MSBit (>80).

 

Mess source code shows it going from LSBit to MSBit here: https://github.com/mamedev/mess-cvs/blob/70fc5e783acac0c13e05938738632d1adef93097/mess/tools/imgtool/ti99.c (line 522.)

 

But, when I format a new blank HD image in HFDC format using TIImageTool, there are 33 AUs used (VIB at 0, bitmap ar 1-15, backup of VIB+bitmap at 2-31, and FDIR at 32), and the bitmap shows FF FF FF FF 80 00 00 00, which implies the opposite ordering is used - the bits are filled from MSBit to LSBit.

 

Does anyone know which way it is.  My assembly is rusty, but from looking at the HFDC driver source in GETSEC looks like it is going MSBit to LSBit, but I could be reading that wrong.

 

Does anyone know the definitive answer?

 

Thanks!

[+InsaneMultitasker]

59 minutes ago, webdeck said:

The disk peripheral software spec says for floppy disks,

This statement suggests you might be applying floppy disk structures and expectations to the hard disk format.  While the two (floppy, hard disk) share terminology their implementations differ.  You'll see this within the respective VIB, bitmap, DDR, and FDR structures.   Within both formats, some values are absolute and others are calculated based on the number of sectors per bitmap bit.

[+mizapf]

@webdeck I wrote something about that on Ninerpedia. One thing has been mentioned: The endianness is different for hard and floppy disk bitmaps.

 

Edit: https://www.ninerpedia.org/wiki/File_systems

Edited November 9, 2020 by mizapf

[webdeck]

Thanks - that clarifies things for me.  The great thing about standards is that there are so many of them. ?

[F.G. Kaal]

On 11/9/2020 at 7:11 AM, webdeck said:

But, when I format a new blank HD image in HFDC format using TIImageTool, there are 33 AUs used (VIB at 0, bitmap ar 1-15, backup of VIB+bitmap at 2-31, and FDIR at 32), and the bitmap shows FF FF FF FF 80 00 00 00, which implies the opposite ordering is used - the bits are filled from MSBit to LSBit.

 

 

Bits are filled from MSBit to LSBit.

In the above example there are 33 bits set; this tells me that you have 1 sector/AU and that your maximum HD size is 15 sectors x 256 bytes x 8 bits x 256 bytes/sector = 7864320 bytes.

[webdeck]

10 hours ago, F.G. Kaal said:

Bits are filled from MSBit to LSBit.

In the above example there are 33 bits set; this tells me that you have 1 sector/AU and that your maximum HD size is 15 sectors x 256 bytes x 8 bits x 256 bytes/sector = 7864320 bytes.

It is a 20MB hard drive, 615 cyl, 4 heads, 32 sectors per track.  It is 2 sectors per AU.  Sectors 0-31 are the VIB and bitmap.  Sectors 32-63 are the backup of the VIB and bitmap.  Together that's 32 AUs.  The 33rd AU is the FDIR for the root directory (sectors 64-65.)

[webdeck]

One more question.  I don't have any files on my drive that are fragmented enough to require a second FDR record.  Does the second FDR copy all the same data from the first FDR except for the prev/next FDR pointers and the data chain pointer blocks?

Edited November 13, 2020 by webdeck

[F.G. Kaal]

7 hours ago, webdeck said:

It is a 20MB hard drive, 615 cyl, 4 heads, 32 sectors per track.  It is 2 sectors per AU.  Sectors 0-31 are the VIB and bitmap.  Sectors 32-63 are the backup of the VIB and bitmap.  Together that's 32 AUs.  The 33rd AU is the FDIR for the root directory (sectors 64-65.)

My mistake, Maximum disk size is 31x256x8x256 = 162Mb for 1 sector/AU.

And off course from FF FF FF FF 80 it is impossible to tell the number of sectors/AU or the number of heads, sectors per track and cylinders ... that is in the VIB sector 0.

Edited November 13, 2020 by F.G. Kaal

[F.G. Kaal]

7 hours ago, webdeck said:

One more question.  I don't have any files on my drive that are fragmented enough to require a second FDR record.  Does the second FDR copy all the same data from the first FDR except for the prev/next FDR pointers and the data chain pointer blocks?

I myself also have never seen a file fragmented enough for this option to kick in. I wondered when writing the IDE DSR what it would look like. I did a small experiment with a doctored IDE DSR to create very fragmented files to see if the DSR was also able to read the file back but I had no option to do this with an HFDC card for comparison.