Sunday brain tickler

[Chuck Guzis]

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."