On Thu, Sep 14, 2017 at 11:57 AM, Rod Smallwood via cctalk < cctalk@classiccmp.org> wrote:
> > > On 14/09/2017 18:37, Rod Smallwood via cctalk wrote: > >> >> >> On 14/09/2017 17:55, Paul Koning via cctalk wrote: >> >>> On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk < >>>> cctalk@classiccmp.org> wrote: >>>> >>>> >>>> On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk < >>>>> cctalk@classiccmp.org> wrote: >>>>> >>>>> >>>>> >>>>> On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote: >>>>> >>>>>> You have some .dsk images of SSDD 96tpi for 11/73. >>>>>> >>>>> I have some also, and would love if there is a writeup of a known >>>>> working procedure to use as a reference. >>>>> >>>>> Having a list of programs and systems is great, but I'd also like to >>>>> know a few formulas that absolutely worked for someone as a starting >>>>> point. >>>>> >>>>> We have copies of a VMS 4.3 floppy set on RX50's which we will image >>>>> as well, and using something other than the DEC hardware will be useful. >>>>> >>>> It's easy on Linux. PC 5.25 inch drives have settable format >>>> parameters. The PC default is 9 sectors per track, but you can set it to >>>> 10 for RX50 compatibility. >>>> >>>> At one point you'd do that with an entry in /etc/fdprm: >>>> >>>> rx50 800 10 1 80 0 0x23 0x01 0xDF 0x50 >>>> >>>> There's still a command line approach, I forgot the command name >>>> though. You can also do it under program control with the the FDSETPRM >>>> ioctl. I have some Python code (in my "FLX" utility for operating on RSTS >>>> file systems) that does this. >>>> >>>> One complication: if you have an image which has the blocks in logical >>>> order, you need to shuffle them to account for the strange track numbering, >>>> interleaving, and track to track sector skew. Here's a program that will >>>> do that. (It operates on image files, not on the actual floppy drive.) >>>> >>> Ok, attachments get stripped. Here it is. >>> >>> #!/usr/bin/env python3 >>> >>> """rx50.py >>> >>> This is a simple program to convert between interleaved and >>> non-interleaved >>> (logical block order) layouts for RX50 floppies or container files. >>> >>> Invocation: >>> rx50.py [-i] infile [-i] outfile >>> >>> If the filename is preceded by -i, that file is/will be interleaved. >>> Infile >>> or outfile may be an actual floppy (in which case -i is in effect >>> automatically). >>> While it is legal to specify -i twice, or not at all, this is rather >>> uninteresting >>> because it merely makes an image copy of the container in a fairly >>> inefficient >>> manner. >>> """ >>> >>> from rstsio import disk >>> import sys >>> >>> def main (args): >>> a = iter (args) >>> il = False >>> ifn = next (a) >>> if ifn == "-i": >>> il = True >>> ifn = next (a) >>> idisk = disk.Disk (ifn, interleave = il) >>> il = False >>> ofn = next (a) >>> if ofn == "-i": >>> il = True >>> ofn = next (a) >>> odisk = disk.Disk.create (ofn, idisk.sz, interleave = il) >>> odisk.setrwdisk (True) >>> dcns = idisk.sz // idisk.dcs >>> for i in range (dcns): >>> ic = idisk.readclu (i) >>> oc = odisk.newclu (i) >>> oc[:] = ic >>> odisk.flush () >>> idisk.close () >>> odisk.close () >>> >>> if __name__ == "__main__": >>> main (sys.argv[1:]) >>> >>> Sounds good. >> But I have to work with what I have: >> >> An 11/73 with: >> One serial (console) line >> An RX50 booting xxdp >> A CQD220 SCSI controller with a DSP5200s attached. >> RT11 customer diagnostics A and B >> >> The DSP5200S is formatted and is seen as DU6 >> >> One PC running windows 10 >> >> There's no Linux systems, no C compilers, emulators or weird hardware >> available. >> >> But I do have a Rainbow which is the console to the 11/73 >> >> I just need to write the RT11 disk images I have to RX50 using the >> Rainbow. >> >> I found this > As part of my entry for this year's RetroChallenge Winter Warm-Up ( > http://retrochallenge.net/2009/winter/news.html), > I've created some disk imaging utilities for the Rainbow 100. > Specifically, the utilities can create RX50 images from disks, or write > disks from RX50 images, similar to dd on GNU/Linux and rawrite on > Windows/DOS. > The utilities are downloadable from my blog (http://jeff.rainbow-100.com/? > p=50). > > But its a dead end Why is it a dead end? I've used that very program to read/write all the Venix disks... Jeff may be running his site on his rainbow again, which isn't the most stable connection there is (since the Rainbow is serial only, no ethernet[*]). I've hacked on this to improve it, but the improvements are all on my Rainbow (and many are one-off hacks designed to cope with media that's in the throws of failure, but that hasn't thrown in the towel just yet). I've uploaded a copy of rbimg to http://people.freebsd.org/~imp/rbimg.zip, which I believe is Jeff's original. Warner
