Files released today!

[Michael Katzmann]

No, not those files ... Unix V4 https://archive.org/details/utah_unix_v4_raw

Does anyone know how we convert .tap format to .tar ?

I think there must be a way to mount the .tap as a tape on a later Unix version (in SIMH).

--

   |\      _,,,---,,_             Michael Katzmann
   /,`.-'`'    -.  ;-;;,_         NV3Z / VK2BEA / G4NYV
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)

[Anton Lavrentiev]

> Does anyone know how we convert .tap format to .tar ?

You are mixing up two very different things, actually. .TAP is a hardware container representation of a tape.  .TAR is a logical archive file.

A .tap file can contain any files, archives, etc, as it only cares about _tape blocks_.  A tar file is a collection of blocks, organized in a special way,

and that can be placed on a tape, i.e. contained in a .tap file.

If you attach a .tap file that contains a .tar archive to a tape device, then you can use the "tar" utility on the UNIX tape device to extract data from the archive.

Conversely, if you have a .tar file, simh can make it a .tap file on the fly with the -F TAR option in the attach command (which you can then read the same way in Unix under SimH).

Hope this helps.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAMyt5ORJ-8Obbr7aFwXNDeiUKNBfY%2BvxR-JUVzCmiBjsu909TQ%40mail.gmail.com.

[Anton Lavrentiev]

So, the .ZIP file that I downloaded contains one tap file in there, analog.tap.  There is no TAR archive on that tape.  The entire tape is made of 512-byte blocks (while with TAR one would expect 10240-byte blocks), and none look like TAR headers.  I presume it is some sort of a disk dump (thus, the 512-byte blocks).

There are other "big" files format of which I do not recognize, though.  I suspect they are just raw data taken from the tape, then converted to the .tap file.  But I might be wrong.

[Warner Losh]

On Fri, Dec 19, 2025, 5:49 PM Anton Lavrentiev <anton.la...@gmail.com> wrote:

So, the .ZIP file that I downloaded contains one tap file in there, analog.tap.  There is no TAR archive on that tape.  The entire tape is made of 512-byte blocks (while with TAR one would expect 10240-byte blocks), and none look like TAR headers.  I presume it is some sort of a disk dump (thus, the 512-byte blocks).

There are other "big" files format of which I do not recognize, though.  I suspect they are just raw data taken from the tape, then converted to the .tap file.  But I might be wrong.

If it is a V4 tape, there will be a bootstrap file to load into memory that reads other programs necessary to setup the disk with a filesystem that's likely in restor format, iirc. Tar is a v7 thing.

Do we have the install instructions yet?

Warner

On Fri, Dec 19, 2025 at 7:40 PM Anton Lavrentiev <anton.la...@gmail.com> wrote:

> Does anyone know how we convert .tap format to .tar ?

You are mixing up two very different things, actually. .TAP is a hardware container representation of a tape.  .TAR is a logical archive file.

A .tap file can contain any files, archives, etc, as it only cares about _tape blocks_.  A tar file is a collection of blocks, organized in a special way,

and that can be placed on a tape, i.e. contained in a .tap file.

If you attach a .tap file that contains a .tar archive to a tape device, then you can use the "tar" utility on the UNIX tape device to extract data from the archive.

Conversely, if you have a .tar file, simh can make it a .tap file on the fly with the -F TAR option in the attach command (which you can then read the same way in Unix under SimH).

Hope this helps.

On Fri, Dec 19, 2025 at 7:20 PM Michael Katzmann <vk2...@gmail.com> wrote:

No, not those files ... Unix V4 https://archive.org/details/utah_unix_v4_raw

Does anyone know how we convert .tap format to .tar ?

I think there must be a way to mount the .tap as a tape on a later Unix version (in SIMH).

--

   |\      _,,,---,,_             Michael Katzmann
   /,`.-'`'    -.  ;-;;,_         NV3Z / VK2BEA / G4NYV
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAMyt5ORJ-8Obbr7aFwXNDeiUKNBfY%2BvxR-JUVzCmiBjsu909TQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr1Rb%2BkfCB7pxo%2B3o5P1icEo4tD6N_7NMFgjbXpa2d3%2BFQ%40mail.gmail.com.

[Anton L.]

BTW, the .tap file contains two tape blocks reported with errors:

