• Please review our updated Terms and Rules here

RT-11 floppy disks conversion

P

per

Veteran Member
Joined
Jan 21, 2008
Messages
3,052
Location
Western Norway
Hi

I am waiting for some 8" floppies with some RT-11 software on them. There's Fortran and BASIC, and the expected pile of games. Several of the floppies also seems to have a system installed, so I guess these are bootable.

Now, I don't own and I have not used any PDP-11 type machine before, but I plan on archiving these disks anyways. I may also have a small chance of getting my hands on a DEC Professional 350. In the mean time, what I am trying to figure out is.. what is the most convenient way of getting the content of these 8" disks over to the 5.25" format used on the Pro350?
 
It depends on if these are RX02 or RX01 disks. RX01 disks can be read using a standard PC with a floppy controller and a 50 pin to 34 pin adapter.

RX02 need somthing different. The format of RX02 is very peculiar. MFM data with FM headers. I am using catweasel but I think Applesauce works as well as Kryoflux. Perhaps also greasewezel?
 
MattisLind said:
It depends on if these are RX02 or RX01 disks. RX01 disks can be read using a standard PC with a floppy controller and a 50 pin to 34 pin adapter.

RX02 need somthing different. The format of RX02 is very peculiar. MFM data with FM headers. I am using catweasel but I think Applesauce works as well as Kryoflux. Perhaps also greasewezel?
Click to expand...
I read these off low-level into images in SuperCardPro format using my own hardware setup, so that's not a problem!
 
Then I suggest that you convert the images into a format that can be read by SimH and start RT-11 in there. Then you can simulate a machine with both RX0x and RX50 and copy the contents between the two disks. Finally you need to convert the RX50 image to physical medium. The blocks are stored in a peculiar way on RX50 as far as I understand so the mapping back requires some software.
 
Code: 
ImageUtilsX -from m013.new.dsk rx01 -to m013.new.rx50.dsk rx50
Code: 
NAME

 - DEC device images unpacker v2.0 beta
