[-- 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 --]
[-- 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 --]
[-- 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 --]
> 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.
>
> 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.
[-- 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 --]
[-- 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 --]
[-- 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 --]
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.
> 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
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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.
> 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