From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14237 invoked from network); 2 Jun 2020 13:32:38 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 13:32:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id CF3839CA83; Tue, 2 Jun 2020 23:32:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 13C629C5EC; Tue, 2 Jun 2020 23:31:59 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="sIgmm5Gq"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 7118C9C5EC; Tue, 2 Jun 2020 23:31:56 +1000 (AEST) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by minnie.tuhs.org (Postfix) with ESMTPS id 62A8993D46 for ; Tue, 2 Jun 2020 23:31:55 +1000 (AEST) Received: by mail-qk1-f178.google.com with SMTP id 205so12474555qkg.3 for ; Tue, 02 Jun 2020 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6iPpU6R46EjUqbb/hnjNI+uUKxnOFeJL4h3ZUGw0Tx8=; b=sIgmm5GqT6brCtC2zz+suFARc5KvQ11BDSeV9prBlCRty1hs+pIL8umLOL2L26ggQ+ kYTr0/NLmxXFifY5xD7nB/qWcR8cbtXDtryu1DbdHyzT8GWzArf9H4WHlHNnYLhW2jKw QzUuc08BOZlqk7zmT9XhnvpRfcdSTwMNLYON8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6iPpU6R46EjUqbb/hnjNI+uUKxnOFeJL4h3ZUGw0Tx8=; b=mOM5OWiL5z3X/taV4yqjRD1VqbjSuVlGcKfM44U+czMKQnpnyjxo+ZlnA9C6XYKNAn VqpuXRhSjQZ5QlgeHpCuu2dAfPxM8M9KoH5sr+hAupFuzs9Mlpkr2eH4/kwdFvMSG+cK IYAUqWU24SCuWIbzbejiC3D44vFepdnOYEkeMPDFxGhzM+DmQb8h8shBJ03Z6dkUUc1y trStB0NDKjyRx56wSoqbcQHdr5ln3h+fB9NPixmOUI+JTPZsMjYw2eKPONOfUY5JJo3Y FYADYOmQxNoy21YU95aMHqsxbFOKyzh6y8rzmvXzcSQrmz4KRhAdZ0UgPQ97PIb4ATHc wOYw== X-Gm-Message-State: AOAM530d1xvr+0GKGXAAtEld7gcTDPhtBKBYK4s2XDYDz4mbB2eMQveb +4OunYN3JG3ZIKkNV/KbbVqQq/NwZ0R+fWVT7z+E0A== X-Google-Smtp-Source: ABdhPJyXUn8NFJydd3BzCMnj8bJWHJ4NzMRXa3WyxWnS9jiL8kreAeGFXq/IxX1fG0mUN9BlKuwBZh8hXp4d+LB4K4I= X-Received: by 2002:a37:65cf:: with SMTP id z198mr9393912qkb.133.1591104713999; Tue, 02 Jun 2020 06:31:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Tue, 2 Jun 2020 09:31:28 -0400 Message-ID: To: Paul Riley Content-Type: multipart/alternative; boundary="00000000000047657c05a719ef2e" Subject: Re: [TUHS] DEC RL01/RL02 RX01/RX02 Disk Image Creator X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000047657c05a719ef2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Clem, > > Thanks for your help. You=E2=80=99ve correctly interpreted my question. > > Is the disk image independent from the disk hardware? I=E2=80=99d 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 mou= nt > for example). The second floppy is permanently mounted at boot time. I=E2= =80=99m > interested in making source file floppies on my modern system to use on t= he > LSX, so I want to be able to create an image file from a source folder tr= ee. > > Paul > > On Mon, 1 Jun 2020 at 9:05 pm, Clem Cole wrote: > >> >> >> On Mon, Jun 1, 2020 at 6:19 AM Paul Riley wrote: >> >>> Is there a Windows or Linux utility to create a disk image in any of th= e >>> above formats, from a local folder tree? >>> >> What I think you are asking, is there a utility for a modern OS that wil= l >> walk a local folder tree on my OS and create a new file whose structure = is >> that of the file system for OS . >> >> The issue is not the device as much as the OS and disk file layout. A= s >> 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 ar= e >> 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 > > --00000000000047657c05a719ef2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Frankly, using a common tape format, and then a raw dis= k as the 'tape' tends to be easy.=C2=A0 For instance,=C2=A0 if it&#= 39;s an older system like v6, there is a binary for v6tar kicking around th= at 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).=C2= =A0 =C2=A0Put that binary on your v6 system.=C2=A0 =C2=A0Then create a tar = image on your modern system.=C2=A0 =C2=A0Tar uses a threaded ASCII header a= nd actually had a bug in it, that is exploited as an extension mechanism an= d became a feature (I'll explain off line=C2=A0if need=C2=A0be).=C2=A0 = So modern tar's will produce a checksum that the original's will co= rrectly accept.=C2=A0 Note the modern tar can create >>file types<= < that the old tar will not understand, but it will just=C2=A0skip them.=

Going the back works too, but is limited by the origi= nal's handling of things like directories.=C2=A0 It is generally not a = problem.

So, the result is that you can attach that &#= 39;tarball' as a raw disk on simh and then read it with v6tar.=C2=A0=C2= =A0

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 ass= embler).=C2=A0 But ...=C2=A0 since that was written with the a pre-Typesett= er C compiler, and has a PDP-11 binary format knowledge in it and I think u= sed Lesk's portable I/O package, so it might be a little more difficult= to get running on a more modern=C2=A0C.

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

Thanks for your help. You=E2=80=99ve correctly interpreted my question.<= /div>

Is the disk image indepe= ndent from the disk hardware? I=E2=80=99d assume that different disks may h= ave different block sizes etc, so the disk type may be important.

The target system is LSX, a cut-d= own 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 i= s permanently mounted at boot time. I=E2=80=99m 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.
<= br>
Paul

On Mon, 1 Jun 2020 at 9:05 pm, Cl= em Cole <clemc@ccc.co= m> 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 tr= ee?=C2=A0
What I think you are asking,= is there a utility for a modern OS that will walk a local folder tree on m= y OS and create a new file whose structure is that of the file system for O= S <insert yours here>.

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

There= are numerious=C2=A0utilities, as well as 'foreign file systems' th= at are available.=C2=A0 =C2=A0For instance, many Unix's can write RT-11= and MS-DOS format with standard utilities.=C2=A0=C2=A0=C2=A0It really depends = the OS.=C2=A0 That s= aid,
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.<= /div>
--
Paul Riley

M= o: +86 186 8227 8332

<= /div>
--00000000000047657c05a719ef2e--