Re: Sunday brain tickler

[Chuck Guzis]

On 01/09/2017 02:58 PM, allison wrote:

> Low majik there...   8 bytes of 7 bit ascii means one free bytes
> worth of bits, to do that start with an 8byte area as 64 bits and
> stuff the bits.   The only question is are the left justified or
> right a few minutes by hand can discover that. Done that way 9
> characters fit in 8 bytes.

> Another allocation scheme is one page per track, about 1200-1500
> bytes, or about 35 pages for a 35track floppy.   So each tack is a
> page and the file header has the page name and a linked list to the
> next.

There are actually 16 150-byte sectors (4 byte header in the form of DB
TT SS CC where CC is the arithmetic sum of TT and SS, followed by 151
bytes of data, with the last byte being the simple sum of bytes 1-150
modulo 256. Encoding is simple FM, with no "funny" missing clock bits.

The sectors are ordered in two groups of 1200 bytes:

0,11,6,1,12,7,2,13 and 8,3,14,9,4,15,10,5

There are 70 groups on the disk, obviously.

I've learned that the 103 was a 32KB 8080 system, so not so sophisticated.

It's the filename encoding that has me stymied, not the data retrieval
itself.

--Chuck

Re: Sunday brain tickler

[allison]

On 01/09/2017 12:51 PM, Chuck Guzis wrote:
> On 01/09/2017 09:28 AM, Fred Cisin wrote:
>> Need there BE a filename?
>>
>> An OS, particularly for a word processor, could have an IMPLICIT list
>> of filenames on a disk of DOCUMENT1 DOCUMENT2 DOCUMENT3
>
> I found this document:
>
> http://www.dtic.mil/get-tr-doc/pdf?Location=U2=GetTRDoc.pdf=ADA199551
>
> about transferring Lanier "No Problem" files to a Unix (Gould 9050)
> mini.  The interchange program was a serial-comms program, so no value
> to disk interpretation.
>
> However, in section 2.2, there's light shed on how the Lanier manages
> its files.  Very unusual, but might well explain some of the directory bits.
>
> But apparently files were named--and some sort of name compression
> appears to be in use as the name of the comms program is 9 characters
> long, while the file name area appears to be only 8 bytes in length.
Low majik there...   8 bytes of 7 bit ascii means one free bytes worth
of bits,
to do that start with an 8byte area as 64 bits and stuff the bits.   The
only
question is are the left justified or right a few minutes by hand can
discover
that. Done that way 9 characters fit in 8 bytes.

Another allocation scheme is one page per track, about 1200-1500 bytes,
or about 35 pages for a 35track floppy.   So each tack is a page and the
file
header has the page name and a linked list to the next.

There are more ways to organize a disk than Carter has liver pills.

Allison

>
> --Chuck
>

Re: Sunday brain tickler

[Chuck Guzis]

On 01/09/2017 03:33 PM, Jules Richardson wrote:

> It seems unlikely that a simple system would resort to something
> like frequency analysis of characters when encoding filenames,
> though, particularly given the size of the data (the overhead would
> probably not make it worthwhile) - so I'm guessing we should be
> looking at "plain text", just with some unusual character size or
> distribution.
> 
> I did hack some quick code to alter the character size (6, 7 and 8 
> bits), spacing between characters (0, 1 and 2 bits) and offset from
> the start of the stream, then 'slide' the resulting data through the
> ASCII table and search for the "LTER" name that you mentioned
> previously, but without any luck. That does make the assumption that
> values for A-Z are contiguous, which seems likely but not certain.


Given the simple 8080 architecture, we may be looking at "rotated" bits
also; I don't know.

But rest assured, every block after the first (directory) block contains
text.  There are no "hidden" file names.

--Chuck

Re: Sunday brain tickler

[Jules Richardson]

On 01/09/2017 11:51 AM, Chuck Guzis wrote:

On 01/09/2017 09:28 AM, Fred Cisin wrote:

Need there BE a filename?

An OS, particularly for a word processor, could have an IMPLICIT list
of filenames on a disk of DOCUMENT1 DOCUMENT2 DOCUMENT3



I found this document:

http://www.dtic.mil/get-tr-doc/pdf?Location=U2=GetTRDoc.pdf=ADA199551

about transferring Lanier "No Problem" files to a Unix (Gould 9050)
mini.  The interchange program was a serial-comms program, so no value
to disk interpretation.


I suppose *if* you had a disk with the program on then it would give a 
known name to be searching for... except that the doc seems to call it 
TTY_ASCII in places and ASCII-TTY in others :-(



But apparently files were named--and some sort of name compression
appears to be in use as the name of the comms program is 9 characters
long, while the file name area appears to be only 8 bytes in length.


It seems unlikely that a simple system would resort to something like 
frequency analysis of characters when encoding filenames, though, 
particularly given the size of the data (the overhead would probably not 
make it worthwhile) - so I'm guessing we should be looking at "plain text", 
just with some unusual character size or distribution.


I did hack some quick code to alter the character size (6, 7 and 8 bits), 
spacing between characters (0, 1 and 2 bits) and offset from the start of 
the stream, then 'slide' the resulting data through the ASCII table and 
search for the "LTER" name that you mentioned previously, but without any 
luck. That does make the assumption that values for A-Z are contiguous, 
which seems likely but not certain.


I didn't look at 5 bit characters, which is a possibility if only alpha 
characters and not numerics are allowed in filenames.


I'm not sure if filenames are stored in their entirety, though - I think 
there was an example in that PDF which seemed to imply that pages have 
their own short names, and that these might be concatenated to form an 
overall name for the group of pages - I need to do more than just skim-read 
the document to understand that. It makes me wonder if there isn't some 
very short (2 or 3 character) limit on individual directory entries though, 
and these are chained together to make a larger name (and file)?


cheers

Jules

Re: Sunday brain tickler

[Chuck Guzis]

On 01/09/2017 09:28 AM, Fred Cisin wrote:
> Need there BE a filename?
> 
> An OS, particularly for a word processor, could have an IMPLICIT list
> of filenames on a disk of DOCUMENT1 DOCUMENT2 DOCUMENT3


I found this document:

http://www.dtic.mil/get-tr-doc/pdf?Location=U2=GetTRDoc.pdf=ADA199551

about transferring Lanier "No Problem" files to a Unix (Gould 9050)
mini.  The interchange program was a serial-comms program, so no value
to disk interpretation.

However, in section 2.2, there's light shed on how the Lanier manages
its files.  Very unusual, but might well explain some of the directory bits.

But apparently files were named--and some sort of name compression
appears to be in use as the name of the comms program is 9 characters
long, while the file name area appears to be only 8 bytes in length.

--Chuck

Re: Sunday brain tickler

[Chuck Guzis]

The web search breadth increases a bit when the term "No Problem" is
substituted for "103" when looking for Lanier documents.  Not much, but
there are some tidbits.

Such as:

" Its main drawback was that it was a page-oriented program as opposed
to a document-oriented program. You got only 99 lines on a page, and
then you had to store that on disk and start the next page. That made it
cumbersome to go back and review what was on previous pages. That
99-line limitation was in part a function of limited memory. In those
days memory was expensive and most computers had only 32K of RAM. The
Lanier No Problem was a 32K machine and both the program and the
document you were working on had to be in memory at the same time. To
get around these shortcomings the Lanier would repaginate, that is, take
your original document and break it up into pages of the length you
wanted. "

--Chuck

Re: Sunday brain tickler

[Fred Cisin]

Need there BE a filename?

An OS, particularly for a word processor, could have an IMPLICIT list of 
filenames on a disk of

DOCUMENT1
DOCUMENT2
DOCUMENT3

in which case, the table that you have found could be little more than 
record keeping of which "documents" are allocated V free-space, how 
much of the "document" is used (file-length), and maybe date?

Re: Sunday brain tickler

[Adam Sampson]

Chuck Guzis  writes:

> I can get the raw text, but how it's linked together and what file
> names might is still a mystery.

The Lanier 103 is apparently a rebadged AES Superplus, and one owner
says:

"The word processor had some strange features, such as each page had to
be stored as a separate file, which made adding text to page 1 quite a
chore!"
http://vintagecomputers.site90.net/aes/

So perhaps there's something unusual going on with the "filesystem"
structure...

-- 
Adam Sampson  

Re: Sunday brain tickler

[Chuck Guzis]

On 01/08/2017 06:25 PM, allison wrote:

> I haven't ground on what it may be but there are four likely 
> directory/catalog cases.


I've certainly seen my share of various filesystems.  In fact, I can
laboriously reconstruct the original files, there being only 70 1200
byte blocks on the disk.  I thought that having a file name might be useful.

I'm just a bit weary of deciphering this one-off and can't get my mind
in the right frame to paw through the directory structure.

But I put it to you that there exactly 72 (or 71) entries in this list
and there are exactly 70 1200-byte blocks--and, make no mistake, they
are 1200-byte blocks with a definite format--a header followed by text.
Short blocks are denoted by a control character sequence, after which
old data to the end of the block may be found.  So it's quite possible
to splice the bits together into complete documents.

But that's cheating--I'd like to understand how the first block
directory dictates the relationship between blocks and any file names.

So let's look at the directory again--note the 11th bytes all either
have values less than 70 (decimal).  I'm guessing that that's a forward
link to the next block--note that 7F is the only out-of-range value
present in this column.  I suspect that this is the end-of-file marker.

This is all guessing at this point.

--Chuck

Re: Sunday brain tickler

[allison]

On 01/08/2017 09: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
>
>
I haven't ground on what it may be but there are four likely
directory/catalog cases.

Bag and tag, the file name starting block (or group of blocks) and
number of blocks.
usually byte pairs or longer ((16, 24, or 32bits) to get enough
addressing and large
enough byte counts.

CP/M like with entries for file name then a short list of allocation
blocks, additional entries
if the file is larger and needs for allocation blocks.  FYI CPM it can
be byte pairs or
single byte allocation list.

unix like with a simple filename and pointer to Inode there the metadata
and block list is.

Last case is a reserved set of blocks that are allocated as a linked
list and the directory
block has the filename and point to the start of the list.  Like unix
that can easily support
subdirectories.

None of those are processor specific but the cpu used often determines
things like if
there is bit packing.

As to radix, anything is possible also simeple things like high bit of a
8bit byte suggests
a control code or extended characters (or several things).

Allison

Re: 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 0x 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."

Re: Sunday brain tickler

[jim stephens]

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 0x 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

Re: Sunday brain tickler

[Chuck Guzis]

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

Re: Sunday brain tickler

[william degnan]

Inverse 8085?

Bill Degnan
twitter: billdeg
vintagecomputer.net
On Jan 8, 2017 7:38 PM, "Chuck Guzis"  wrote:

> On 01/08/2017 04:24 PM, Jules Richardson wrote:
> > On 01/08/2017 10:03 AM, Chuck Guzis wrote:
> >> I'm looking at a sample of what I see as a directory of sorts and
> >> am attempting to decode the file names from it.  They're not
> >> anything as elegant as Rad50, but the encoding has escaped my weary
> >> brain.
> >
> > Hmm, do you have any clues to go on? Knowledge of what some of the
> > names might logically be, whether filename extensions were a concept
> > or not, whether uppercase/lowercase/punctuation in names was
> > supported etc.?
> >
> > What would be really handy I suppose would be a disk where the user
> > had written some of the document names on the label :-)
>
>
> About all I can offer is that the names may (not certain) include the
> string "LTER".
>
> Typical work for me, I'm afraid.  Keeps me young.
>
> --Chuck
>

Re: Sunday brain tickler

[Chuck Guzis]

On 01/08/2017 04:24 PM, Jules Richardson wrote:
> On 01/08/2017 10:03 AM, Chuck Guzis wrote:
>> I'm looking at a sample of what I see as a directory of sorts and
>> am attempting to decode the file names from it.  They're not
>> anything as elegant as Rad50, but the encoding has escaped my weary
>> brain.
> 
> Hmm, do you have any clues to go on? Knowledge of what some of the
> names might logically be, whether filename extensions were a concept
> or not, whether uppercase/lowercase/punctuation in names was
> supported etc.?
> 
> What would be really handy I suppose would be a disk where the user
> had written some of the document names on the label :-)


About all I can offer is that the names may (not certain) include the
string "LTER".

Typical work for me, I'm afraid.  Keeps me young.

--Chuck

Re: Sunday brain tickler

[Jules Richardson]

On 01/08/2017 10:03 AM, Chuck Guzis wrote:

I'm looking at a sample of what I see as a directory of sorts and am
attempting to decode the file names from it.  They're not anything as
elegant as Rad50, but the encoding has escaped my weary brain.


Hmm, do you have any clues to go on? Knowledge of what some of the names 
might logically be, whether filename extensions were a concept or not, 
whether uppercase/lowercase/punctuation in names was supported etc.?


What would be really handy I suppose would be a disk where the user had 
written some of the document names on the label :-)