0x0021F5C4 WARNING: TAPE RECORD 0./4280./4280. SIZE 511. (0x000001FF) W/ERROR
0x0022A474 WARNING: TAPE RECORD 0./4366./4366. SIZE 512. (0x00000200) W/ERROR

(and I saw logs in the .zip file suggesting two read errors, too.)  So, depending on where these blocks land on the disk, the usability of the entire dump may be rather questionable (e.g. if any critical executable code is affected by them).  Certainly, a 511-byte sector is no good under any circumstances.  OTOH it also may happen that these two blocks are not involved in anything critical (yet if they are the executable code, I'd expect that to crash, anyways).

[Anton L.]

>  there will be a bootstrap file to load into memory that reads other programs necessary to setup the disk with a filesystem that's likely in restor format

There's only one "file" on tape (there are only two tape marks all the way at the end of the tape).  I assume it's a raw block-by-block dump of an entire disk drive (from looking at what's inside).  So basically, you will need to copy the tape block by block to a disk and then you can boot the disk.  My $.02 ;-)

[Warner Losh]

On Fri, Dec 19, 2025, 6:05 PM Anton L. <anton.la...@gmail.com> wrote:

>  there will be a bootstrap file to load into memory that reads other programs necessary to setup the disk with a filesystem that's likely in restor format

There's only one "file" on tape (there are only two tape marks all the way at the end of the tape).  I assume it's a raw block-by-block dump of an entire disk drive (from looking at what's inside).  So basically, you will need to copy the tape block by block to a disk and then you can boot the disk.  My $.02 ;-)

I'll have to look at it closely then after dinner. That's not typical for the boot tapes...

Warner

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/44ce010f-ed71-4dd3-a92f-11f4bba08adan%40googlegroups.com.

[Anton L.]

It does actually look like a bootable TM11 tape (looking at the bootloader in the first tape block).  But the rest of it looks like a disk dump, from what I can see.  Maybe I'm wrong, though.

The entire tape size is 2532864 bytes (which is 4947 blocks, which is larger than RK05, 203x2x12 = 4872 blocks).

You can boot it using "boot -o tm" in SimH ("-o" for "old boot" because the bootloader is expected in the second tape block, by newer standards, and that's the default). It prompts you with the "equal sign" (=) on the console.  I tried a few inputs, but = comes back again.  I have no idea what to do with that (e.g. what response is expected).

HTH

[a...@papnet.eu]

i extracted the filesystem: http://squoze.net/UNIX/v4/

aap

[Johnny Billquist]

There are certainly ways of doing this, but you need to first understand
that a tar file is not some sort of tape image format. So you cannot
just directly convert from one to the other.

But if you have a .tap file, it's a tape image. So it contains
something. You can attach that to simh, run some unix (or whatever),
extract whatever is on that tape back to files (you need to find out
exactly what is on the tape, and in which format), and then you can of
course create a tar-ball from that extracted data.

You can "mount" a .tap file under simh using any OS you can imagine, as
the OS inside simh isn't really in control of anything here. It's all
simh. It then presents a tape drive to the OS inside, which that OS
needs to be able to operate.

Johnny

On 2025-12-20 01:20, Michael Katzmann wrote:
> No, not those files ... Unix V4 https://archive.org/details/

> utah_unix_v4_raw <https://archive.org/details/utah_unix_v4_raw>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/
> CAMyt5ORJ-8Obbr7aFwXNDeiUKNBfY%2BvxR-JUVzCmiBjsu909TQ%40mail.gmail.com

> <https://groups.google.com/d/msgid/pidp-11/
> CAMyt5ORJ-8Obbr7aFwXNDeiUKNBfY%2BvxR-JUVzCmiBjsu909TQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Anton L.]

So the TM bootloader understands the following commands (the "list" command prints them all):

=list
dldr
dtf
list
mboot
mcopy
rkf
tboot
uboot

I have to stop here because my early Unix knowledge is nonexistent LOL

I tried to use mcopy.  mboot does not seem to do anything (but pops back the prompt).  uboot just hangs.

HTH

[Anton L.]

So apparently, I was wrong about the tape structure.  The first block is the boot loader for the TM.  It is followed by the "files" for the programs that the boot loader accepts at the = sign.  The table of those "files" is located in the second tape block (sort of directory).  The following blocks contain the executable code for all these commands.

That finally is followed by the dump of the file system (which I suppose you can copy with the "mcopy" command).  It asks for "tape offset", "disk offset" and "count".

And it does write something to an RK disk 0.  The "only" problem is what are the values and units for the offsets and count ;-)

Happy hacking, everybody!

[Anton L.]

Oh, and I forgot to mention that all those "parts" are contained in a single tape "file" (that is, like I said before, there are no intermediate tape marks). All tape blocks are same 512-byte size (except for one bad block, which I suppose should still be treated as a 512-byte block).

[Anton Lavrentiev]

Super!  Very cool ;-)

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/4894ea40-a11c-46e7-b452-69b9530d016fn%40googlegroups.com.

[a...@papnet.eu]

It's booting!

=uboot
k
unix

login: root
# ls
bin
dev
etc
lib
mnt
tmp
unix
usr
#

 updated the readme with instructions. i'll keep working on the stuff at that link

[Anton Lavrentiev]

>   i'll keep working on the stuff at that link

Awesome!  Just a little nit: Your boot.ini does not mention that both "k" and "unix" get entered in response to the "uboot" command.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/6656be20-3c71-406a-b4ec-f406222b4569n%40googlegroups.com.

[John D. Bruner]

The first part of the tape is in tp format. I attached it to 2.11BSD to look at it:

$ tp mtv

   mode    uid gid tapa    size   date    time name

rwxrwxrwx   6   1   63      228 73/10/24  8:19 dldr

rwxrwxrwx   6   1   64     2406 73/10/24  8:22 dtf

rwxrwxrwx   3   1   69       74 73/10/25  8:12 list

rwxrwxrwx   3   1   70      492 73/10/25  8: 9 mboot

rwxrwxrwx   6   1   71      432 73/11/11 12:12 mcopy

rwxrwxrwx   6   1   72       80 73/11/11 12: 4 rkf

rwxrwxrwx   3   1   73      450 73/10/25  8:10 tboot

rwxrwxrwx   6   1   74      512 73/10/25 14:55 uboot

   8 entries

  12 used

  74 last

End

The tp content is followed by a disk image. I assume that the installation process is to format the drive with the "rkf" program and then copy the content from tape to disk with "mcopy".

I stripped off the first 75 blocks and wrote the rest to an image file. I was able to mount it on v6 and poke around in it. So far I haven't been able to get it to boot. The boot block runs and echoes keyboard input (forcing it to lower-case), but it doesn't load "unix".

--John

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr2LCU%3Du6HSvMtxRRV5rtBPRA%3DYB%3D78N-bT1P8%2Be%3DFJjNA%40mail.gmail.com.

[John D. Bruner]

Got it - the bootstrap looks for a 'k' or a 'p' to determine the type of drive it's booting from. I attached the image as an RK05, so I was able to boot it with

k

unix

It prints out "mem = XXXX" followed by a login prompt. There is no password for root.

--John

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/rpIgNIbJgbY-JqJN4zw2BjSa_tYAqocZhQ3g4afcqjP17e8l1tZMMmbZ5QxFQIWNZDSqYLNEHJUmtxc0-U-nhPCgOZGs2KWzcF4NJNdSR3c%3D%40brunerhome.net.

[Michael Katzmann]

There is something amiss somewhere (maybe the simh setup)...

😼 simh-pdp11 boot.ini

PDP-11 simulator V3.12-5
Disabling XQ
k
unix
mem = 64530

login: root
# ls -l
total 63
drwxr-xr-x 2 bin       944 Jun 12 17:54 bin
drwxr-xr-x 2 bin        64 Jun 10 09:37 dev
drwxr-xr-x 2 bin       256 Jun 12 19:50 etc
drwxr-xr-x 2 bin       256 Jun 12 18:04 lib
drwxr-xr-x 2 bin        32 Jun 10 09:37 mnt
drwxrwxrwx 2 bin        48 Jun 12 19:50 tmp
-rw-r--r-- 1 bin     27624 Jun 12 19:50 unix
drwxr-xr-x15 bin       240 Jun 12 17:52 usr
# cd /
cd: not found
# ps
No mem
#

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/gGYoV4VCOOldDa3U2O0DgPlcc0yzSrAYAWZf3xvW2bYCVyCNeRpdVQWbGwTulzfNiDD-asFpNJyfSq20vY1jH92a9NULKTghqsGxEbSQZmQ%3D%40brunerhome.net.

[Michael Katzmann]

never mind its chdir in V4 ... !!

[Anton L.]

But what about "ps"?

The tape had 2 bad blocks.  I wonder if ppl could figure out where these two belong at (if any files affected).  Hopefully, they were unused, but one needs to make sure!

[John D. Bruner]

"No mem" means ps can't open /dev/mem

The reason for the error is that there is no /dev/mem. It doesn't look like the kernel includes the mem driver (see /usr/sys/conf/conf.c). That driver also provides /dev/kmem and /dev/null. Thus, if you try something like "cat /etc/rc > /dev/null" you'll wind up with an ordinary file in the /dev directory. That seems like an odd configuration for a distribution...

--John

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/7accece9-4c6b-4371-bff7-ee0cbe75622cn%40googlegroups.com.

[Michael Katzmann]

It looks like you need to run mkconf specifying the devices on the machine. This creates c.c. The script rc then compiles and creates a new unix.

I don't know if you need to mknod /dev/mem explicitly (like you need to do for the other devices)

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/GLz3w06TFO2-GQEeSpv7vYghUiw0Ra1D_wB8RzLL3nI5hTFefIITKhqkgnEWt9AKADCm5Zzirs99LLho0bGs6s0s3yP3-m38bZHL8L_7fYU%3D%40brunerhome.net.

[John D. Bruner]

It will go best if you login as bin (no password) rather than root. bin owns all of the files, and mv checks whether the destination is writeable and prompts for consent if it is. That doesn't work in a Thompson shell script, because it reads from stdin (fd 0), which is the script file.

You will need to mknod /dev/mem (ideally also /dev/kmem and /dev/null) using the major number for mm in cdevsw and minor number 0 (and 1 and 2, respectively). After you do this and reboot, ps should work.

--John

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAMyt5OSvaXRFyk2pzsy1%3DAmiWmbv96RoAEXjSFE5Mj4Fdz%3D%3D7A%40mail.gmail.com.

[Anton L.]

>  > i'll keep working on the stuff at that link

Question for aap:

Your mcopy instructions (in README) say to copy with count 4000. Why?

The tape contains 4947 512-byte blocks, of which the first 75 is the bootloader and "tp" stuff.

The remaining 4947-75=4872 would exactly cover the entire RK05 (=203 cyls x 2 sides x 12 sectors/track).

Can you please explain?  Thx.

[Bob Eager]

In Sixth Edition, 4000 was the limit of the file system. The remaining
blocks were the swap area.

[Anton L.]

That's good news!  Since it also answers my other question about what the bad tape blocks (4280 and 4366) could have affected.  Since they are well outside the [75 .. 4075) block range, they fell onto the swap area, and thus the entire file system was actually intact!  (Although I'm not sure why the entire drive was dumped to tape, rather than just the file system partition, but it was probably simpler to do it that way.)

