Inverse 8085? Bill Degnan twitter: billdeg vintagecomputer.net On Jan 8, 2017 7:38 PM, "Chuck Guzis" <cclist at sydex.com> wrote:

On 01/08/2017 09:09 PM, Chuck Guzis wrote: 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

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:

Chuck Guzis <cclist at sydex.com> writes: 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 <ats at offog.org> <http://offog.org/>

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?

On 01/09/2017 12:51 PM, Chuck Guzis 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 more ways to organize a disk than Carter has liver pills. Allison

On 01/09/2017 11:51 AM, Chuck Guzis wrote: 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 :-( 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

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