Tom,
Another person with Lisa file system knowledge is Ray Arachelian <ray_at_email.domain.hidden> who wrote the FS tool you mention.
One thing I would recommend when looking at the disk layout of this FS is to create a text file which lists on a block basis the 512 byte block contents in hex and ASCII and also the block tag data. Having a disk image in this format will be much easier to understand and interpret since the references will be to blocks (or possible allocation groups which are multiple blocks). The tag data occupies 24 bytes. The key here is the FILE ID part (2 bytes) which helps the Lisa FS to identify block ownership during its scavenger process. Each file is assigned a unique id which is assigned to the file's tag data whenever a block is written. Also, certain special blocks are assigned special ids (e.g. boot blocks have id $AAAA). Believe the regular file ids started as small positive numbers whereas special ids were large negative numbers. The tag data layout is described in the Lisa device driver manual (attached, see page 136 - this is called the "page label" with Pascal type PageLabel). Also, not sure what the Lisa FS did when the number of files on a disk became rather large and started to intersect with the special file ids. Suspect nothing since Apple most likely did not think there would ever be more than 32K files on a disk.
I think I will create a program that parses the Apple Disk Copy 4.2 files to provide this block data/tag listing (layout info for these disk image files is attached).
Here's the driver interface for the Page Label / Tag data (the OS reference manual on page 6 has a short description of this too):
pagelabel = packed record
version: integer; {2}
datastat: (dataok, datamaybe, databad); {1 along with FILLER field}
filler: -32..31;
volume: int1; {1}
fileid: integer; {2}
abspage: int4; {4}
relpage: int4; {4}
fwdlink: int4; {4}
Since this is a packed record, the fields which are less than a byte in size will be packed. I've added after each field the number of bytes I believe each field occupies so easier to parse this data when you look at the raw tag data.
When you read a Lisa disk on a Macintosh using a program such as Apple Disk Copy, only 12 bytes of tag data are read. This is because the Macintosh only supported 12 byte tags. But the FILE ID field is read.
Misc. stuff ...
MDDF = Media Descriptor Data File per Apple's Lisa operating system reference manual (the March 1, 1982 version mentions this on page 6).
Each file also contains a LABEL. This is similar to the Macintosh resource fork, but for the Lisa this is rather small. Page 7 of the Lisa OS manual describes these. The 1982 manual says this contains 488 bytes, but later manuals say 128 bytes. The Lisa OS provided system calls to read/write this data (the Lisa Desktop Manager used label data to map a file from the FS physical view to the DM logical view - e.g. the name of the file internal to the FS was system-generated whereas the label contained the user's name for the file). See the Lisa ToolKit listing page 97 for label content details as listed in the TDeskLabel record structure. I'm not sure where the label was stored but suspect it was in the first block of a file's data. The FS would exclude this block when it opened a file for reading/writing and instead treated physical block # 1 as logical block # 0. Or, labels may have been stored in their own file but I suspect not since one issue with the Lisa FS was slow data access and having a extra level of data access for labels would slow the performance. Not sure if the label storage location and format differed based on the Lisa FS version. I suspect not and also suspect label size was 128 bytes even for Twiggies, ProFiles, and Sony disks.
===
On January 13, 2014, at 11:18 PM, Tom Stepleton wrote:
> Hi David,
>
> Thanks for the tip and the resources. I will drop Natalia a line and see how far she has come. I have not examined a v2 Flat FS disk, but everything you have described for the "FFS v1" matches what I see in my images.
>
> I look forward to having some spare time to dive into this! Should be fun. The filenames are very easy to spot in the bytes of the disk image---they are essentially sitting on their own in a sea of zeroes, with some other flotsam bytes around. I don't have a great deal of expertise in this kind of reverse engineering, but I think it shouldn't be too bad. We'll see!
>
> Thanks again,
> --Tom
This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:14 EST