Thanks

[Clem Cole]

Let me be a tad more precise here.  The limit is set with mkfs(8) when the file system is built on the disk. File system can be larger - although before V7, seek is limited to the size of a 16-bit integer - which was the limit for the size of an FS. 

That said, my convention, RK05’s often were set to 4000 blocks and the rest used for swapping. But that is not a requirement. But his many blocks used for that specific FS instance is purely how that FS was built for that specific disk pack using mkfs(8). 

In fact some times we would use a dedicated swap disk like an RS11/RF11 and then we would let the RK05 use the entire disk. 

Also? Please remember that the idea of partitioning a disk does not come into play until the number blocks overflowed the size of a 16 bit integer (the later RP series drives).   That’s when the idea of swap partition came into being.

 It also helped as a problem with swap being at the end of disk tended to force the disk arm to move a lot. Keeping it closer to the front of the disk often helped some performance issues. 

Btw: I believe the binary version of tp on this system is based on Ken’s original assembler version. The version in 2.11 is based the Harvard stp (super tp) and is written in C. The sources are in the TUHS archives in the USENIX 1977 distribution. One of the difference is that stp writes a second copy of the directory at the end of the tape. Ken’s original tp format put the directory in the first blocks of the tape since that was how DECtape worked. He just used the same format for the 9-track. 

