31 Jul
2026
31 Jul
'26
10:18 a.m.
https://www.vintagecomputer.net/browse_thread.cfm?id=833
New TU56 Tape Images Available for simH use. I will post updates on this
thread, but if anyone is interested in messing around with the images
using simH, feel free to download and explore/use.
Bill
31 Jul
31 Jul
5:21 p.m.
Bill Degnan via cctalk <cctalk(a)classiccmp.org> writes:
New TU56 Tape Images Available for simH use. I will
post updates on this
thread, but if anyone is interested in messing around with the images
using simH, feel free to download and explore/use.
Just out of curiosity, what is the internal format of these images?
Most especially, what is the internal format of the "18 bit" file?
They look to be something more clever than little endian 32 bit
integers, where "clever" is not necessarily complimentary.
--
Rich Alderson news(a)alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
11 p.m.
On Fri, Jul 31, 2026 at 9:38 PM Rich Alderson via cctalk <
cctalk(a)classiccmp.org> wrote:
Bill Degnan via cctalk <cctalk(a)classiccmp.org>
writes:
I dont' know. I watched as Dave Gesswein ran them through his TU56. I was
able to load the pdp8 and pdp11 tape
images using simH, I have not
yet tried the pdp10 tape image. The TU56 is a universal drive and as I
underatand it (barely), and if I understand correctly the tracks of 00's
are ignored and/or are used to indicate what kind of system made them, 12,
16, or 18 bit. I am still learning about TU56 tape storage. Sorry I can't
provide a substantial answer to question
Bill
New TU56 Tape Images Available for simH use. I
will post updates on
this
thread, but if anyone is interested in messing
around with the images
using simH, feel free to download and explore/use.
Just out of curiosity, what is the internal format of these images?
Most especially, what is the internal format of the "18 bit" file?
<snip>
1 Aug
1 Aug
11:49 a.m.
On Aug 1, 2026, at 3:00 AM, Bill Degnan via cctalk
<cctalk(a)classiccmp.org> wrote:
I dont' know. I watched as Dave Gesswein ran them through his TU56.
Did he use read-all mode to read the raw tape structure? Or is this something lower level
still, without using a TC11 controller?
I was
able to load the pdp8 and pdp11 tape
images using simH, I have not
yet tried the pdp10 tape image. The TU56 is a universal drive and as I
underatand it (barely), and if I understand correctly the tracks of 00's
are ignored and/or are used to indicate what kind of system made them, 12,
16, or 18 bit.
True. I remember a DECtape manua, perhaps the TC11/TU56 technical manual, with an
appendix that shows the PDP-n DECtapes for all n, and the matrix of interoperabiltiy. So
if you have a PDP-4 and needed to read PDP-11 DECtapes, it would tell you whether
that's possible.
DECtapes basically have a clock track, a "mark" track, and 3 data tracks, all of
these replicated. And controllers like the TC11 have a "read-all" mode where
pretty much everything is extracted, I'm having some trouble finding out the precise
details of how that deals with the block delimiters, block numbers, etc.
The one thing a TC11 can't handle is LINCtape, because its low level encoding is
different. I think the drive can handle it if you capture the waveforms, it's
compatible at that level, but the controller even in read-all mode can't cope.
paul
12:19 p.m.
Dave Gesswein constructed electronics to read the tape data into his laptop
directly from a TU56. We backed up a pdp8, 11, and 10 tape all with the
same process. Dave used a program that I think Vince Briel created, but I
don't know who for sure, to view the tracks individually after import.
This program would show which tracks were all 00's and which were data.
The number of 00 tracks demonstrates whether the tape is 12, 16, 18 bit but
I don't recall exactly how this is done other than to count how many
columns were all 00's. We also viewed wave forms of the data as it was
being inputted.
I also have a TU56 but I have not used it yet. I did some research on the
drive and an interesting negibus/posibus conversion cable that was
apparently used to connect this TU56 to a PDP 9, more info here
https://www.vintagecomputer.net/browse_thread.cfm?id=788
I hopefully will get my TU56 up and running eventually. I donated the
adapter to the RICM a few years ago.
Bill
On Sat, Aug 1, 2026 at 3:49 PM Paul Koning <paulkoning(a)comcast.net> wrote:
On Aug 1, 2026, at 3:00 AM, Bill Degnan via
cctalk <
cctalk(a)classiccmp.org> wrote:
I dont' know. I watched as Dave Gesswein ran them through his TU56.
Did he use read-all mode to read the raw tape structure? Or is this
something lower level still, without using a TC11 controller?
I was
able to load the pdp8 and pdp11 tape
images using simH, I have not
yet tried the pdp10 tape image. The TU56 is a universal drive and as I
underatand it (barely), and if I understand correctly the tracks of 00's
are ignored and/or are used to indicate what kind of system made them,
12,
16, or 18 bit.
True. I remember a DECtape manua, perhaps the TC11/TU56 technical manual,
with an appendix that shows the PDP-n DECtapes for all n, and the matrix of
interoperabiltiy. So if you have a PDP-4 and needed to read PDP-11
DECtapes, it would tell you whether that's possible.
DECtapes basically have a clock track, a "mark" track, and 3 data tracks,
all of these replicated. And controllers like the TC11 have a "read-all"
mode where pretty much everything is extracted, I'm having some trouble
finding out the precise details of how that deals with the block
delimiters, block numbers, etc.
The one thing a TC11 can't handle is LINCtape, because its low level
encoding is different. I think the drive can handle it if you capture the
waveforms, it's compatible at that level, but the controller even in
read-all mode can't cope.
paul
12:32 p.m.
On Aug 1, 2026, at 4:19 PM, Bill Degnan
<billdegnan(a)gmail.com> wrote:
Dave Gesswein constructed electronics to read the tape data into his laptop directly from
a TU56. We backed up a pdp8, 11, and 10 tape all with the same process. Dave used a
program that I think Vince Briel created, but I don't know who for sure, to view the
tracks individually after import. This program would show which tracks were all 00's
and which were data. The number of 00 tracks demonstrates whether the tape is 12, 16, 18
bit but I don't recall exactly how this is done other than to count how many columns
were all 00's. We also viewed wave forms of the data as it was being inputted.
Nice. Is there a description of this somewhere?
Your comment about 00 tracks does not appear correct. In all DECtape formats, there are
10 physical tracks, which are two copies of 5 tracks: a timing track, a mark track, and 3
data tracks. This is true for all formats, not just PDP11 (which is the same as PDP-10)
but PDP-8 also. The PDP-8 format has 4 3-bit word per PDP-8 word; the PDP-10/11 format
has 6 3-bit words per 18 bit word, where in the PDP-11 case the top 2 are ignored on read
and writtten as 0.
The way you recognize a PDP-8 format tape is by its short blocs. The PDP-11 format has
256 18-bit words per block, 578 of those per tape. The PDP-8 format has 129 12-bit words
per block, and I think 1102 blocks per tape but I'm not sure about that. The mark
track gives the block envelope which is how you can tell them apart.
The reason you can read odd format tapes on a PDP-11 is that the mark track definition is
common across all of them. And this is why you can't read LINCtape that way, its mark
track codes are different and the block envelope is different as well. For example, you
can read DECtape in either direction, no matter what direction the block was written in.
But LINCtape can be written/read in either direction but a block can only be read in the
same direction it was written.
paul
12:58 p.m.
Dave Gesswin should have a bronze statue for all the things he does....
Interestingly enough this brings up a point: I recently dumped some RX02
floppies using virtual devices in RSX11M+ for a person and he had a
devil of a time getting them to read on SIMH. Finally figured out that
SIMH was expecting 2 interleave and RSX didn't do that on the virtual
images.
I wonder if the interleave would be preserved if I used pdpgui and
dumped them that way, but I have a bunch of RX02 disks with neat things
like TSX+, SATURN software, and stuff like that. Maybe it's time for
Simh to support logical devices with 1-1 interleaves through an attach
option.
Thoughts? I'll stick them on www.crystel.com/pdp of course, but at the
same time I have lots of other stuff to do.
CZ
On 8/1/26 16:19, Bill Degnan via cctalk wrote:
Dave Gesswein constructed electronics to read the tape
data into his laptop
directly from a TU56. We backed up a pdp8, 11, and 10 tape all with the
same process. Dave used a program that I think Vince Briel created, but I
don't know who for sure, to view the tracks individually after import.
This program would show which tracks were all 00's and which were data.
The number of 00 tracks demonstrates whether the tape is 12, 16, 18 bit but
I don't recall exactly how this is done other than to count how many
columns were all 00's. We also viewed wave forms of the data as it was
being inputted.
I also have a TU56 but I have not used it yet. I did some research on the
drive and an interesting negibus/posibus conversion cable that was
apparently used to connect this TU56 to a PDP 9, more info here
https://www.vintagecomputer.net/browse_thread.cfm?id=788
I hopefully will get my TU56 up and running eventually. I donated the
adapter to the RICM a few years ago.
Bill
On Sat, Aug 1, 2026 at 3:49 PM Paul Koning <paulkoning(a)comcast.net> wrote:
>
>> On Aug 1, 2026, at 3:00 AM, Bill Degnan via cctalk <
> cctalk(a)classiccmp.org> wrote:
>> I dont' know. I watched as Dave Gesswein ran them through his TU56.
> Did he use read-all mode to read the raw tape structure? Or is this
> something lower level still, without using a TC11 controller?
>
>> I was
>> able to load the pdp8 and pdp11 tape
>> images using simH, I have not
>> yet tried the pdp10 tape image. The TU56 is a universal drive and as I
>> underatand it (barely), and if I understand correctly the tracks of 00's
>> are ignored and/or are used to indicate what kind of system made them,
> 12,
>> 16, or 18 bit.
> True. I remember a DECtape manua, perhaps the TC11/TU56 technical manual,
> with an appendix that shows the PDP-n DECtapes for all n, and the matrix of
> interoperabiltiy. So if you have a PDP-4 and needed to read PDP-11
> DECtapes, it would tell you whether that's possible.
>
> DECtapes basically have a clock track, a "mark" track, and 3 data tracks,
> all of these replicated. And controllers like the TC11 have a "read-all"
> mode where pretty much everything is extracted, I'm having some trouble
> finding out the precise details of how that deals with the block
> delimiters, block numbers, etc.
>
> The one thing a TC11 can't handle is LINCtape, because its low level
> encoding is different. I think the drive can handle it if you capture the
> waveforms, it's compatible at that level, but the controller even in
> read-all mode can't cope.
>
> paul
>
>
3:17 p.m.
Bill Degnan <billdegnan(a)gmail.com> writes:
On Fri, Jul 31, 2026 at 9:38 PM Rich Alderson via
cctalk <cctalk(a)classiccmp.org> wrote:
Bill Degnan via cctalk <cctalk(a)classiccmp.org>
writes:
> New TU56 Tape Images Available for simH use. I
will post updates on
> this thread, but if anyone is interested in messing around with the
> images using simH, feel free to download and explore/use.
Just out of curiosity, what is the internal format of
these images?
Most especially, what is the internal format of the "18 bit" file?
<snip>
I dont' know. I watched as Dave Gesswein ran them
through his TU56.
I was able to load the pdp8 and pdp11 tape images using simH, I have
not yet tried the pdp10 tape image. The TU56 is a universal drive and
as I underatand it (barely), and if I understand correctly the tracks
of 00's are ignored and/or are used to indicate what kind of system
made them, 12, 16, or 18 bit. I am still learning about TU56 tape
storage. Sorry I can't provide a substantial answer to question
ALL DECtape drives are universal; any differences are in the controllers
rather than the drives.
I expected Dave Gesswein to use a PDP-8/e vel sim. with a TD8E
controller, since that is the most agnostic controller DEC built--all
the interesting stuff is done by the OS/8 driver rather than in
hardware.
In a later message in this thread, you said that DG had created an
interface for a PC of some variety to connect directly to the TU56. I
have had experience with someone else's lashup of the same kind, which
ran on a Windows 98 box at Paul Allen's computer facility (years before
the museum was anything other than a gleam in PGA's eye).
On that one, the data was intentionally obfuscated because the creator
wanted to hold Paul up for the software to *read* the images; I was
tasked with breaking the obfuscation. This meant that I read every
single piece of DECtape documentation from the PDP-6 through the PDP-15,
so I can speak with some authority on this.
The imaging was done by creating a 2,000,000 byte long file of zeroes,
reading the tape from end to end, and stuffing the data from the tape
into the file by representing the mark track and the three data tracks
in bits 4, 5, 6, and 7 while timing was represented by the position of
the byte in the file.
The obfuscation was to invert the 0/1 value of the bits in the mark
track with respect to the data tracks.
I worked that out by writing dozens of Perl scripts to grovel over the
2MB files, looking for the mark data. Once I found that, I could find
the data tracks, and discover the sense inversion.
It was using the tools I created to read the images of Paul's personal
DECtapes that we were able to recover the immediately precommercial
version of Altair BASIC which we later demonstrated hourly at the museum
(and which Paul demonstrated to Leslie Stahl on 60 Minutes when she
interviewed him at the warehouse that became the museum a few years later).
--
Rich Alderson news(a)alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
11:46 p.m.
Bill Degnan wrote:
I have not yet tried the pdp10 tape image.
This is the file listing from my own extraction tool.
1. F40 SHR 35 1970-04-02
2. LINED OPR 1 1970-02-25
3. LINED 10 1 1970-02-19
4. LNDV10 DOC 25 1970-02-25
5. LINED SHR 1 1970-02-25
6. CREF OPR 1 1969-09-16
7. CREF 42 1 1970-01-11
8. CREF SHR 2 1970-01-19
9. CRFV42 DOC 1 1970-01-14
10. A REL 1 1970-04-22
11. TEST TMP 1 1970-04-29
12. TRANS MAC 2 1970-06-30
13. LAOCN3 SVE 38 1970-06-05
14. TABLE MAC 3 1970-06-30
15. CNVRT MAC 4 1970-06-30
16. LAME V01 57 1970-06-11
17. EXTH 54 1970-06-20
18. EXTH SVE 47 20K 1970-06-20
19. LAOCN4 V01 31 1970-06-16
4:42 p.m.
The PDP-8 tapes are 12 bit words in low bits of 16 bit word. The other
tapes are 18 bits in low bits of 32 bit word. Both little endian. SIMH pdp-8
simulator knows about these formats.
The images only contain the data words from the tape blocks. PDP-8 tapes are
129 word per block and normally 1474 blocks. The 18 bit tapes are 256 words
per block and normally 578 blocks.
PDP-8 PIP10 will give a directory of the PDP-10 tape.
Note in the .zip file are files with 16 in the filename. Those have the
upper 2 zero bytes removed to allow easier viewing of strings in the file. I
don't know if anything supports that format.
On some of the other posts
Did he use read-all mode to read the raw tape
structure? Or is this something
lower level still, without using a TC11 controller?
I have used my TD8E PDP-8 controller to read tapes. I tried
inverting the timing track for reading LINCtapes with the PDP8 but it was hit
or miss so I created the analog digitizer with software decode.
It hooks directly to the head cable.
FYI: My software archive. Some others have read and sent to me.
https://www.pdp8online.com/images/index.shtml
Your comment about 00 tracks does not appear correct.
This was comment on viewing the data files in a hex editor. Its is the number
of bits actually used 16 or 18 in the 32 bit word. Tracks wasn't the best
word choice.
The reader is a bunch of instrument amps that amplify to levels usable by
Saleae logic 16 pro which has analog digitization mode and way too many
times repurposed code to decode it. Doesn't look like I have put it online
probably because the code is embarrassing but ok with giving it away if
someone has use for it.
If I missed question ask again.
On Fri, Jul 31, 2026 at 09:21:19PM -0400, Rich Alderson wrote:
Bill Degnan via cctalk <cctalk(a)classiccmp.org>
writes:
New TU56 Tape Images Available for simH use. I
will post updates on this
thread, but if anyone is interested in messing around with the images
using simH, feel free to download and explore/use.
Just out of curiosity, what is the internal format of these images?
Most especially, what is the internal format of the "18 bit" file?
They look to be something more clever than little endian 32 bit
integers, where "clever" is not necessarily complimentary.
--
Rich Alderson news(a)alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
------------------------------
2 Aug
2 Aug
9:17 a.m.
On Aug 1, 2026, at 8:42 PM, David Gesswein via cctalk
<cctalk(a)classiccmp.org> wrote:
...
As I recall, LINCtape has 4 bit mark track codes rather than 6 bit. I had to sort this
out at one time to write a Python program to recover data from LINCtape captures.
Don't remember where I found the documentation... I assume those were captures you
did.
Hard to imagine how even an "agnostic" DECtape controller can cope with tapes
that have 4 bit mark track codewords...
paul
Did he use read-all mode to read the raw tape
structure? Or is this something
lower level still, without using a TC11 controller?
I have used my TD8E PDP-8 controller to read tapes. I tried
inverting the timing track for reading LINCtapes with the PDP8 but it was hit
or miss so I created the analog digitizer with software decode.
It hooks directly to the head cable.
9:58 a.m.
On Sun, Aug 02, 2026 at 01:17:14PM -0400, Paul Koning wrote:
The TD8E is really dumb and just gives you the
mark track bit and
3 data bits for each tape line on the tape. Decoding is left to software.
It does package the bits in the registers to slightly simplify the software.
Hard to imagine how even an "agnostic"
DECtape controller can cope with tapes
that have 4 bit mark track codewords...
10:27 p.m.
Paul Koning wrote:
I recall, LINCtape has 4 bit mark track codes rather
than 6 bit. I
had to sort this out at one time to write a Python program to recover
data from LINCtape captures.
What data was that? I have written a LINC emulator, so I'm interested
in testing it with real LINC software.
3 Aug
3 Aug
11:49 a.m.
On Aug 3, 2026, at 2:27 AM, Lars Brinkhoff
<lars(a)nocrew.org> wrote:
Paul Koning wrote:
I don't remember and I can't find any of it now, not even the Python program I
used for the analysis. David, do you remember? I was working from raw captures of
LINCtapes, so I'm guessing those might have been yours.
paul
I recall, LINCtape has 4 bit mark track codes
rather than 6 bit. I
had to sort this out at one time to write a Python program to recover
data from LINCtape captures.
What data was that? I have written a LINC emulator, so I'm interested
in testing it with real LINC software.
12:55 p.m.
I don't remember sending off LINCtape images without having a decoder to
image file myself. Doesn't mean I didn't.
I looked at my old email from you and didn't find anything that seemed
related.
Lars is looking for pre merge with PDP-8 LINCtapes. Do you think they were
those or later?
On Mon, Aug 03, 2026 at 03:49:50PM -0400, Paul Koning wrote:
On Aug 3, 2026, at 2:27 AM, Lars Brinkhoff
<lars(a)nocrew.org> wrote:
Paul Koning wrote:
I don't remember and I can't find any of it now, not even the Python program I
used for the analysis. David, do you remember? I was working from raw captures of
LINCtapes, so I'm guessing those might have been yours.
paul
I recall, LINCtape has 4 bit mark track codes
rather than 6 bit. I
had to sort this out at one time to write a Python program to recover
data from LINCtape captures.
What data was that? I have written a LINC emulator, so I'm interested
in testing it with real LINC software.
2 Aug
2 Aug
9:18 a.m.
On Aug 1, 2026, at 8:42 PM, David Gesswein via cctalk
<cctalk(a)classiccmp.org> wrote:
The PDP-8 tapes are 12 bit words in low bits of 16 bit word. The other
tapes are 18 bits in low bits of 32 bit word. Both little endian. SIMH pdp-8
simulator knows about these formats.
The images only contain the data words from the tape blocks. PDP-8 tapes are
129 word per block and normally 1474 blocks. The 18 bit tapes are 256 words
per block and normally 578 blocks.
PDP-8 PIP10 will give a directory of the PDP-10 tape.
So will RT-11 FILEX, which from what ABC told me recovers the upper 2 bits in each word by
watching the CSR as the data DMA is underway, rather than doing read-all. I forgot why he
did it that way.
paul
1 Aug
1 Aug
11:42 p.m.
Rich Alderson via cctalk <cctalk(a)classiccmp.org> writes:
Just out of curiosity, what is the internal format of
these images?
Most especially, what is the internal format of the "18 bit" file?
All PDP-6/10 DECtape images I have seen (and I assume this also applies
to any 18-bit image) have each block being 256 32-bit little endian
words. Each word stores an 18-bit number. For a 36-bit tape, the words
are paired to form 128 36-bit numbers. The number of blocks are
typically around 576. There is no low-level format info.
18
days inactive
21
days old
16 comments
6 participants
participants (6)
-
Bill Degnan -
Chris Zach -
David Gesswein -
Lars Brinkhoff -
Paul Koning -
Rich Alderson