(compile 24.01.2024 on 21:25(+04)

(c) 2022-2024 Hunta <some@where.on.net


SYNOPSIS

Command line options are processed strictly left-to-right.

ImageUtilsX  --help --errorlog [ <filename>] --dos11 --xxdp --rt11 --ods1
          --size <size> --pack <dirname> <filename> <devicetype>
          --unpack <filename> <dirname> [ <devicetype>]
          --from <filename> [ <devicetype>] --to <filename> [ <devicetype>]

Command line options:
-?    | --help
          Print help.
-err  | --errorlog [ <filename>]
          The name of the file with information about read errors
-dos  | --dos11
          Select DOS-11 file system for following --device or --shareddevice options.
          New image files are create with an empty DOS-11 file system.
-xx   | --xxdp
          Select XXDP file system for following --device or --shareddevice options.
          New image files are create with an empty XXDP file system.
-rt   | --rt11
          Select RT11 file system  for following --device or --shareddevice options.
-rsx  | --ods1
          Select RSX file system  for following --device or --shareddevice options.
-s    | --size <size>
          Override size of TU58 imagefile.
          <size> is number of bytes; suffix "K": * 1024, suffix "M": * K * K.
          Smaller images are enlarged, greater are trunc'd if possible.
          Devices and file system try to adapt.
          Works for XXDP non-boot-tapes, and RT-11 with patched DD.SYS driver.
          "--size std" clears overriden size.
          Simple example:  -s 10M
              image is 10 Megabytes = RL02 sized.
-pk   | --pack <dirname> <filename> <devicetype>
          Read files from a directory and pack into binary disk/tape image
          <DeviceType> can specify a different device geometry for the image,
          allowed: NoDev,TA11,TM11,TU56,TU58,RX01,RX01N,RX02,RX02N,FD1,RX50,RX50N,DSRX50,DRX50N,DRX50N2,OSA0,OSA1,OSAH0,OSAH1,APPLE,APPLEN,APPLE0,APPLE1,RF11,RS034,RK035,RL01,RL02,RL02V2,RL02V3,RK067,RP0456,RM03,DU,RD,HX,DWK
-up   | --unpack <filename> <dirname> [ <devicetype>]
          Read a binary disk/tape image, and extract files into directory
          A filesystem type must be specified (like -xxdp)
          <DeviceType> can specify a different device geometry for the image,
          allowed: NoDev,TA11,TM11,TU56,TU58,RX01,RX01N,RX02,RX02N,FD1,RX50,RX50N,DSRX50,DRX50N,DRX50N2,OSA0,OSA1,OSAH0,OSAH1,APPLE,APPLEN,APPLE0,APPLE1,RF11,RS034,RK035,RL01,RL02,RL02V2,RL02V3,RK067,RP0456,RM03,DU,RD,HX,DWK
-from | --from <filename> [ <devicetype>]
          Convert image from one device type to another device type - From part
          <DeviceType> can specify a different device geometry for the image,
          allowed: NoDev,TA11,TM11,TU56,TU58,RX01,RX01N,RX02,RX02N,FD1,RX50,RX50N,DSRX50,DRX50N,DRX50N2,OSA0,OSA1,OSAH0,OSAH1,APPLE,APPLEN,APPLE0,APPLE1,RF11,RS034,RK035,RL01,RL02,RL02V2,RL02V3,RK067,RP0456,RM03,DU,RD,HX,DWK
-to   | --to <filename> [ <devicetype>]
          Convert image from one device type to another device type - To part
          <DeviceType> can specify a different device geometry for the image,
          allowed: NoDev,TA11,TM11,TU56,TU58,RX01,RX01N,RX02,RX02N,FD1,RX50,RX50N,DSRX50,DRX50N,DRX50N2,OSA0,OSA1,OSAH0,OSAH1,APPLE,APPLEN,APPLE0,APPLE1,RF11,RS034,RK035,RL01,RL02,RL02V2,RL02V3,RK067,RP0456,RM03,DU,RD,HX,DWK

Option names are case sensitive.

EXAMPLES

ImageUtilsX -rt11 -unpack C:\RT11\image.dsk C:\RT11\ImageUnpacked
 
Last edited:
shirsch said:
Where does one find this ImageUtilsX application? Too much noise to effectively Google it.
Click to expand...
This is the Joerg Hoppe's TU58fs program, rewritten by me from C to C#, subsequently divided by functionality (only ImageUtilsX is now involved in unpacking and creating the image), modified to support DOS-11 and ODS-1 FS, as well as various interleaving options and additional functionality. Currently, you can only get it from me upon request - due to the fact that it is constantly being improved and some functionality has not yet been implemented. For now, creating images only works for RT-11 FS.
 
shirsch said:
It's contained in the comments at the top of the utilitiy sources. Let me know if anything is not clear?
Click to expand...
Well, I read the Python comments but IMO they're not an "explanation of the process and rationale", so I was assuming that there was some other document somewhere that I had missed. Pperhaps a compendium from the Discord chat holds that, somewhere?
 
The "process" (such as it was) went on for several days and over a dozen messages that I'm not going to repost here. Short answers:

  • Data on RX50 diskettes begins on the second track and wraps around to include track 0 at the very end (assuming the diskette was not intended to be bootable). An emulation image starts at what would be the second track and has any track 0 contents at the end.
  • An RX50 diskette returns data in proper order when you ignore physical position on the diskette and process sectors by their header id numbers (1..n). An emulation image contains the data in the same physical order as they appeared on the media - which is NOT a proper logical ordering. This strikes me as absolutely bizzare, but I'm told that's the way RT-11 returns them on successive reads.
My programs allow you to convert between these two representations. All flux readers I'm aware of render an RX50 image that must be converted for SIMH. Conversely, you must convert a SIMH image if you intend to write it back to media.
 
Got the imaging going. More or less all disks seem to be single sided, about half of them flippable.

Looking at the data, am I right that these are both hardware- and software-interleaved? That seems quite a bit like an odd choice..

Also, most of the difficult to read sectors seems to be unused. Looking at the bitstream, it’s clear that's due to the drive used for formatting those disks once uppon a time, had a terribly worn spindle belt.
 

Attachments

  • DSC_0360.JPG
    DSC_0360.JPG
    4.3 MB · Views: 13
per said:
I see now that the HW sectors on the DEC disks are sequential.
Click to expand...
Yes, if the interleaving were hardware-based, this could be seen from the location of the sectors on the disk, but the image captured by software would be without interleaving. And then there would be no need for utilities to restore the logical order of sectors :) ImageUtils describes many disk images precisely because of software interleaving.
 
Since these are all RX01, my plan is to convert them to sector-images, that would be with the software interleave in place (the FM/MFM decoder I use undoes the hardware interleave for this, if present).
 
You must log in or register to reply here.
Back
Top