When he created tar for V6++ (and left the labs in V7), the directory is threaded throughout the tape instead of being at a fixed location. 

Sent from a handheld expect more typos than usual

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/7c354263-c5b9-46a8-9ca5-3ffdbee53326n%40googlegroups.com.

[Michael Katzmann]

I updated the Unix V4 configuration to include a dc11 device (major #4) and created the devices in /dev but I cannot tell what /etc/ttys should be.

Unsurprisingly it differs in format to V7. Does anyone have a clue how the format relates to the major/minor device numbers?

(I want to attach the Teletype 33 to the PiDP11 running Unix 4)

At the moment it is ...

# cat /etc/ttys
000
010
020
030
040
050
060
070
180
090
0a0
0b0
0c0
0d0
# 

# ls -l /dev
total 0
crw-rw-rw- 1 root    3,  1 Jun 12 21:01 kmem
crw-rw-rw- 1 root    3,  0 Jun 12 21:01 mem
crw-rw-rw- 1 root    3,  2 Jun 12 21:01 null
crw-rw-rw- 1 root    4,  0 Jun 12 21:16 tty0
crw-rw-rw- 1 root    4,  1 Jun 12 21:16 tty1
crw-rw-rw- 1 root    4,  2 Jun 12 21:17 tty2
crw-rw-rw- 1 root    4,  3 Jun 12 21:17 tty3
crw--w--w- 1 root    0,  0 Jun 12 21:19 tty8

[Michael Katzmann]

To answer my own question 8-) ... 

Looking at the source code, it seems the first number is 0 or 1 to disable or enable the tty.

The second digit is the tty number 0 for /dev/tty0.

I don't exactly know what the third digit is but it indexes a character array that is executed (so a program .. probably getty for index 0)

[Bob Eager]

Indeed. I was referring specifically to the installation tape, of course.

We used to use the entire RK05 except on the boot disk. We didn't have a tape drive, so we had no way of doing a dump if needed (the dump code was built into m40.s on Sixth Edition). I wrote some code (which survives in a few places) that dumped to the swap area instead. One could then bring up the system in single user mode, and use dd or similar to preserve the dump in a file.

The block numbers on the tape were documented (at least by Sixth Edition) in the installation instructions. There were different boot blocks depending on the disk.

I do have the instructions for Mini-UNIX (see my Mini-UNIX page at https://unixhistory.tavi.co.uk/mini-unix.html), which use the same blocks. In fact, there were multiple disk images on the tape. See this file for more details: https://unixhistory.tavi.co.uk/mini-unix/munix-documents.zip.

As for the disk partitioning...oh yes. On the 20MB RP02s, there were about 40,000 blocks. That fitted in 16 bits, but there was software that had used signed integers where it shouldn't. The 40MB RP03s broke that completely, and partitions were born!

Somewhere I must have a copy of 'tp' that I wrote from scratch in DOS-11 assembler, to allow file interchange.

Incidentally, RT-11 put the directory about a third of the way up the tape, on the assumption that this would be at about the middle of the data on a typical tape.

[Johnny Billquist]

On 2025-12-21 13:13, Bob Eager wrote:
> Incidentally, RT-11 put the directory about a third of the way up the
> tape, on the assumption that this would be at about the middle of the
> data on a typical tape.

Are we talking about DECtape here?
Anyway, I think that is incorrect. RT-11 have a very simplistic file
system, and it also suffers badly by any fragmentation of the disk (or
DECtape). So directories always start at a known block number very early
on the device.

However, RSX do this trick on almost all devices. The files required for
manipulating the file systems are usually stored in the middle of the
device, which (hopefully) makes seek distance never more than 1/4 of the
media surface to get there. Exceptions are floppies, where it usually
stores the information at the beginning, since they are small enough
that you want to optimize for largest possible contiguous file. Not sure
where it places the files on a DECtape, but it might be at the start as
well.

If we're talking about magtapes in general, then you never store things
like directory information in a fixed place, or separate from content.
You usually have each file starting with the meta-information, and then
the data. Doing a directory always means scanning over the whole device,
looking for each tape mark.

Johnny