> On Jul 17, 2023, at 12:28 PM, Henry Bent via cctalk <cctalk@classiccmp.org>
> wrote:
>
> Hi all,
>
> I just noticed that images of a full RX50 floppy set for Ultrix-32m 1.2 was
> posted on Bitsavers (
> http://bitsavers.trailing-edge.com/bits/DEC/vax/ultrix/1.2/ULTRIX-32M_V1.2_RX50_1986.zip
> ). I am having difficulty parsing these images into a usable raw format
> for SIMH.
>
> As a reference, TUHS has a set of 1.0 floppies (
> https://www.tuhs.org/Archive/Distributions/DEC/Ultrix-32M/ ) that are
> usable for installation purposes. (You can ignore the 1.2 floppies in that
> archive, they aren't actually a full set). The first disk of that
> installer, 32m-1.0-bin/01, has a bootloader that starts at byte zero as we
> would expect. This should be approximately equivalent to disk 1 in the
> Bitsavers set. Oddly though, in the "raw" dump the bootloader doesn't
> start until 0x1400, and a number of the other disks I looked at appear to
> have odd holes/zeroes in them. IMD format dumps of the 1.2 disks are
> provided but when I converted the IMD format to a raw image I got the same
> issue.
It's unfortunate that there is no description of what format these image files
have.
From your description it looks like these are physical track/sector ordered
copies of the floppy, while SIMH for the RX50 container files wants to see
logical order. One tool that can convert between the two is the "rx50.py"
utility that is part of my RSTSFLX V3 tool, a RSTS file system handler in
Python. You can find it at svn://akdesign.dyndns.org/flx/trunk (that's a
Subversion repository). Note that the rstsflx in the "simtools" repository of
Open-SIMH is V2, that's an entirely different version written in C. It also
has the interleave algorithm but no command line tool analogous to the rx50.py
tool.
The key element is that logical track 0 is physical track 1, and similarly all
the others differ by one except logical track 79 which is physical track 0.
That fits what you stated: bootloader starting at 0x1400, that is sector 10 so
the first sector in physical track 1.
The other parts of the address translation are: sectors on the track are 2:1
interleaved, and there is a 2 sector skew from each track to the next. So, for
example, logical sector 0 is physical track 1 sector 0; logical sector 1 is
physical track 1 sector 2; local sector 5 is physical track 1 sector 1, and
logical sector 10 is physical track 2 sector 2.
What you need to do is to invert that interleave algorithm to convert from the
physical sector order to the logical.
paul
