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.

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 &lt;paul(a)rileyriot.com&gt; 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.

On Tue, Jun 2, 2020 at 11:44 AM Ronald Natalie &lt;ron(a)ronnatalie.com&gt; wrote: 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.

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