[TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Team Unix,

Is there a Windows or Linux utility to create a disk image in any of the
above formats, from a local folder tree?

Paul

*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com

[-- Attachment #2: Type: text/html, Size: 681 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Ronald Natalie]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Eh?   An RL is just a cartridge disk drive, not a format.    It would depend on what the operating system you are using wanted to put on it.
Similarly the RX is just a floppy drive.    In my memory, there wasn’t much UNIX use of these drives.   The main reason the driver existed on the
VAX unices was to write the Console Floppy Disk in the 780 (which was in RT-11 format).

What are you trying to do?

> On Jun 1, 2020, at 6:18 AM, Paul Riley <paul@rileyriot.com> wrote:
> 
> Team Unix,
> 
> Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree?
> 
> Paul
> 
> Paul Riley
> 
> Mo: +86 186 8227 8332
> Email: paul@rileyriot.com <mailto:paul@rileyriot.com>
> 


[-- Attachment #2: Type: text/html, Size: 1999 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Ron,

Trying to move a large number of source files from my Windows machine to
the LSX simulation (or V6 simulation). This is a Unix forum, so I didn’t
explicitly say in a Unix format, but that was implied, sorry.

Paul

On Mon, 1 Jun 2020 at 9:01 pm, Ronald Natalie <ron@ronnatalie.com> wrote:

> Eh?   An RL is just a cartridge disk drive, not a format.    It would
> depend on what the operating system you are using wanted to put on it.
> Similarly the RX is just a floppy drive.    In my memory, there wasn’t
> much UNIX use of these drives.   The main reason the driver existed on the
> VAX unices was to write the Console Floppy Disk in the 780 (which was in
> RT-11 format).
>
> What are you trying to do?
>
> On Jun 1, 2020, at 6:18 AM, Paul Riley <paul@rileyriot.com> wrote:
>
> Team Unix,
>
> Is there a Windows or Linux utility to create a disk image in any of the
> above formats, from a local folder tree?
>
> Paul
>
> *Paul Riley*
>
> Mo: +86 186 8227 8332
> Email: paul@rileyriot.com
>
>
> --
*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Mon, Jun 1, 2020 at 6:19 AM Paul Riley <paul@rileyriot.com> wrote:

> Is there a Windows or Linux utility to create a disk image in any of the
> above formats, from a local folder tree?
>
What I think you are asking, is there a utility for a modern OS that will
walk a local folder tree on my OS and create a new file whose structure is
that of the file system for OS <insert yours here>.

The issue is not the device as much as the OS and disk file layout.    As
far as UNIX (or simh at the OS level) is concerned, the disk is just a
linear array of bytes, addressed by blocks.  The physical format is not
seen by UNIX.

There are numerious utilities, as well as 'foreign file systems' that are
available.   For instance, many Unix's can write RT-11 and MS-DOS format
with standard utilities.   It really depends the OS.  That said,
if the target OS is modern enough to support NFS or Samba, the easiest way
might be export the file system from local system, and then running a
simulated OS, 'mount' the file system.

[-- Attachment #2: Type: text/html, Size: 2153 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Clem,

Thanks for your help. You’ve correctly interpreted my question.

Is the disk image independent from the disk hardware? I’d assume that
different disks may have different block sizes etc, so the disk type may be
important.

The target system is LSX, a cut-down version of V6 designed to run on the
LSI-11. There are very few system utilities in the standard build (no mount
for example). The second floppy is permanently mounted at boot time. I’m
interested in making source file floppies on my modern system to use on the
LSX, so I want to be able to create an image file from a source folder tree.

Paul

On Mon, 1 Jun 2020 at 9:05 pm, Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Jun 1, 2020 at 6:19 AM Paul Riley <paul@rileyriot.com> wrote:
>
>> Is there a Windows or Linux utility to create a disk image in any of the
>> above formats, from a local folder tree?
>>
> What I think you are asking, is there a utility for a modern OS that will
> walk a local folder tree on my OS and create a new file whose structure is
> that of the file system for OS <insert yours here>.
>
> The issue is not the device as much as the OS and disk file layout.    As
> far as UNIX (or simh at the OS level) is concerned, the disk is just a
> linear array of bytes, addressed by blocks.  The physical format is not
> seen by UNIX.
>
> There are numerious utilities, as well as 'foreign file systems' that are
> available.   For instance, many Unix's can write RT-11 and MS-DOS format
> with standard utilities.   It really depends the OS.  That said,
> if the target OS is modern enough to support NFS or Samba, the easiest way
> might be export the file system from local system, and then running a
> simulated OS, 'mount' the file system.
>
-- 
*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com

[-- Attachment #2: Type: text/html, Size: 3865 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Ronald Natalie]

As far as the early UNIXs go, any disk is collection of 512-byte blocks.     The filesystems either the early (what I’ll call V6) and the later (V7) don’t differ much.
The primary difference is that the later V7 had 16-bit uids and a provision for larger file systems/sizes.    The V6 file system was limited to 2^24 blocks while V7
did 2^32.

The 512 block size corresponded to the native sector size of all the DEC hardware except the RX which I think only had 128-byte sectors.    But again, we didn’t
do much with that other than write the standalone console disks for the 780 (in RT format) and I also used it to make “unix” file system disks for the BRL “LOS”
(little operating system…no time for sharing, uniprocessor system) that ran our internet routers and the IO hardware on the HEP supercomputer.

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

Thanks Ron, and all others.

Theres plenty of grist for the mill, time for me to grind it.

Paul

*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Tue, 2 Jun 2020 at 07:59, Ronald Natalie <ron@ronnatalie.com> wrote:

> As far as the early UNIXs go, any disk is collection of 512-byte blocks.
>    The filesystems either the early (what I’ll call V6) and the later (V7)
> don’t differ much.
> The primary difference is that the later V7 had 16-bit uids and a
> provision for larger file systems/sizes.    The V6 file system was limited
> to 2^24 blocks while V7
> did 2^32.
>
> The 512 block size corresponded to the native sector size of all the DEC
> hardware except the RX which I think only had 128-byte sectors.    But
> again, we didn’t
> do much with that other than write the standalone console disks for the
> 780 (in RT format) and I also used it to make “unix” file system disks for
> the BRL “LOS”
> (little operating system…no time for sharing, uniprocessor system) that
> ran our internet routers and the IO hardware on the HEP supercomputer.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1859 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]

Frankly, using a common tape format, and then a raw disk as the 'tape'
tends to be easy.  For instance,  if it's an older system like v6, there is
a binary for v6tar kicking around that was created as part of the v7
conversion utilities (or you can build it yourself with a little work - the
issue a few changes in some headers).   Put that binary on your v6 system.
 Then create a tar image on your modern system.   Tar uses a threaded ASCII
header and actually had a bug in it, that is exploited as an extension
mechanism and became a feature (I'll explain off line if need be).  So
modern tar's will produce a checksum that the original's will correctly
accept.  Note the modern tar can create >>file types<< that the old tar
will not understand, but it will just skip them.

Going the back works too, but is limited by the original's handling of
things like directories.  It is generally not a problem.

So, the result is that you can attach that 'tarball' as a raw disk on simh
and then read it with v6tar.

Another possible way to go it to try to get stp(1) to compile on the more
modern system [it's on the Harvard tape IIRC -- it was the first version of
tp in C -- earlier versions were in PDP-11 assembler).  But ...  since that
was written with the a pre-Typesetter C compiler, and has a PDP-11 binary
format knowledge in it and I think used Lesk's portable I/O package, so it
might be a little more difficult to get running on a more modern C.

On Mon, Jun 1, 2020 at 6:45 PM Paul Riley <paul@rileyriot.com> wrote:

> Clem,
>
> Thanks for your help. You’ve correctly interpreted my question.
>
> Is the disk image independent from the disk hardware? I’d assume that
> different disks may have different block sizes etc, so the disk type may be
> important.
>
> The target system is LSX, a cut-down version of V6 designed to run on the
> LSI-11. There are very few system utilities in the standard build (no mount
> for example). The second floppy is permanently mounted at boot time. I’m
> interested in making source file floppies on my modern system to use on the
> LSX, so I want to be able to create an image file from a source folder tree.
>
> Paul
>
> On Mon, 1 Jun 2020 at 9:05 pm, Clem Cole <clemc@ccc.com> wrote:
>
>>
>>
>> On Mon, Jun 1, 2020 at 6:19 AM Paul Riley <paul@rileyriot.com> wrote:
>>
>>> Is there a Windows or Linux utility to create a disk image in any of the
>>> above formats, from a local folder tree?
>>>
>> What I think you are asking, is there a utility for a modern OS that will
>> walk a local folder tree on my OS and create a new file whose structure is
>> that of the file system for OS <insert yours here>.
>>
>> The issue is not the device as much as the OS and disk file layout.    As
>> far as UNIX (or simh at the OS level) is concerned, the disk is just a
>> linear array of bytes, addressed by blocks.  The physical format is not
>> seen by UNIX.
>>
>> There are numerious utilities, as well as 'foreign file systems' that are
>> available.   For instance, many Unix's can write RT-11 and MS-DOS format
>> with standard utilities.   It really depends the OS.  That said,
>> if the target OS is modern enough to support NFS or Samba, the easiest
>> way might be export the file system from local system, and then running a
>> simulated OS, 'mount' the file system.
>>
> --
> *Paul Riley*
>
> Mo: +86 186 8227 8332
> Email: paul@rileyriot.com
>
>

[-- Attachment #2: Type: text/html, Size: 6190 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

On Mon, Jun 1, 2020 at 6:45 PM Paul Riley <paul@rileyriot.com> wrote:

> Is the disk image independent from the disk hardware? I’d assume that
> different disks may have different block sizes etc, so the disk type may be
> important.
>
A reasonable thought, but no, other than efficiency.  It's just an array of
bytes exposed to the OS.

The good news is that all the DEC systems used 512 byte fixed blocks
(Nothing like the funky Prime, Apollo or Alto tricks of putting some of the
file system metadata into the physical disk format -- if you ever wondered
why some of the original SCSI controllers supported a 1072 byte block size
- it was for Domain/Aegis - 1024 block + 48 byte meta data].



>
> The target system is LSX, a cut-down version of V6 designed to run on the
> LSI-11.
>
Everything should be able to be simulated using is 512-byte blocks.




> There are very few system utilities in the standard build (no mount for
> example). The second floppy is permanently mounted at boot time. I’m
> interested in making source file floppies on my modern system to use on the
> LSX, so I want to be able to create an image file from a source folder tree.
>

You'll have to check the docs, but I thought Heinz supported the RK05
[RKV11 controller].  That will give you 2.5M of 'raw' disk blocks, instead
of floppy.  Open it raw, and use it like mag tape.   If you don't have a
coming format, you can create something and then use dd(1) on the LSI-11
from the RKV11 -- a little clumsy but as a bootstrap, it should work fine.
The RL11 and RK711 controllers (RL01/02, RK07 disk) came later to the
PDP-11 (post 11/34 and 11/60). I think there was an RLV1[12] at some point,
but I don't think DEC even made an RKV71[12] -- however, I'm not up on
late-generation PDP-11 lore and they would have been much later than LSX so
driver support is doubtful.

Good luck,
Clem

[-- Attachment #2: Type: text/html, Size: 3577 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Ronald Natalie]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]



> On Jun 2, 2020, at 9:52 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> The good news is that all the DEC systems used 512 byte fixed blocks much later than LSX so driver support is doubtful. 
> 

Except on the RX’s.   The RX01 was 128 byte sectors and the later ones 256 and a odd interleaving strategy.    However, the boot block and the rest of the file systems (both UNIX and RT at least)
just aggregated the smaller (logical) sectors together to make a 512 byte one.

[-- Attachment #2: Type: text/html, Size: 1376 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Tue, Jun 2, 2020, 9:45 AM Ronald Natalie <ron@ronnatalie.com> wrote:

>
>
> On Jun 2, 2020, at 9:52 AM, Clem Cole <clemc@ccc.com> wrote:
>
>
> The good news is that all the DEC systems used 512 byte fixed blocks much
> later than LSX so driver support is doubtful.
>
>
> Except on the RX’s.   The RX01 was 128 byte sectors and the later ones 256
> and a odd interleaving strategy.    However, the boot block and the rest of
> the file systems (both UNIX and RT at least)
> just aggregated the smaller (logical) sectors together to make a 512 byte
> one.
>

RX50 also had weird interleaving... but it was quite the odd duck.

Warner

>
>

[-- Attachment #2: Type: text/html, Size: 1927 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Tue, Jun 2, 2020 at 11:44 AM Ronald Natalie <ron@ronnatalie.com> wrote:

> Except on the RX’s.   The RX01 was 128 byte sectors and the later ones 256
> and a odd interleaving strategy.    However, the boot block and the rest of
> the file systems (both UNIX and RT at least) just aggregated the smaller
> (logical) sectors together to make a 512 byte one.
>
Indeed, I was less than precise -- the key is that the SW treats them
everything as being in 512 byte 'hunks' no matter the underlying physical
formatting/interleaving actually is.

The point is that if you Paul is trying to move data from the two systems,
just treat the device as a serial byte stream of 512 byte blocks on both
sides and you you be fine.   That means if using dd, add conv=sync to fill
any write buffer to a complete multiple of 512.

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Winalski]

On 6/2/20, Ronald Natalie <ron@ronnatalie.com> wrote:
>
> Except on the RX’s.   The RX01 was 128 byte sectors and the later ones 256
> and a odd interleaving strategy.    However, the boot block and the rest of
> the file systems (both UNIX and RT at least)
> just aggregated the smaller (logical) sectors together to make a 512 byte
> one.

At least they all supported fixed-length sectors.  Was there ever a
Unix implementation that supported IBM-style CKD disk devices?

-Paul W.

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Adam Thornton]

> On Jun 2, 2020, at 11:59 AM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 6/2/20, Ronald Natalie <ron@ronnatalie.com> wrote:
>> 
>> Except on the RX’s.   The RX01 was 128 byte sectors and the later ones 256
>> and a odd interleaving strategy.    However, the boot block and the rest of
>> the file systems (both UNIX and RT at least)
>> just aggregated the smaller (logical) sectors together to make a 512 byte
>> one.
> 
> At least they all supported fixed-length sectors.  Was there ever a
> Unix implementation that supported IBM-style CKD disk devices?


If you count Linux, sure, Linux for the S/390 and zSeries.

If you don’t…well, for one brief shining moment before IBM squeezed too hard on the price and Oracle bought Sun instead, there was an OpenSolaris port to the zSeries, and it did support 3390 type devices.

I may have had something to do with that latter device driver.

Adam

[TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Ruizendaal]

> Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley*

It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and dskutil
https://github.com/sergev/bkunix/tree/master/fsutil
https://github.com/sergev/bkunix/tree/master/diskutil

The first generates a Unix 6th edition file system from a local directory tree. The result is a binary file with the 512 byte disk blocks stored in sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH.

The second appears to be a tool to take the a file generated by the fsutil tool and split that into sectors and tracks. I’m not familiar with this tool, but it looks like you might need something similar (I assume that you have some way to hook up a 8” drive to your PC?). Sector interleaving may be an issue to look out for.

When preparing a LSX system disk, you will need to think carefully about the layout:

Presumably the disk works with 128 byte sectors and 4 sectors are grouped together to create a 512 byte unix block. Check out the disk driver code for details:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c

Block 0 contains bootstrap code which is loaded/called from the monitor rom (or from a short code sequence keyed in on a “blinkenpanel” console).

The filesystem itself starts at block 1 and runs up to a block N (you need to tell fsutil how big the filesystem needs to be).

After block N up to the end of the disk is space to contain 2 swapped out programs plus 1 block for the return code of the third (default LSX has a maximum of 3 processes). You have to figure out how many 512 blocks are on your floppy and subtract out the swap space to arrive at a figure for N.

In the LSX source code ’N’ is known as the define SWPLO, see param.h for details:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h

In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h

Be careful with size units in the source code. Often sizes are expressed in words (2 bytes). Where memory is concerned it is often expressed in ‘clicks’, 64 bytes.

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]

Paul,

Many thanks for your detailed reply, it’s much appreciated.

I’ll start with the Bkunix utility and see if SimH can use the output, then
move on to your other suggestions if not.

Paul

On Mon, 1 Jun 2020 at 11:04 pm, Paul Ruizendaal <pnr@planet.nl> wrote:

> > Team Unix, Is there a Windows or Linux utility to create a disk image in
> any of the above formats, from a local folder tree? Paul *Paul Riley*
>
> It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and
> dskutil
> https://github.com/sergev/bkunix/tree/master/fsutil
> https://github.com/sergev/bkunix/tree/master/diskutil
>
> The first generates a Unix 6th edition file system from a local directory
> tree. The result is a binary file with the 512 byte disk blocks stored in
> sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH.
>
> The second appears to be a tool to take the a file generated by the fsutil
> tool and split that into sectors and tracks. I’m not familiar with this
> tool, but it looks like you might need something similar (I assume that you
> have some way to hook up a 8” drive to your PC?). Sector interleaving may
> be an issue to look out for.
>
> When preparing a LSX system disk, you will need to think carefully about
> the layout:
>
> Presumably the disk works with 128 byte sectors and 4 sectors are grouped
> together to create a 512 byte unix block. Check out the disk driver code
> for details:
> https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c
>
> Block 0 contains bootstrap code which is loaded/called from the monitor
> rom (or from a short code sequence keyed in on a “blinkenpanel” console).
>
> The filesystem itself starts at block 1 and runs up to a block N (you need
> to tell fsutil how big the filesystem needs to be).
>
> After block N up to the end of the disk is space to contain 2 swapped out
> programs plus 1 block for the return code of the third (default LSX has a
> maximum of 3 processes). You have to figure out how many 512 blocks are on
> your floppy and subtract out the swap space to arrive at a figure for N.
>
> In the LSX source code ’N’ is known as the define SWPLO, see param.h for
> details:
> https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h
>
> In this file, 99 blocks are reserved for swap, corresponding to processes
> with 24KB memory; total disk size is defined as 500 blocks, 250KB - note
> that this slightly exceeds the 241KB offered by the standard IBM 77 track
> 26 sector formatting for 8” disks. Probably you will need to tweak the
> values in param.h
>
> Be careful with size units in the source code. Often sizes are expressed
> in words (2 bytes). Where memory is concerned it is often expressed in
> ‘clicks’, 64 bytes.
>
>
>
>
> --
*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com

[-- Attachment #2: Type: text/html, Size: 4167 bytes --]

[TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Paul Ruizendaal]

> 
> In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h

Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Noel Chiappa]

    > From: Ronald Natalie

    > The V6 file system was limited to 2^24 blocks

No, 2^16; from filsys.h:

        int     s_fsize;        /* size in blocks of entire volume */

and of course on an -11 an int is 16 bits.

Maybe you're thinking of the file size, which was 2^24 bytes (max).

      Noel

Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator

[Ronald Natalie]

You are right.   16 bit block numbers 24 bit file size for V6.


> On Jun 1, 2020, at 8:14 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>> From: Ronald Natalie
> 
>> The V6 file system was limited to 2^24 blocks
> 
> No, 2^16; from filsys.h:
> 
>        int     s_fsize;        /* size in blocks of entire volume */
> 
> and of course on an -11 an int is 16 bits.
> 
> Maybe you're thinking of the file size, which was 2^24 bytes (max).
> 
>      Noel