• Please review our updated Terms and Rules here

Interpreting TRSDOS 2.0 images from a Model II

david__schmidt

david__schmidt

Veteran Member
Joined
Jun 5, 2007
Messages
724
Location
Southeast US
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?
 
david__schmidt said:
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?
Click to expand...


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

marcus
 
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.
 
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.
 
david__schmidt said:
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?
Click to expand...

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/cpmarchives/trs80/Software/Model%204/L/LDOS%20v6.2%20(19xx)(Logical%20Systems%20Inc)%5bSRC%5d%5bPartial%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.
 
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.
 
david__schmidt said:
... before I try to read the LDOS source code, do any references to the filesystem structures exist?
Click to expand...

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/trs80m2/doc/TandyModel2DiskOperatingSystemReferenceManual.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/trs80m2/doc/TRSDOS-II_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:
Hello, All.

I think if you go to https://github.com/pski/model2archive/tree/master/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:
So, anyone want to start working on the Xenix disk images too? I have 0 documentation, but lots of samples.
 
I've attempted to do some of the Xenix format before, and have successfully unTARed some Xenix backup images. There's still some wading in to do there; I can see I need to look at Xenix again very soon.
 
AaronBrockbank said:
Hello, All.

I think if you go to https://github.com/pski/model2archive/tree/master/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.
Click to expand...

First, thanks much for making these available in this manner. These utilities are in my opinion best-in-class for TRS-80 formats, and I thank you.

Diskmanip is a win32 windows executable ...

M2FILE is a win32 console application ...
Click to expand...

What would be the chances of a Mac or Linux port for those of us who might not use Windows? Have you tested under Wine? I'm a Linux user myself, but I'm willing to take a whirl at running these under Wine (or trying to port to Linux, for that matter, if you aren't averse to sharing source to do so). I just have to get Wine configured for the job.....
 
lowen said:
What would be the chances of a Mac or Linux port for those of us who might not use Windows? Have you tested under Wine? I'm a Linux user myself, but I'm willing to take a whirl at running these under Wine (or trying to port to Linux, for that matter, if you aren't averse to sharing source to do so). I just have to get Wine configured for the job.....
Click to expand...

For Mac users, I've run both of these tools successfully in Windows 7 using Fusion on my Mac.
 
AaronBrockbank said:
I've attempted to do some of the Xenix format before, and have successfully unTARed some Xenix backup images. There's still some wading in to do there; I can see I need to look at Xenix again very soon.
Click to expand...

I forgot the most important thing:
Hi Aaron. Great to hear from you.

Kelly
 
PowerBASIC 3.5 under DOSbox wouldn't really work, as both PowerBASIC compilers used to make the two versions (console v6 and windows v10) won't function under DOSbox. Backporting it to PowerBASIC 3.5 would involve a complete rewrite, eliminating all windows SDK access in the process. I have no wish to reinvent wheels that have taken me four years to get this far.

Please don't look down on PowerBASIC as a lowly BASIC, it can be made to do almost anything that C could do, except maybe kernel mode drivers.
 
You must log in or register to reply here.
Back
Top