I suspect it would not be incredibly difficult to hack around the SPA check, but I haven’t had time to do such.

–bryan

Have fun!

The inodes (64 bytes each) start at 0x0035b800, the second entry is the root directory inode:

0035b840: 41ed 0011 0000 0000 0000 0200 0000 c200 A……………
0035b850: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0035b860: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0035b870: 0000 0000 37f1 63a6 3573 282c 30f5 4407 ….7.c.5s(,0.D.

The file is 512 bytes long (offset 0x08), has 0x11 hard links (that’s a lot), uid and gid of 0 and uses block 0x0000c2 (offset 0x0c, big endian byte order). Still need to find the correct encoding for the first two bytes (di_mode). The last 12 bytes are the a/m/ctime Unix time stamp, 0x37f163a6 = Wednesday, 29 September 1999 00:56:06 GMT (https://www.epochconverter.com). Sounds reasonable.

The offset of this block of 0xc2 * 0x400 = 0x30800.

With the start address of the partition (“load band” in TI terms) of 0x35b000, the directory starts at 0x38B800:

0038b800: 0002 2e00 0000 0000 0000 0000 0000 0000 …………….
0038b810: 0002 2e2e 0000 0000 0000 0000 0000 0000 …………….
0038b820: 0003 6269 6e00 0000 0000 0000 0000 0000 ..bin………..
0038b830: 0004 6574 6300 0000 0000 0000 0000 0000 ..etc………..
0038b840: 0005 7573 7200 0000 0000 0000 0000 0000 ..usr………..
0038b850: 0006 7469 0000 0000 0000 0000 0000 0000 ..ti…………
0038b860: 0007 7368 6c69 6200 0000 0000 0000 0000 ..shlib………
0038b870: 0008 6c69 6200 0000 0000 0000 0000 0000 ..lib………..
0038b880: 0009 6465 7600 0000 0000 0000 0000 0000 ..dev………..
0038b890: 000a 7069 7065 0000 0000 0000 0000 0000 ..pipe……….
0038b8a0: 000b 7261 6d00 0000 0000 0000 0000 0000 ..ram………..
0038b8b0: 000c 746d 7000 0000 0000 0000 0000 0000 ..tmp………..
0038b8c0: 000d 7574 696c 0000 0000 0000 0000 0000 ..util……….
…

Looks like the root directory :-). The two bytes at 0x38b800 tell us the root directory inode is #2. So it seems the inode numbers start counting at 1 and inode 1 is the first one stored at 0x35b800 (no idea what this inode actually points to, it has an empty length and block list but appropriate time stamps).

The following inode (#3) is /bin, this points to block 0xc3 at 0x38bc00:

0038bc00: 0003 2e00 0000 0000 0000 0000 0000 0000 …………….
0038bc10: 0002 2e2e 0000 0000 0000 0000 0000 0000 …………….
0038bc20: 0173 6173 0000 0000 0000 0000 0000 0000 .sas…………
0038bc30: 0174 6163 6374 636f 6d00 0000 0000 0000 .tacctcom…….
0038bc40: 0175 6172 0000 0000 0000 0000 0000 0000 .uar…………
0038bc50: 0176 6261 636b 7570 0000 0000 0000 0000 .vbackup……..
0038bc60: 017d 6261 7365 6e61 6d65 0000 0000 0000 .}basename……
0038bc70: 017f 6361 7400 0000 0000 0000 0000 0000 ..cat………..
0038bc80: 0180 6368 6772 7000 0000 0000 0000 0000 ..chgrp………
0038bc90: 0181 6368 6b73 686c 6962 0000 0000 0000 ..chkshlib……
0038bca0: 0182 6368 6d6f 6400 0000 0000 0000 0000 ..chmod………
0038bcb0: 0183 6368 6f77 6e00 0000 0000 0000 0000 ..chown………
0038bcc0: 0187 636d 7000 0000 0000 0000 0000 0000 ..cmp………..
0038bcd0: 0188 636f 6d6d 0000 0000 0000 0000 0000 ..comm……….
0038bce0: 0189 6370 696f 0000 0000 0000 0000 0000 ..cpio……….
0038bcf0: 018c 6372 7970 7400 0000 0000 0000 0000 ..crypt………
0038bd00: 018d 6373 706c 6974 0000 0000 0000 0000 ..csplit……..
0038bd10: 018e 6374 7261 6365 0000 0000 0000 0000 ..ctrace……..
0038bd20: 018f 6374 6372 0000 0000 0000 0000 0000 ..ctcr……….
0038bd30: 018f 6374 6300 0000 0000 0000 0000 0000 ..ctc………..

Looks like /bin!

So that doesn’t solve the problem completely, but maybe it’s a step in the right direction… hope it helps :).

This is the patient 0 from A/UX (0.7 floating around has kernel source)

struct dinode
{
        ushort  di_mode;                /* mode and type of file */
        short   di_nlink;               /* number of links to file */
        ushort  di_uid;                 /* owner's user id */
        ushort  di_gid;                 /* owner's group id */
        off_t   di_size;                /* number of bytes in file */
        char    di_addr[40];            /* disk block addresses */
#define di_gen          di_addr[39]
        time_t  di_atime;               /* time last accessed */
        time_t  di_mtime;               /* time last modified */
        time_t  di_ctime;               /* time created */
};

I guess its similar enough?

https://multicores.org/ti1500/include/ino.h looks more like it and there seems to be some magic happening in the last 4 bytes of what should be di_addr

Right, stupid me… ouch.

The on-disk inode format might be described in a file s5ino.h (see the OSF/1 header https://samy.pl/packet/MISC/tru64/usr/include/s5fs/s5ino.h), but I can’t find this header in the disk image. Will have to dig deeper :).

yeah these things were rare 20-30 years ago, and now.. it’s like a mere legend.

I’ll have to get in contact with that Museum, although in general they usually don’t poke/prod the machines too hard.

Im so sorry for bugging you.. .turns out the inode structure on disk is different from memory. 😐

ino.h

	/* Inode structure as it appears on a disk block. */
struct dinode

What is strange is doing a strings on the disk has it missing braces.. and I never can tell if it’s the end of the file if it was contiguous or if it’s just broken up.. 😐

I’m not sure if it’s missing stuff but I’m certainly not reading inodes right from the disk. 🙁

The header files are included in the disk image and at least some of the blocks seem to be contiguous, so maybe this helps a bit? https://multicores.org/ti1500/include/inode.h