The previous log properly parsed the first directory block but it did not go through all the directory blocks. Where is the next directory block? A hint is here.

For FAT32, the root directory can be of variable size 
and is a cluster chain, just like any other directory is. 
The first cluster of the root directory on a FAT32 volume 
is stored in BPB_RootClus.

Each entry is:

Picking one entry in the middle:

080 48 4F 43 4B 45 59 20 20 42 41 53 20 00 23 BD 8C  HOCKEY  BAS .#..
090 A9 54 A9 54 00 00 F5 91 4D 54 05 00 B9 20 00 00  .T.T....MT... ..

• Offset 0-10 = Short File Name - "HOCKEY  BAS"
• Offset 11 = 0x20 - ATTR_ARCHIVE (see below)
• Offset 12 = 0x00 NT_Reserved - is 0 like it should be
• Offset 13 - 0x23 = Millisecond timestamp - ignore
• Offset 14-19 = BD 8C A9 54 A9 54 - Not sure what this is but there's stuff in there and it's different for each entry
• Offset 20-21 = 00 00 - High word of entry's first cluster
• Offset 22-23 = F5 91 - Last Time
• Offset 24-25 = 4D 54  - Last Date
• Offset 27-28 = 05 00 - Low word of entry's first cluster
• Offset 28-31 = B9 20 00 00 - File size

For example HOCKEY.BAS is at offset 0x00 00 00 05.

There's no chain element in this entry.

Note about the ATTR_ARCHIVE - This attribute supports backup utilities. This bit is set by the FAT file system driver when a file is created, renamed, or written to. Backup utilities may use this attribute to indicate which files on the volume have been modified since the last time that a backup was performed.

The first character in the Short File name has special meaning.

• If DIR_Name[0] == 0xE5, then the directory entry is free (there is no file or directory name in this entry).

• If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0).

The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free.

Nothing There

There's nothing in the directory block that tells where the next block is located. Backing up a level to the FAT32 FSInfo Sector Structure.

The root directory seems to be in consecutive block. Added code to read blocks until a block that starts with the first item equal to 0x00.

Result is:

*** DIRECTORY START ***
SYSTEM~1.      0
HOCKEY.BAS     8377
HORSER~1.BAS   3014
HURKLE.BAS     1390
KINEMA.BAS     813
...
[CLIPPED HERE
...
STARTR~1.BAS   8481
STOCK.BAS      7440
SUPERS~1.BAS   20045
SUPERS~2.BAS   5960
SWING.BAS      1151
SYNONYM.BAS    1981
T1000.BAS      32
TANKFORT.BAS   3456
*** DIRECTORY END ***

The code is:

 5200 REM READ/PRINT ROOT DIRECTORY
 5210 BO=0
 5220 PRINT "*** DIRECTORY START ***"
 5230 L0=(DS+BO) AND 255:L1=(DS+BO)/256:L2=(DS+BO)/65536
 5240 GOSUB 4800:REM READ BLOCK
 5250 IF MA(0)=0 THEN GOTO 5300
 5260 REM GOSUB 3000:REM DUMP ARRAY
 5270 GOSUB 4600:REM PRINT DIRECTORY
 5280 BO=BO+1
 5290 GOTO 5230
 5300 PRINT "*** DIRECTORY END ***"
 5310 RETURN

It works but I'm not sure if it is a robust result since I am assuming that the directory is in consecutive blocks. Moving on for the moment.

I think the answer is in Rebuilding FAT cluster chains.

By now you know from the previous entries that this structure 
in the FAT was zeroed out when the file was deleted and that 
the file system uses the data contained in these 16 bit cluster 
entries to map out the file's location on disk. Without this map,
who knows where the file lies.

To rebuild the map, we have to populate the 16 bit cluster 
entries with cluster addresses where the data resides on disk. 
We saw in the previous entry that the FAT Directory Entry told 
us the file began in cluster two. We know from the way a 
file system optimizes writes that it will put the file down 
contiguously if it can and in this instance we have enough 
available cluster entries in the FAT to accommodate our file.

Let's see the corrected FAT:

Aside from the fact that I've masked out the values we're not interested in seeing,
you can now see the 16-bit values (also known as words) that make up each
cluster entry in the FAT. Each pair of bytes (03 00, 04 00, 05 00...) represents a
cluster on the disk, and inside each word is the next cluster address on the disk
where the file continues. Previously, when the file was deleted, each word
contained 00 00, 00 00, etc.


We know from the FAT Directory Entry that our file started in cluster two. The 16
bit value in the FAT entry for cluster two is 0x0300, the 16 bit value in the FAT
entry for cluster three is 0x0400, the 16 bit value in the FAT entry for cluster four
is 0x0500 and so on. If we convert these values to decimal we get three, four, 
five and so on. So, cluster two is the start of the file, the FAT Directory Entry tells 
us this, to see where the file continues, we look at cluster two's entry in the FAT 
itself.

It would be nice to build a table of file names and offsets.