Jim, that occurred to me right off the bat, but the disk has only 35 cylinders and is single-sided.
No file names in the body text. The text itself isn't proprietary, but merely an early cut of an already-published public report, so I have no problem sharing any part of the disk image. --Chuck On 01/08/2017 07:55 PM, jim stephens wrote: > I don't know the names, but the use of extents might be something going on. > > I highlighted the c4a3 extent. The last two columns maybe cylinder and > sector number. > > There may be a free count going on with the next to the last two bytes > 0xff85 for instance in the first stick. > > Since line 0x000 is odd, i wonder if it is volume related or other with > the application of the disk. I'd guess that line 0x0007 > is also possibly volume related. > > The only deviating entry at 073 has a 7f in what I'm guessing is the > cylinder column, so maybe an "erased" entry? > > And for whatever reason, there are 6 bytes "live" in the beginning, the > two bytes of 0x0000 in all the entries as well. > > As to the missing file names, I wonder if that data is in the text of > the disk. That was one way that file > systems had to pay with variable length packed data since tables like > this was necessary with fixed length. > > I am guessing you don't want to share the file names, but I'd take the > numbers in the cylinder and sector columns > and see if you can spot something like filenames and the like. > > I had a file system on a Microdata 1621 based mini that i wrote, and we > put the directory entry in both the main > VTOC and in the heading of the first sector of the file. Thank god for > that, as one time we had a malfunction and > had to do a VTOC rebuild from scanning the entire disk, but that's > another story. > > Thanks > Jim > > On 1/8/2017 6:09 PM, Chuck Guzis wrote: >> On 01/08/2017 04:42 PM, william degnan wrote: >>> Inverse 8085? >> I don't think so. If it helps, here's the first few lines of the >> "directory": >> >> 000: 00 a1 7a c1 c0 00 00 >> 0007: 00 00 00 00 00 00 00 80 1a 02 38 00 >> 0013: a1 7a c1 c0 00 00 00 00 1b ff 00 00 >> 001f: 5c 25 15 1b 4c 40 00 00 ff ff 37 05 >> 002b: 94 2f 38 40 00 00 00 00 ff 8f 31 01 >> 0037:*c4 a3 75 6a ab 52 00 00 ff 85 25 05* >> 0043: 94 2f 38 40 00 00 00 00 ff 02 0f 02 >> 004f:*c4 a3 75 6a ab 52 00 00 ff b6 09 04* >> 005b: 94 2f 38 40 00 00 00 00 ff 03 02 03 >> 0067:*c4 a3 75 6a ab 52 00 00 ff 01 12 01* >> 0073: d0 7f 9f 12 1f bd 53 28 ff ff 7f 02 >> 007f:*c4 a3 75 6a ab 52 00 00 ff 01 2b 00* >> 008b:*c4 a3 75 6a ab 52 00 00 ff 83 28 04* >> 0097:*c4 a3 75 6a ab 52 00 00 ff 01 38 00* >> 00a3: 94 2f 3e 80 00 00 00 00 ff 01 1d 00 >> 00af: 94 2f 4b 00 00 00 00 00 ff 03 35 05 >> 00bb: 94 2f 4b 00 00 00 00 00 ff ff 3e 06 >> ... >> >> There are no other tables on disk. The disk itself is hard-sectored, >> with a sector length of 150 bytes and 16 sectors per track. They're >> interleaved 3:1 and grouped into blocks of 1200 bytes. The directory >> would correspond to block 0 and there are 72 entries in it, less the >> header. >> >> I can get the raw text, but how it's linked together and what file names >> might is still a mystery. >> >> --Chuck >> >> >> > > -- --Chuck ------------------------------------------------------------- "The first thing we do, let's kill all the spammers."
