From: grinder@no.spam.maam.com   
      
   Knut wrote:   
   > Grinder wrote:   
   >> Knut wrote:   
   >>> Grinder wrote:   
   >>>> Rick Massey wrote:   
   >>>>> I've been having a fairly non-stop headache getting my files off   
   >>>>> some Model III disk images.   
   >>>>>   
   >>>>> First, the functional details. I have several files that I either   
   >>>>> created in basic a while back or created as text files in   
   >>>>> Excaliber's program Edit. I've been trying to get these files off   
   >>>>> the images created by Readdisk, but I have been unable to find an   
   >>>>> emulator that works well enough to run programs on an XP system,   
   >>>>> has the capability to print files or copy data to the clipboard,   
   >>>>> and reads things in a native enough format that a screen reader can   
   >>>>> parse the output. (I lost my sight almost six years ago and have   
   >>>>> been unable to locate it in the intervening time)   
   >>>>>   
   >>>>> So, I either need to find an emulator that will print or copy to   
   >>>>> the clipboard on a Windows XP system while letting my screen reader   
   >>>>> access the info, or I need to find a kind soul that will  will help   
   >>>>> me out with getting these files translated to txt documents. Edit   
   >>>>> is quite intuitive once you use Clear+O to access the help menu,   
   >>>>> plus it's a plain text format so it should probably open up in any   
   >>>>> text editor or word processor. I've tried pulling data from the raw   
   >>>>> disk images, and I get some success with it, but things are rather   
   >>>>> hashed. I spent five hours recently cleaning up one file this way,   
   >>>>> and even then some of the text of the file was junked so that I had   
   >>>>> to get a sighted person to look at the file in an emulator )that I   
   >>>>> can't access and won't print) to get the missing text out.   
   >>>>>   
   >>>>> Any assistance/advice would be greatly appreciated.   
   >>>>   
   >>>> Rick sent me an example, and it appears to be a DMK disk image.  I'm   
   >>>> an interested novice, so if someone knows of an "out of the box"   
   >>>> solution you can probably get him a quick answer.   
   >>>>   
   >>>> More later...   
   >>>   
   >>> Thay are created with TRSDOS1.3 which is very incompatible with   
   >>> almost anything else... 4 of the disk I got are OK so I extracted 4   
   >>> files for him. They are indeed DMK type images.   
   >>>   
   >>> I'm not sure if export tools work for TRSDOS1.3 so I used LDOS' CONV   
   >>> command to get the files over to LDOS and then exported them 'CONV :1   
   >>> :0 (VIS)' then Y for it to convert the file. I also use XVI32, a pc   
   >>> hexeditor, to substitute CR to CRLF so the files can be read by a pc   
   >>> editor. I sent both the straight file and the pc readable one.   
   >>>   
   >>> The bad disk images didn't read even with TRSDOS1.3   
   >>   
   >> Rick, if you're watching, send me the images that Knut couldn't get   
   >> read.  Knut: was one of the bad images named SWORDS.DSK?   
   >   
   > No I didn't get that. I read PSICHART, PSICLASS, SKILL1 and SKILL5 and   
   > those that failed were SKILL2, SKILL3 and SKILL4.   
   >   
   > TRSDOS1.3 gave error 04 on them while LDOS' CONV said unable to read   
   > sector. I guess those images weren't properly created or "taken out"   
   > before all writing was done. So probably not a problem with the file in   
   > itself, I think.   
   >   
   > My method wouldn't have any problem with images with lots of files.   
   >   
   > I did also try an old virtual-disk tool I had but it couldn't read   
   > TRSDOS1.3 disks. TRSDOS1.3 has no sector 0, numbering the sectors from 1   
   > to 18 rather than 0 to 17. This thwarts almost any tool I have, even zap   
   > type tools.   
      
   I was able to get 16K worth of text out of SWORDS.DSK just by reading   
   the sectors in order (de-interleaving them, that is) and jamming it all   
   into a text file.  There really was only one file on the disk, so that   
   worked about.  The file appears truncated, though.   
      
   The image header indicated that there are 40 tracks of 0x1900 bytes.   
   Every other track was zero-filled, though.  Maybe that's the way images   
   of single-sided disks are made?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)