Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: Interpreting TRSDOS 2.0 images from a Model II

  1. #1

    Default Interpreting TRSDOS 2.0 images from a Model II

    I have imaged a few TRSDOS 2.0 (probably rev a) 8" disks, and I was wondering if there is any software that interprets the filesystem on them?

  2. #2

    Default

    Quote Originally Posted by david__schmidt View Post
    I have imaged a few TRSDOS 2.0 (probably rev a) 8" disks, and I was wondering if there is any software that interprets the filesystem on them?

    So my dumbo question is therefore, what did you use to do the imaging and do you have a link to sample images

    marcus

  3. #3

    Default

    I used imgdisk in this case - the low-level format is standard IBM SSDD. Track 0 is 128x26 (bytes x sectors), and tracks 1-76 are 256x26. Browsing the available docs, I see I can expect filesystem allocation in terms of "granules" (5 sectors), sector 26 is always reserved, and a catalog is on track 44. That's what I know so far without poking too hard.

    I don't know where any sample images might be found just yet... all I have right now are the ones I captured.

  4. #4

    Default

    For sample images go to https://github.com/pski/model2archive

    If by "interpreting" the file system you mean readable on a PC/Mac/Linux like TRSTools for the M1/3/4, then I am not aware of such a tool for the M2. I know there is a partial MESS implementation of the M2 so that might be a place to look. I have not played with that yet. I've been thinking about writing such a tool. Let me know if you give it a shot.

  5. #5
    Join Date
    Jan 2014
    Location
    Western North Carolina, USA
    Posts
    1,336

    Default

    Quote Originally Posted by david__schmidt View Post
    I have imaged a few TRSDOS 2.0 (probably rev a) 8" disks, and I was wondering if there is any software that interprets the filesystem on them?
    Yes, there is such software, but it runs on LS-DOS 6.3.1A for Model II. The source code is available in the LS-DOS 6.2 source archive found at http://www.classiccmp.org/cpmarchive...Partial%5d.zip Note that this source is for a beta LS-DOS 6.2; a disassembly of CONV/CMD from the 6.3.1A for II distribution disk should be compared with this 6.2 source to see if patches have been made.

    LS-DOS shipped with a CONV utility; for Model 4 LS-DOS this reads Model III TRSDOS 1.x disks. For Model II LS-DOS this reads TRSDOS 2.0 disks. Look in the file 'conv2.asm' inside that zipfile above. Les Mikesell, one of the last people to touch that code (for LDOS 5 and LS-DOS 6), frequents the CentOS mailing lists and is still around, although I've not heard anything from him in a while. The Model II port was apparently done by Kim Watt (kjw). Apparently (and totally unsurprisingly) TRSDOS 1.x for Model III uses a very similar format to the Model II TRSDOS 2.0.

    Tim Mann is also listed as one of the authors, and he writes up how he did some data recovery from a Model II SCRIPSIT disk at http://www.tim-mann.org/trs80resources.html (look down the page for the heading "Model II Scripsit" and you'll find some information, including how to patch for a nonstandard directory track location).

    Tools used included xtrs, LS-DOS 6.3.1 for Model 4, the xtrs8/dct eight-inch driver, and the CONV/CMD from LS-DOS 6.3.1A for Model II.

    Hope that helps.
    --
    Thus spake Tandy Xenix System III version 3.2: "Bughlt: Sckmud Shut her down Scotty, she's sucking mud again!"

  6. #6

    Default

    This won't give you what you want in the immediate future, but I plan to add support for understanding various filesystems of interest to my Python-based ImageDisk manipulating software:

    https://github.com/NF6X/pyImageDisk

    The filesystem code in there is nothing but an empty, untested skeleton class and some LS-DOS stuff that I'm noodling around with to figure out how I want to structure the overall filesystem support. That will all certainly change a lot as I firm up the implementation.

    The low-level .IMD manipulation is a lot more mature, though. The provided utility can examine .IMD files and tell you things about the low-level format. For example, it'll show the different address marks used on the directory track of (some? all?) TRSDOS 5.25" formats. It can also reveal the interleave, and change it if desired.

    I still consider it to be alpha level code, but I think the low level IMD manipulation stuff is stable enough to be usable, and passes a fairly thorough unit test suite.

  7. #7

    Default

    Thanks, all - this confirms my suspicions. I guess I'll get to it. Most likely home will be part of Transformenator's utility disk extractor functions:
    http://transformenator.sourceforge.net/#Utility

    Now, on to the logical filesystem... before I try to read the LDOS source code, do any references to the filesystem structures exist?

  8. #8
    Join Date
    Jan 2014
    Location
    Western North Carolina, USA
    Posts
    1,336

    Default

    Quote Originally Posted by david__schmidt View Post
    ... before I try to read the LDOS source code, do any references to the filesystem structures exist?
    The LS-DOS native format is well-documented in both the Model 4 Tech Ref (Software section) and in the Programmer's Guide to TRSDOS/LS-DOS 6 (everything except the copy/backup limited protection systems, which are documented in Pete Cervasio's LS-DOS 6.3.1 source tree).

    This actually does help you, since the Model III TRSDOS format is somewhat similar, but where it is different it is quite different. The best source of information on the Model III format is actually a very difficult to find book called 'TRSDOS Commented' which I would love to have a copy scanned. The older Model I format is very similar to the LS-DOS 6 format, and it is also quite well documented in one or two of the 'and other Mysteries' books by IJG.

    Yes, I know you're asking about Model II TRSDOS, but the basics of the filesystem are the same between almost any TRS-80 DOS (notable exceptions: TRSDOS II 4.x and Xenix). You have the concept of granules or grans (similar to the FAT format's clusters); you have a Granule Allocation Table that shows the status (free/allocated/bad) of every granule on the disk (the GAT is in the first sector of the directory track); you have a hash index table (HIT) in the second sector which allows you to find out which directory entry contains a particular filename (the filename is hashed; the hash is a pointer to a byte in the HIT that contains the directory entry number); each directory entry has filename, extension, and hashed user and owner passwords for the file as well as the granule allocation pointer chains (called 'extents' in the documentation). The specifics of the hashing functions, the size of each directory entry, whether the first sector is sector zero or sector one, and a few differences in flag bits and date/time stamps on files are the essential differences between the various TRS-80 formats.

    On the Model III TRSDOS, the hashing functions are further obfuscated by the use of some of the undocumented Z80 instructions.

    Unfortunately no one of whom I am aware has made public full documentation of the Model II TRSDOS's, but knowing what the Model III TRSDOS and the Model I TRSDOS-derived LDOS and LS-DOS are doing will help you plow through what each byte of the directory entry does, using a disk editor. Although, years ago I remember seeing a manual that listed the TRSDOS SVC's for the Model II TRSDOS; I'll have to do some looking...... as that same manual might just contain some information on the directory structure.

    Mark, I'm looking with great interest at what you're doing with your Python code!

    EDIT: Found the doc I was thinking of. See http://electrickery.xs4all.nl/comp/t...enceManual.pdf beginning on page 173. It does not appear to directly document the on-disk data structure, although a clue to the format is found in the SVC titled RAMDIR (page 225 of the PDF; page 261 of the printed manual).

    For various reasons (backup limiting and copy protection being two of them; supporting people who messed up their disks be directly munging directory entries being a third one) Tandy was averse to documenting too many details (search for a post in comp.sys.tandy by Mike Yetsko about why his own fast copy routine had to run on TRSDOS 2.0 because the TRSDOS-II 4.x programmers obfuscated the direct disk access SVCs and call points). Later TRSDOS-II is pretty well-documented (the tech stuff: http://electrickery.xs4all.nl/comp/t...RefMan_3-4.pdf ) and has the same RAMDIR SVC, and the same lack of information on the direct disk format, for the same reasons.

    EDIT 2: See the appendix E of the second document on TRSDOS-II for the differences between the older TRSDOS and TRSDOS-II. There are substantial differences that are documented in the filesystem, including allocation by sectors instead of granules, sector-level badblock lockout instead of track-level, and much larger directories, with up to 1,220 files available. This implies a much different system. But, then again, TRSDOS-II was also usable on a hard disk.
    Last edited by lowen; January 26th, 2016 at 09:48 AM. Reason: Added links to some TRSDOS for Model II technical information.
    --
    Thus spake Tandy Xenix System III version 3.2: "Bughlt: Sckmud Shut her down Scotty, she's sucking mud again!"

  9. #9

    Default

    Hello, All.

    I think if you go to https://github.com/pski/model2archiv...Software/Tools you might find a helpful tool that I've got Peter to upload for me. This is a little something that has taken me 4 years to get to this stage, and contains about 225k lines of code. There are two files, M2FILE and Diskmanip.

    Diskmanip is a win32 windows executable that will allow you to see what's on your disk images. It accepts the DMK, IMD, and TDO (unsqueezed) 8in disc images as input, and will display directories for ATON, FMG, Pickles & Trout CP/M Systems, LS-DOS 6.3.1A, DOSPLUS II A.0x, TRSDOS (1.1), 1.2x, 2.0x, and 4.x, Racet-HSDS, Corvus and UCSD Pascal formats. TRSDOS 4.0 and 4.1 are still a little spotty, and will probably lock up at this stage. I have also disabled the Catweasel and FDRAW direct reading of discs for the time being.

    M2FILE is a win32 console application that will allow extraction of the file from the above images in the formats listed; it's basically Diskmanip with extraction. I realise that the extraction doesn't always work, and tends to ignore the EOF sector/byte resulting in files that are the length as specified in the allocation table.
    Last edited by AaronBrockbank; January 28th, 2016 at 01:07 AM. Reason: grammar

  10. #10

    Default

    So, anyone want to start working on the Xenix disk images too? I have 0 documentation, but lots of samples.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •