Sensi Disk Directory

[bloodline]

I have been trying to reverse engineer the Sensible software file system. It looks really simple, with a normal bootblock, an then a file allocation table starting at 0x400.
The file allocation table appears to be made up of 192 entries, each one 32bytes long.

Each entry appears to have three fields:
The first field appears to be a 26byte null terminated string.
The second field appears to be a 2 byte word, indicating the location of the file.
The third field appears to be a 4byte long, giving the file size.

The problem is that I'm not sure how the second field relates to the location of the file on the disk. All files (easy to see with their IFF headers) appear to aligned to the nearest 512bytes.

Does anyone know the calculation to work out the actual byte offset of the files?

[phx]

There are a lot of Sensible Software games. Can you refer to a specific ADF?

It was common to store the starting block number in the file table. As you can easily identify files by their IFF headers on block-boundaries it shouldn't be too difficult to find out in which format their locations are stored.

[bloodline]

Apologies, my initial post was very weak, it was posted in haste this morning before work.

The disk I am looking at is (possibly the older disk I own) MegaLoMania, disk 1.

The first three entries in the file allocation table are:

mod.warintro | 259 | 23,044
mlm_icons | 10,756 | 52,736
mlm_features | 13,064 | 17,970

The first file is a standard MOD and I can see it is at byte offset 7,168 (directly after the file allocation table).
The second file is a standard IFF ILBM picture at byte offset 238,592
The third file is also an IFF ILBM at 291,328
The file size of all three files matches the last number in the table entry.

My initial assumption was that the second number was a block number (as one might find in FFS), but multiplying it by 512 gives stupidly high values. Then I wondered if it was a "cluster" number so I played around with some numbers and found that multiplying it by 22 started to give me approximate values. Then I wondered if this was based on the FAT file system, but that didn't seem to work (Link to the FAT32 spec I used https://www.pjrc.com/tech/8051/ide/fat32.html).


I just can't see how the second number relates to the actual file position on the disk... I must be missing something obvious

[bloodline]

More tables entries:

(in the format of name, byte position, entry location and file size)

mlm	                648,192	29,441	150,684
machinegun	799,744	36,352	1,046
cannon2     	801,280	36,355	4,366
harearg3b	        805,888	36,609	6,742
musk	        813,056	36,868	1,066
throw.      	        814,592	36,871	1,594
wwind2	        816,640	37,120	1,946
missile1d	        818,688	37,124	8,040
xplo	                826,880	37,385	3,592
spit2	                830,976	37,638	10,932
stick1	        842,240	38,150	2,078
harearg2B	        844,800	38,400	5,650
GRUNT1d	        850,944	38,657	2,878
laser2b	        854,016	38,663	4,050

Looking through the raw data, I can see that the file sizes in the table are correct.

[phx]

I think the file starting location is stored in two bytes. The first byte is the track (11 sectors per track) and the second byte is the sector inside that track.

259 = $01 $03 : Track 1, Sector 3, means Block 14. 14*512 = 7168.
10756 = $2a $04: Track 42, Sector 4, means Block 466. 466*512 = 238592.
Match!

[bloodline]

Originally Posted by phx

I think the file starting location is stored in two bytes. The first byte is the track (11 sectors per track) and the second byte is the sector inside that track.

259 = $01 $03 : Track 1, Sector 3, means Block 14. 14*512 = 7168.
10756 = $2a $04: Track 42, Sector 4, means Block 466. 466*512 = 238592.
Match!

It never occurred to me that the geometry could be addressed that way with 2 bytes. Brilliant! Many thanks for your insight

-edit-
For those following along at home:

blockNumber = (Track * 11) + Sector

Bytes = bockNumber * 512

I have checked every entry and all are addressed perfectly with your scheme!

[Leffmann]

That's some good digital forensics I think the LBA model makes more sense, but I guess it's simpler like this with the way Amiga track-loaders work.

[bloodline]

Originally Posted by Leffmann

That's some good digital forensics I think the LBA model makes more sense, but I guess it's simpler like this with the way Amiga track-loaders work.

It is easy to forget now, when working on multi gigabyte machines, that the byte is a useful unit of information! And, yes I have become so used to LBA I often forget about the old disk geometry method of addressing.

I will add Seni disk reading support to my ADFBench app.