From IanK at vulcan.com  Mon Mar 11 21:00:18 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 12 Mar 2013 01:00:18 +0000
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D77AE0@505MBX2.corp.vnw.com>

Hi folks, 

I'm doing some work where I need to build some DECtapes for a PDP-10,
using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
emulated TC08/TU56.  The emulator simply hangs.  I also tried just
creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
resulting in a hang.

Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
recognized on SIMH?  :-)  Thanks -- Ian

I'm done with this two-bit town.  Show me a twelve-bit town ? now we're
talking.  

Ian S. King, Sr. Vintage Systems Engineer
Living Computer Museum
A presentation of Vulcan, Inc.
http://www.livingcomputermuseum.org


From IanK at vulcan.com  Tue Mar 12 00:53:23 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 12 Mar 2013 04:53:23 +0000
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D77AE0@505MBX2.corp.vnw.com>
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>

On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:

>Hi folks, 
>
>I'm doing some work where I need to build some DECtapes for a PDP-10,
>using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>resulting in a hang.
>
>Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>recognized on SIMH?  :-)  Thanks -- Ian
>
>I'm done with this two-bit town.  Show me a twelve-bit town ? now we're
>talking.  
>
>Ian S. King, Sr. Vintage Systems Engineer
>Living Computer Museum
>A presentation of Vulcan, Inc.
>http://www.livingcomputermuseum.org
>
>_______________________________________________
>Simh mailing list
>Simh at trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>

To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
emulation, using PIP10.  A couple of (thank you so much) replies made me
realize my statement of the problem was ambiguous.  -- Ian 


From bqt at softjar.se  Tue Mar 12 06:50:17 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 12 Mar 2013 11:50:17 +0100
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
References: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
Message-ID: <513F0869.10300@softjar.se>

On 2013-03-12 05:53, Ian King wrote:
> On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:
> 
>> Hi folks,
>>
>> I'm doing some work where I need to build some DECtapes for a PDP-10,
>> using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>> some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>> emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>> creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>> resulting in a hang.
>>
>> Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>> recognized on SIMH?  :-)  Thanks -- Ian
>>
>> I'm done with this two-bit town.  Show me a twelve-bit town ? now we're
>> talking.
>>
>> Ian S. King, Sr. Vintage Systems Engineer
>> Living Computer Museum
>> A presentation of Vulcan, Inc.
>> http://www.livingcomputermuseum.org
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
> 
> To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
> emulation, using PIP10.  A couple of (thank you so much) replies made me
> realize my statement of the problem was ambiguous.  -- Ian

I understood you the first time. My big question would be if you are
sure the TC08 emulation is good enough. PIP10 uses its own code to
handle the drive, and uses it in ways no other PDP8 code likely do. It
definitely would test the emulation much harder than anything else I can
think of.

	Johnny

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

From bqt at softjar.se  Tue Mar 12 07:40:33 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 12 Mar 2013 12:40:33 +0100
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <513F0869.10300@softjar.se>
References: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
 <513F0869.10300@softjar.se>
Message-ID: <513F1431.6000505@softjar.se>

On 2013-03-12 11:50, Johnny Billquist wrote:
> On 2013-03-12 05:53, Ian King wrote:
>> On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:
>>
>>> Hi folks,
>>>
>>> I'm doing some work where I need to build some DECtapes for a PDP-10,
>>> using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>>> some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>>> emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>>> creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>>> resulting in a hang.
>>>
>>> Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>>> recognized on SIMH?  :-)  Thanks -- Ian
>>>
>>> I'm done with this two-bit town.  Show me a twelve-bit town ? now we're
>>> talking.
>>>
>>> Ian S. King, Sr. Vintage Systems Engineer
>>> Living Computer Museum
>>> A presentation of Vulcan, Inc.
>>> http://www.livingcomputermuseum.org
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>>
>>
>> To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
>> emulation, using PIP10.  A couple of (thank you so much) replies made me
>> realize my statement of the problem was ambiguous.  -- Ian
> 
> I understood you the first time. My big question would be if you are
> sure the TC08 emulation is good enough. PIP10 uses its own code to
> handle the drive, and uses it in ways no other PDP8 code likely do. It
> definitely would test the emulation much harder than anything else I can
> think of.

By the way, another question is how your PDP-10 formatted tapes got onto
the host running simh, and connected to the simulated TU56. Did you have
some real PDP-10 DECtapes that you transferred somehow? If so, then how?
Or did you get them using some PDP-10 simulator to create them on a
smimulated DECtape on the ten side?
Are the simulated tape format in the files compatible? Exactly how do
the format look like? DECtape as such have a rather free form in some
ways. It's not totally clear to me in which way I would represent these
tapes on disk in a way that would allow me to operate correctly on them.
Especially if we want to deal with both 12-bit and 18-bit formatted
tapes. This can get rather hairy. On the real systems, this is mostly
done in hardware, but it is rather fiddly.

	Johnny

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

From aek at bitsavers.org  Thu Mar 14 14:24:15 2013
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 14 Mar 2013 11:24:15 -0700
Subject: [Simh] Fwd: SimH, PDP8 OS/8 and RKLFMT hang
In-Reply-To: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
References: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
Message-ID: <514215CF.6090803@bitsavers.org>

forwarded from the classiccmp mailing list


-------- Original Message --------
Subject: SimH, PDP8 OS/8 and RKLFMT hang
Date: Thu, 14 Mar 2013 11:03:47 -0700
From: Rick Bensene <rickb at bensene.com>
Reply-To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>

I'm running SimH V3.9 on a PC under Windows 7  using the binaries from
the primary SimH website.
I'm running the OS8 distribution on floppy that is packaged on the Simh
site.
I attached an 'empty' RK disk drive file as RK0, and tried to run RKLFMT
on it to "format" the drive.
The RKLFMT program asks its questions (which drives to format), then
says "ARE YOU SURE?" and expects a Y or N.  If N is typed, the questions
about which drives to format are repeated.  If Y is typed, the
formatting process begins.

On real PDP8/e hardware, it all does what it is supposed to...the drive
does a bunch of writes, then goes back and reads the sectors to verify
that they were written correctly, then prints out a message indicating
that the format passes are complete, and then starts over with the
"which disks to format" question, at which point you can type ^C to
exit.

However, in SimH, the program starts up and asks which drives to format,
and I say "Y" to drive 0, and "N" to the other 7 drives, then the "ARE
YOU SURE?" prompt comes up, and I type "Y", and the Y echoes back, and
then  it just sits there.
On real hardware, it takes about 80 seconds to format a drive.  I waited
MUCH longer than this to see if the simulated RKLFMT would eventually
come back indicating that it had completed.  It didn't.

I used ^E to interrupt the execution, and stepped through a few
instructions, and it appears to be hung in a loop waiting for the disk
drive to do something.  I checked to see if the disk file holding the
emulated RK05 drive had changed in size, and it was still at 0 bytes.

The RKLFMT program uses the RK8E disk controller's "WRITE ALL" and "READ
ALL" functions to format and verify the drive.  These RK8E commands
ignore header information on the sectors, and just writes/reads the
data, as opposed to the normal READ and WRITE commands that pay
attention to the sector header information.

I am wondering if perhaps the SimH emulation of the RK8E is flawed in
some way such that the READ ALL and WRITE ALL commands don't work
properly, causing RKLFMT to fail.

I can get the emulated RK05 to work by simply issuing a "ZERO RKA0:"
command to OS8, which writes the directory information on the disk,
making it accessible to OS8.

Has anyone run into this before?  It isn't a big deal in terms of
usability of emulated RK05s in the PDP 8 SimH implementation, but I'm
wondering if it might be a technical detail in the emulation  of the
RK8E that isn't quite correct.

I'd be interesting in hearing anything that folks may have run into or
heard about this.

Thanks,
Rick Bensene







From Mark at infocomm.com  Thu Mar 14 16:34:03 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 14 Mar 2013 13:34:03 -0700
Subject: [Simh] Fwd: SimH, PDP8 OS/8 and RKLFMT hang
In-Reply-To: <514215CF.6090803@bitsavers.org>
References: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
 <514215CF.6090803@bitsavers.org>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E6884B18A@REDROOF2.alohasunset.com>

On Thursday, March 14, 2013 at 11:24 AM, Al Kossow wrote:
> forwarded from the classiccmp mailing list
> 
> 
> -------- Original Message --------
> Subject: SimH, PDP8 OS/8 and RKLFMT hang
> Date: Thu, 14 Mar 2013 11:03:47 -0700
> From: Rick Bensene <rickb at bensene.com>
> Reply-To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> 
> I'm running SimH V3.9 on a PC under Windows 7  using the binaries from the
> primary SimH website.
> I'm running the OS8 distribution on floppy that is packaged on the Simh site.
> I attached an 'empty' RK disk drive file as RK0, and tried to run RKLFMT on it
> to "format" the drive.
> The RKLFMT program asks its questions (which drives to format), then says
> "ARE YOU SURE?" and expects a Y or N.  If N is typed, the questions about
> which drives to format are repeated.  If Y is typed, the formatting process
> begins.
> 
> On real PDP8/e hardware, it all does what it is supposed to...the drive does a
> bunch of writes, then goes back and reads the sectors to verify that they
> were written correctly, then prints out a message indicating that the format
> passes are complete, and then starts over with the "which disks to format"
> question, at which point you can type ^C to exit.
> 
> However, in SimH, the program starts up and asks which drives to format,
> and I say "Y" to drive 0, and "N" to the other 7 drives, then the "ARE YOU
> SURE?" prompt comes up, and I type "Y", and the Y echoes back, and then  it
> just sits there.
> On real hardware, it takes about 80 seconds to format a drive.  I waited
> MUCH longer than this to see if the simulated RKLFMT would eventually
> come back indicating that it had completed.  It didn't.

Hi Rick,

Great description.  100% reproducible.

The issue was that the initial RK disk operation was completing too quickly.  Changing RK_MIN from 10 to 45 allows things to work as expected.

The problem is fixed in the latest source at https://github.com/simh/simh/archive/master.zip

Pre Compiled binaries are available at:  https://github.com/simh/Win32-Development-Binaries/blob/Win32-Development-Binaries/simh-4.0-Beta--2013-03-14-b06505ab.zip

- Mark




From bob at supnik.org  Mon Mar 18 12:44:44 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 18 Mar 2013 12:44:44 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
Message-ID: <5147447C.9000501@supnik.org>

I was trying to get a debug setup for PIP10, per Ian King's mail, when I 
discovered that none of my OS/8 images have PIP10 on them. This 
certainly explains why the feature has never been tested before. I 
suspect that ReadAll and WriteAll either are not working at all, or are 
not working when the DECtape format is 18b. Another possibility is that 
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty 
level (format of headers and trailers).

If anyone has a canned OS/8 V3C image with PIP10, please post it 
somewhere (like Mediafire) and let me know by email.

Thanks,

/Bob Supnik


From litt at ieee.org  Mon Mar 18 13:20:03 2013
From: litt at ieee.org (Timothe Litt)
Date: Mon, 18 Mar 2013 13:20:03 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147447C.9000501@supnik.org>
References: <5147447C.9000501@supnik.org>
Message-ID: <51474CC3.5040408@ieee.org>

Well, there's 
http://www.filewatcher.com/b/ftp/sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8-0.html, 
which has V3d (and sources)...

This communication may not represent my employer's views,
if any, on the matters discussed.

On 18-Mar-13 12:44, Bob Supnik wrote:
> I was trying to get a debug setup for PIP10, per Ian King's mail, when 
> I discovered that none of my OS/8 images have PIP10 on them. This 
> certainly explains why the feature has never been tested before. I 
> suspect that ReadAll and WriteAll either are not working at all, or 
> are not working when the DECtape format is 18b. Another possibility is 
> that PDP-10 DECtape format is not the same as 18b format, at the 
> nitty-gritty level (format of headers and trailers).
>
> If anyone has a canned OS/8 V3C image with PIP10, please post it 
> somewhere (like Mediafire) and let me know by email.
>
> Thanks,
>
> /Bob Supnik
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130318/9b6836b6/attachment.bin>

From bqt at softjar.se  Mon Mar 18 16:26:52 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Mon, 18 Mar 2013 21:26:52 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147447C.9000501@supnik.org>
References: <5147447C.9000501@supnik.org>
Message-ID: <5147788C.2090901@softjar.se>

On 2013-03-18 17:44, Bob Supnik wrote:
> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
> discovered that none of my OS/8 images have PIP10 on them. This
> certainly explains why the feature has never been tested before. I
> suspect that ReadAll and WriteAll either are not working at all, or are
> not working when the DECtape format is 18b. Another possibility is that
> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
> level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same 
on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) 
words, however, while a PDP-10 (or any other 18-bitter) would have 128 
18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way 
that is rather different from an 18-bit machine. But at the tape as 
such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in 
manuals, but in essence a DECtape is always doing 18-bit words. That is 
done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means 
that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is 
formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, 
and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months 
ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had 
actually been written on a PDP-15, I had to write my own code in the 
end, to just dump the raw data.

> If anyone has a canned OS/8 V3C image with PIP10, please post it
> somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, 
including sources (if I remember right) somewhere. Let me know if it 
can't be located anywhere else.

	Johnny


From litt at ieee.org  Tue Mar 19 09:03:15 2013
From: litt at ieee.org (Timothe Litt)
Date: Tue, 19 Mar 2013 09:03:15 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147788C.2090901@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
Message-ID: <51486213.8040508@ieee.org>

> The DECtape format as such, with all the headers and so on, is the 
> same on all tapes. A normal PDP-8 formatted tape will have 129 
> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would 
> have 128 18-bit words (if I remember right). 
Pretty much right.  129 may be slightly misleading.  The format is 129, 
but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) 
formatted DECtape would have 578 blocks of 128 36-bit words.  (256 
18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't 
contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data. The 
directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH 
= first block & words used in this block) + 127 words of payload.  This 
differed from disk files, where all 128 words were payload, so 
inattentive programmers could make a number of mistakes.  (E.g. random 
access block isn't word/128; you had to pay attention to the buffer's 
word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the 
drive to stop and restart while reading or writing without having to 
reverse direction.  The spacing depended on what blocks were free when 
files were written, and the data mode.  (Files written in 'core dump' 
modes were assumed to be read by the monitor without stopping, so the 
gap was smaller, allowing larger programs to be read without reversing 
direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word 
(except when reading PDP-10 tapes; the hardware for that was tricky as 
the high bits had to be read with programmed IO; the low 16 were DMAed 
on the TC-11.)

The low-level formatting that established the mark track, end zones and 
block delimiters was done via a stand-alone diagnostic. This differs 
between the two formats.  The directory block could be initialized under 
timesharing.

Directory structure given is for the PDP-10; other OSs used different 
formats.

 From an emulation point of view, the PDP-10's controller was the most 
interesting; the driver does dead reckoning; that is, it will start a 
drive spinning for a seek, disconnect, service other drives, and 
reconnect just before the desired block is expected to be over the read 
head.  So real-world timing matters.  The other controllers (and thus 
OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct 
link 
isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ 
Sorry if this was confusing.

Of potential interest to low-level folks is 
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 18-Mar-13 16:26, Johnny Billquist wrote:
> On 2013-03-18 17:44, Bob Supnik wrote:
>> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
>> discovered that none of my OS/8 images have PIP10 on them. This
>> certainly explains why the feature has never been tested before. I
>> suspect that ReadAll and WriteAll either are not working at all, or are
>> not working when the DECtape format is 18b. Another possibility is that
>> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
>> level (format of headers and trailers).
>
> The DECtape format as such, with all the headers and so on, is the 
> same on all tapes. A normal PDP-8 formatted tape will have 129 
> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would 
> have 128 18-bit words (if I remember right).
> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way 
> that is rather different from an 18-bit machine. But at the tape as 
> such, there is nothing odd about it.
>
> But I can see lots of potential for errors when emulating this whole 
> thing.
>
> I couldn't give exact details on lots of bits without looking in 
> manuals, but in essence a DECtape is always doing 18-bit words. That 
> is done by doing 6 groups of 3 bits each.
> A PDP-8 will pack three 12-bit words into two 18-bit words. This means 
> that a DECtape block for a PDP-8 will only have 86 18-bit words.
> So the blocks are shorter, but you have more of them, when the tape is 
> formatted for a PDP-8.
>
> I hope (assume) that you already know all of this. If not, let me 
> know, and I can try helping out some more.
> I actually did dump a few 18-bit tapes on my PDP-8 only a few months 
> ago, which is when I actually had to dig rather deep into all of this.
> PIP10 was one of the things I really looked into. But since my tapes 
> had actually been written on a PDP-15, I had to write my own code in 
> the end, to just dump the raw data.
>
>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>> somewhere (like Mediafire) and let me know by email.
>
> I think someone already posted this, but I know I have that software, 
> including sources (if I remember right) somewhere. Let me know if it 
> can't be located anywhere else.
>
>     Johnny
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/57ae2877/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/57ae2877/attachment-0001.bin>

From bqt at softjar.se  Tue Mar 19 09:25:25 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 14:25:25 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486213.8040508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
Message-ID: <51486745.3010802@softjar.se>

On 2013-03-19 14:03, Timothe Litt wrote:
>> The DECtape format as such, with all the headers and so on, is the
>> same on all tapes. A normal PDP-8 formatted tape will have 129
>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>> have 128 18-bit words (if I remember right).
> Pretty much right.  129 may be slightly misleading.  The format is 129,
> but the -8 used  only 128 of the 129 12-bit words/block for data.

Right. :-)

> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
> formatted DECtape would have 578 blocks of 128 36-bit words.  (256
> 18-bit words at the hardware level.)

I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape 
as such, which physically always stores 18 bits. A PDP-10 would 
obviously store its 36-bit words using two DECtape words. Any 18-bit 
machine is straight forward, while the PDP-11 (as you mention below) 
only use 16 bits of the 18-bit word.

I thought it was 128 18-bit words, but I may well remember that wrong, 
and the "normal" format is 256 18-bit words. Makes sense, when I think 
about it.

The number of blocks is not absolutely fixed, but 578 is the "standard" 
except on the PDP-8, I guess.

> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
> contain user data.

That would be very depending on which machine we're talking about, and 
which controller... :-) But I assume you're talking about the PDP-10 
here. Did all PDP-10 with DECtapes use the same controller? I assume 
both the KA and KI had DECtapes, as well as the PDP-6.

> Block 100 is the directory block.  Thus 574 blocks for user data. The
> directory holds up to 22 files, plus a map of which file owns each block.
>
> The user data blocks have a one word header (LH = next block of file; RH
> = first block & words used in this block) + 127 words of payload.  This
> differed from disk files, where all 128 words were payload, so
> inattentive programmers could make a number of mistakes.  (E.g. random
> access block isn't word/128; you had to pay attention to the buffer's
> word count, etc.)
>
> Data blocks of a file are (usually) not contiguous; this allowed the
> drive to stop and restart while reading or writing without having to
> reverse direction.  The spacing depended on what blocks were free when
> files were written, and the data mode.  (Files written in 'core dump'
> modes were assumed to be read by the monitor without stopping, so the
> gap was smaller, allowing larger programs to be read without reversing
> direction.)
>
> The gory details of the format are in the Monitor Calls manual (TOPS-10).

TOPS-10 DECtape format is definitely not something I know anything 
about. But thanks for the rundown.

> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
> (except when reading PDP-10 tapes; the hardware for that was tricky as
> the high bits had to be read with programmed IO; the low 16 were DMAed
> on the TC-11.)

Yes! Thanks for bringing another murky memory.

> The low-level formatting that established the mark track, end zones and
> block delimiters was done via a stand-alone diagnostic. This differs
> between the two formats.  The directory block could be initialized under
> timesharing.

Um? What two formats?

> Directory structure given is for the PDP-10; other OSs used different
> formats.
>
>  From an emulation point of view, the PDP-10's controller was the most
> interesting; the driver does dead reckoning; that is, it will start a
> drive spinning for a seek, disconnect, service other drives, and
> reconnect just before the desired block is expected to be over the read
> head.  So real-world timing matters.  The other controllers (and thus
> OSs) didn't support this.

Wow. The TC08 actually did seeks while actually looking at the tape, and 
then did DMA as well. So you didn't have to pay any more attention than 
to a disk controller.
Essentially, you asked it to seek, and it indicated when the seek was 
done. You asked it to read, and it read.
As far as I can remember, the TC11 is the same.
Not sure what you mean by "other controllers didn't support this". What 
is "this". Doing dead reckoning? Why would you actually want to do dead 
reckoning. It makes much more sense to actually look at the tape the 
whole time it is spinning by, and not only when you are getting close to 
where you want to be. And the hardware can do that without your involvement.

In a way, however, I'd say that the TD8E is the most "interesting" 
controller to emulate, since it is so incredibly stupid that you 
actually have to emulate the low level format of the tape for that 
controller to work.
It is truly ugly. And that controller was a headache if you ever wanted 
to use it in a timesharing operating system, since it did not do DMA, it 
did not really do seeks, or in fact anything at all except just feed the 
bits from the tape to the computer as they whizzed by.

> Oh, all numbers above are radix 10.

What's wrong with you. ;-)

> The link for OS8 that I posted yesterday was via filewatcher; the direct
> link
> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
> Sorry if this was confusing.
>
> Of potential interest to low-level folks is
> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>
> Hope this is useful.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.

Thanks for all the interesting bits and pieces.

	Johnny

>
> On 18-Mar-13 16:26, Johnny Billquist wrote:
>> On 2013-03-18 17:44, Bob Supnik wrote:
>>> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
>>> discovered that none of my OS/8 images have PIP10 on them. This
>>> certainly explains why the feature has never been tested before. I
>>> suspect that ReadAll and WriteAll either are not working at all, or are
>>> not working when the DECtape format is 18b. Another possibility is that
>>> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
>>> level (format of headers and trailers).
>>
>> The DECtape format as such, with all the headers and so on, is the
>> same on all tapes. A normal PDP-8 formatted tape will have 129
>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>> have 128 18-bit words (if I remember right).
>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>> that is rather different from an 18-bit machine. But at the tape as
>> such, there is nothing odd about it.
>>
>> But I can see lots of potential for errors when emulating this whole
>> thing.
>>
>> I couldn't give exact details on lots of bits without looking in
>> manuals, but in essence a DECtape is always doing 18-bit words. That
>> is done by doing 6 groups of 3 bits each.
>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>> So the blocks are shorter, but you have more of them, when the tape is
>> formatted for a PDP-8.
>>
>> I hope (assume) that you already know all of this. If not, let me
>> know, and I can try helping out some more.
>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>> ago, which is when I actually had to dig rather deep into all of this.
>> PIP10 was one of the things I really looked into. But since my tapes
>> had actually been written on a PDP-15, I had to write my own code in
>> the end, to just dump the raw data.
>>
>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>> somewhere (like Mediafire) and let me know by email.
>>
>> I think someone already posted this, but I know I have that software,
>> including sources (if I remember right) somewhere. Let me know if it
>> can't be located anywhere else.
>>
>>     Johnny
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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

From Jason.Armistead at otis.com  Tue Mar 19 09:30:07 2013
From: Jason.Armistead at otis.com (Armistead, Jason)
Date: Tue, 19 Mar 2013 13:30:07 +0000
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486213.8040508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>

I had trouble with Timothe?s link to the USPTO, but found this same patent in PDF form at

http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf

As a relative newbie who started my serious journey into computing with an Apple ][  I?ve never fully understood DEC?s fascination with word lengths that weren?t multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer ? mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN).  Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words.  All I?ve ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!)

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh at trailing-edge.com
Subject: Re: [Simh] PIP10 on PDP-8 SIM

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
Pretty much right.  129 may be slightly misleading.  The format is 129, but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words.  (256 18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data.  The directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload.  This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes.  (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction.  The spacing depended on what blocks were free when files were written, and the data mode.  (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.)

The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic.  This differs between the two formats.  The directory block could be initialized under timesharing.

Directory structure given is for the PDP-10; other OSs used different formats.

>From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head.  So real-world timing matters.  The other controllers (and thus OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing.

Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.



This communication may not represent my employer's views,

if any, on the matters discussed.
On 18-Mar-13 16:26, Johnny Billquist wrote:
On 2013-03-18 17:44, Bob Supnik wrote:

I was trying to get a debug setup for PIP10, per Ian King's mail, when I
discovered that none of my OS/8 images have PIP10 on them. This
certainly explains why the feature has never been tested before. I
suspect that ReadAll and WriteAll either are not working at all, or are
not working when the DECtape format is 18b. Another possibility is that
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to write my own code in the end, to just dump the raw data.


If anyone has a canned OS/8 V3C image with PIP10, please post it
somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, including sources (if I remember right) somewhere. Let me know if it can't be located anywhere else.

    Johnny

_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/05720b28/attachment-0001.html>

From bqt at softjar.se  Tue Mar 19 09:43:10 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 14:43:10 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
Message-ID: <51486B6E.7080304@softjar.se>

On 2013-03-19 14:30, Armistead, Jason wrote:
> I had trouble with Timothe?s link to the USPTO, but found this same
> patent in PDF form at
>
> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>
> As a relative newbie who started my serious journey into computing with
> an Apple ][  I?ve never fully understood DEC?s fascination with word
> lengths that weren?t multiples of 2 (even though I dabbled with the
> PDP-11s at the local council my father worked at as a civil engineer ?
> mainly to play Mugwump and Wumpus after giving up on trying to learn
> FORTRAN).  Maybe someone can give a brief history behind the 12-bit,
> 18-bit and 36-bit sizing of words.  All I?ve ever had to deal with are
> 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I
> do remember the 4004 !!!)

It wasn't just DEC. Back in the day, most everyone used various word 
lengths that wasn't a power of two. I can't really make many comments on 
why other word lengths were more popular. I've seen mentioned that 
floating point formats was pretty nice to do with something like 60 or 
72 bits. Reason being that you had large enough exponents for useful 
things, and enough precision for most calculations.
So a word length that related to this made sense.

Number of bits being a power of two started with IBM in the 60s, and 
became common with the PDP-11 in the 70s. (Or so I'd like to think.)

	Johnny

>
> *From:*simh-bounces at trailing-edge.com
> [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *Timothe Litt
> *Sent:* Tuesday, 19 March 2013 9:03 AM
> *To:* simh at trailing-edge.com
> *Subject:* Re: [Simh] PIP10 on PDP-8 SIM
>
>     The DECtape format as such, with all the headers and so on, is the
>     same on all tapes. A normal PDP-8 formatted tape will have 129
>     (12-bit) words, however, while a PDP-10 (or any other 18-bitter)
>     would have 128 18-bit words (if I remember right).
>
> Pretty much right.  129 may be slightly misleading.  The format is 129,
> but the -8 used  only 128 of the 129 12-bit words/block for data.
>
> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
> formatted DECtape would have 578 blocks of 128 36-bit words.  (256
> 18-bit words at the hardware level.)
>
> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
> contain user data.
>
> Block 100 is the directory block.  Thus 574 blocks for user data.  The
> directory holds up to 22 files, plus a map of which file owns each block.
>
> The user data blocks have a one word header (LH = next block of file; RH
> = first block & words used in this block) + 127 words of payload.  This
> differed from disk files, where all 128 words were payload, so
> inattentive programmers could make a number of mistakes. (E.g. random
> access block isn't word/128; you had to pay attention to the buffer's
> word count, etc.)
>
> Data blocks of a file are (usually) not contiguous; this allowed the
> drive to stop and restart while reading or writing without having to
> reverse direction.  The spacing depended on what blocks were free when
> files were written, and the data mode.  (Files written in 'core dump'
> modes were assumed to be read by the monitor without stopping, so the
> gap was smaller, allowing larger programs to be read without reversing
> direction.)
>
> The gory details of the format are in the Monitor Calls manual (TOPS-10).
>
> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
> (except when reading PDP-10 tapes; the hardware for that was tricky as
> the high bits had to be read with programmed IO; the low 16 were DMAed
> on the TC-11.)
>
> The low-level formatting that established the mark track, end zones and
> block delimiters was done via a stand-alone diagnostic.  This differs
> between the two formats.  The directory block could be initialized under
> timesharing.
>
> Directory structure given is for the PDP-10; other OSs used different
> formats.
>
>  From an emulation point of view, the PDP-10's controller was the most
> interesting; the driver does dead reckoning; that is, it will start a
> drive spinning for a seek, disconnect, service other drives, and
> reconnect just before the desired block is expected to be over the read
> head.  So real-world timing matters.  The other controllers (and thus
> OSs) didn't support this.
>
> Oh, all numbers above are radix 10.
>
> The link for OS8 that I posted yesterday was via filewatcher; the direct
> link
> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
> <ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/>
> Sorry if this was confusing.
>
> Of potential interest to low-level folks is
> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>
> Hope this is useful.
>
>
> This communication may not represent my employer's views,
>
> if any, on the matters discussed.
>
> On 18-Mar-13 16:26, Johnny Billquist wrote:
>
>     On 2013-03-18 17:44, Bob Supnik wrote:
>
>     I was trying to get a debug setup for PIP10, per Ian King's mail,
>     when I
>     discovered that none of my OS/8 images have PIP10 on them. This
>     certainly explains why the feature has never been tested before. I
>     suspect that ReadAll and WriteAll either are not working at all, or are
>     not working when the DECtape format is 18b. Another possibility is that
>     PDP-10 DECtape format is not the same as 18b format, at the
>     nitty-gritty
>     level (format of headers and trailers).
>
>
>     The DECtape format as such, with all the headers and so on, is the
>     same on all tapes. A normal PDP-8 formatted tape will have 129
>     (12-bit) words, however, while a PDP-10 (or any other 18-bitter)
>     would have 128 18-bit words (if I remember right).
>     The PDP-8, when doing 12-bit formatted tapes, just packs data in a
>     way that is rather different from an 18-bit machine. But at the tape
>     as such, there is nothing odd about it.
>
>     But I can see lots of potential for errors when emulating this whole
>     thing.
>
>     I couldn't give exact details on lots of bits without looking in
>     manuals, but in essence a DECtape is always doing 18-bit words. That
>     is done by doing 6 groups of 3 bits each.
>     A PDP-8 will pack three 12-bit words into two 18-bit words. This
>     means that a DECtape block for a PDP-8 will only have 86 18-bit words.
>     So the blocks are shorter, but you have more of them, when the tape
>     is formatted for a PDP-8.
>
>     I hope (assume) that you already know all of this. If not, let me
>     know, and I can try helping out some more.
>     I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>     ago, which is when I actually had to dig rather deep into all of this.
>     PIP10 was one of the things I really looked into. But since my tapes
>     had actually been written on a PDP-15, I had to write my own code in
>     the end, to just dump the raw data.
>
>
>     If anyone has a canned OS/8 V3C image with PIP10, please post it
>     somewhere (like Mediafire) and let me know by email.
>
>
>     I think someone already posted this, but I know I have that
>     software, including sources (if I remember right) somewhere. Let me
>     know if it can't be located anywhere else.
>
>          Johnny
>
>     _______________________________________________
>     Simh mailing list
>     Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>     http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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

From tshoppa at wmata.com  Tue Mar 19 09:47:37 2013
From: tshoppa at wmata.com (Shoppa, Tim)
Date: Tue, 19 Mar 2013 13:47:37 +0000
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
Message-ID: <303A17BD5F8FA34DA45EEC245271AC0B7434C07E@JGEX2K10MBX2.wmata.local>

Non-power-of-2 word sizes are in many applications today. 12- and 14-bit instruction width PIC processors are sold by the billions.  24-bit data width DSP's are extremely common, and other sizes including
28-bit, 36-bit, 48-bit, and 56-bit data widths abound in DSP audio/video processing and other applications.

Tim.

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason
Sent: Tuesday, March 19, 2013 9:30 AM
To: simh at trailing-edge.com
Subject: Re: [Simh] PIP10 on PDP-8 SIM

I had trouble with Timothe's link to the USPTO, but found this same patent in PDF form at

http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf

As a relative newbie who started my serious journey into computing with an Apple ][  I've never fully understood DEC's fascination with word lengths that weren't multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer - mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN).  Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words.  All I've ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!)

From: simh-bounces at trailing-edge.com<mailto:simh-bounces at trailing-edge.com> [mailto:simh-bounces at trailing-edge.com] On Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: Re: [Simh] PIP10 on PDP-8 SIM

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
Pretty much right.  129 may be slightly misleading.  The format is 129, but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words.  (256 18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data.  The directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload.  This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes.  (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction.  The spacing depended on what blocks were free when files were written, and the data mode.  (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.)

The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic.  This differs between the two formats.  The directory block could be initialized under timesharing.

Directory structure given is for the PDP-10; other OSs used different formats.

>From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head.  So real-world timing matters.  The other controllers (and thus OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing.

Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.


This communication may not represent my employer's views,

if any, on the matters discussed.
On 18-Mar-13 16:26, Johnny Billquist wrote:
On 2013-03-18 17:44, Bob Supnik wrote:
I was trying to get a debug setup for PIP10, per Ian King's mail, when I
discovered that none of my OS/8 images have PIP10 on them. This
certainly explains why the feature has never been tested before. I
suspect that ReadAll and WriteAll either are not working at all, or are
not working when the DECtape format is 18b. Another possibility is that
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to write my own code in the end, to just dump the raw data.

If anyone has a canned OS/8 V3C image with PIP10, please post it
somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, including sources (if I remember right) somewhere. Let me know if it can't be located anywhere else.

    Johnny

_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/cd973e66/attachment-0001.html>

From litt at ieee.org  Tue Mar 19 09:56:02 2013
From: litt at ieee.org (Timothe Litt)
Date: Tue, 19 Mar 2013 09:56:02 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486745.3010802@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org> <51486745.3010802@softjar.se>
Message-ID: <51486E72.4010508@ieee.org>


This communication may not represent my employer's views,
if any, on the matters discussed.

Consider a timesharing system, with 4 users each trying to transfer from 
their own DTA.  With a TC11, you serviced user 1, user, 3, user 4, user 
2 sequentially.   The controller was tied up for the whole seek for each 
user - potentially from one end of the tape to the other.

The TD10-'s dead reckoning allowed  the seeks to proceed in parallel.  
E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by 
the controller.  When the shortest seek was near completion, the driver 
would tell the controller to pay attention to that drive ('connect'), do 
the transfer, and stop.  Then the next.  Besides being impressive to 
watch (8 drives spinning in various directions), the user request 
latency was reduced.   (Some systems had two controllers, for 16 drives!)

The KA, KI and KL (with the IO Bus adapter) all used the TD10 
controller.  The -6 had another controller - type 551.  I think it was a 
dumb controller, but didn't use it personally.

129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats.  
Gory details of the TD10 are at

http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/DEC-10-I3AA-D%20TD10%20DECtape%20Control%20Maintenance%20Manual.pdf

Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the 
format info I provided was for the 10.  TOPS-10.  MAC had another format 
for the -6.  TOPS-20 didn't officially support DECtapes, but internally 
we had systems with them.  They used the PDP-10 format.

Much of the pdp-10 format documentation is a mixture of octal and 
decimal.  I picked decimal because these days, thinking in octal is a 
(mostly) lost art.

IBM and many other vendors used 36-bits, because the (BCD) character 
codes of the day were 6-bits, so it packed nicely.  The -8 was 12 bits 
for the same reason, only it was cheaper to build.

The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii, 
8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.

The -11 was designed after 8-bit character codes became popular. EBCDIC 
was (and is) an ugly mess; ASCII cemented 8-bit character codes.  And 
machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the 
most popular.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 19-Mar-13 09:25, Johnny Billquist wrote:
> On 2013-03-19 14:03, Timothe Litt wrote:
>>> The DECtape format as such, with all the headers and so on, is the
>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>> have 128 18-bit words (if I remember right).
>> Pretty much right.  129 may be slightly misleading.  The format is 129,
>> but the -8 used  only 128 of the 129 12-bit words/block for data.
>
> Right. :-)
>
>> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
>> formatted DECtape would have 578 blocks of 128 36-bit words. (256
>> 18-bit words at the hardware level.)
>
> I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape 
> as such, which physically always stores 18 bits. A PDP-10 would 
> obviously store its 36-bit words using two DECtape words. Any 18-bit 
> machine is straight forward, while the PDP-11 (as you mention below) 
> only use 16 bits of the 18-bit word.
>
> I thought it was 128 18-bit words, but I may well remember that wrong, 
> and the "normal" format is 256 18-bit words. Makes sense, when I think 
> about it.
>
> The number of blocks is not absolutely fixed, but 578 is the 
> "standard" except on the PDP-8, I guess.
>
>> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
>> contain user data.
>
> That would be very depending on which machine we're talking about, and 
> which controller... :-) But I assume you're talking about the PDP-10 
> here. Did all PDP-10 with DECtapes use the same controller? I assume 
> both the KA and KI had DECtapes, as well as the PDP-6.
>
>> Block 100 is the directory block.  Thus 574 blocks for user data. The
>> directory holds up to 22 files, plus a map of which file owns each 
>> block.
>>
>> The user data blocks have a one word header (LH = next block of file; RH
>> = first block & words used in this block) + 127 words of payload.  This
>> differed from disk files, where all 128 words were payload, so
>> inattentive programmers could make a number of mistakes.  (E.g. random
>> access block isn't word/128; you had to pay attention to the buffer's
>> word count, etc.)
>>
>> Data blocks of a file are (usually) not contiguous; this allowed the
>> drive to stop and restart while reading or writing without having to
>> reverse direction.  The spacing depended on what blocks were free when
>> files were written, and the data mode.  (Files written in 'core dump'
>> modes were assumed to be read by the monitor without stopping, so the
>> gap was smaller, allowing larger programs to be read without reversing
>> direction.)
>>
>> The gory details of the format are in the Monitor Calls manual 
>> (TOPS-10).
>
> TOPS-10 DECtape format is definitely not something I know anything 
> about. But thanks for the rundown.
>
>> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
>> (except when reading PDP-10 tapes; the hardware for that was tricky as
>> the high bits had to be read with programmed IO; the low 16 were DMAed
>> on the TC-11.)
>
> Yes! Thanks for bringing another murky memory.
>
>> The low-level formatting that established the mark track, end zones and
>> block delimiters was done via a stand-alone diagnostic. This differs
>> between the two formats.  The directory block could be initialized under
>> timesharing.
>
> Um? What two formats?
>
>> Directory structure given is for the PDP-10; other OSs used different
>> formats.
>>
>>  From an emulation point of view, the PDP-10's controller was the most
>> interesting; the driver does dead reckoning; that is, it will start a
>> drive spinning for a seek, disconnect, service other drives, and
>> reconnect just before the desired block is expected to be over the read
>> head.  So real-world timing matters.  The other controllers (and thus
>> OSs) didn't support this.
>
> Wow. The TC08 actually did seeks while actually looking at the tape, 
> and then did DMA as well. So you didn't have to pay any more attention 
> than to a disk controller.
> Essentially, you asked it to seek, and it indicated when the seek was 
> done. You asked it to read, and it read.
> As far as I can remember, the TC11 is the same.
> Not sure what you mean by "other controllers didn't support this". 
> What is "this". Doing dead reckoning? Why would you actually want to 
> do dead reckoning. It makes much more sense to actually look at the 
> tape the whole time it is spinning by, and not only when you are 
> getting close to where you want to be. And the hardware can do that 
> without your involvement.
>
> In a way, however, I'd say that the TD8E is the most "interesting" 
> controller to emulate, since it is so incredibly stupid that you 
> actually have to emulate the low level format of the tape for that 
> controller to work.
> It is truly ugly. And that controller was a headache if you ever 
> wanted to use it in a timesharing operating system, since it did not 
> do DMA, it did not really do seeks, or in fact anything at all except 
> just feed the bits from the tape to the computer as they whizzed by.
>
>> Oh, all numbers above are radix 10.
>
> What's wrong with you. ;-)
>
>> The link for OS8 that I posted yesterday was via filewatcher; the direct
>> link
>> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
>> Sorry if this was confusing.
>>
>> Of potential interest to low-level folks is
>> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 
>>
>>
>> Hope this is useful.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>
> Thanks for all the interesting bits and pieces.
>
>     Johnny
>
>>
>> On 18-Mar-13 16:26, Johnny Billquist wrote:
>>> On 2013-03-18 17:44, Bob Supnik wrote:
>>>> I was trying to get a debug setup for PIP10, per Ian King's mail, 
>>>> when I
>>>> discovered that none of my OS/8 images have PIP10 on them. This
>>>> certainly explains why the feature has never been tested before. I
>>>> suspect that ReadAll and WriteAll either are not working at all, or 
>>>> are
>>>> not working when the DECtape format is 18b. Another possibility is 
>>>> that
>>>> PDP-10 DECtape format is not the same as 18b format, at the 
>>>> nitty-gritty
>>>> level (format of headers and trailers).
>>>
>>> The DECtape format as such, with all the headers and so on, is the
>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>> have 128 18-bit words (if I remember right).
>>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>>> that is rather different from an 18-bit machine. But at the tape as
>>> such, there is nothing odd about it.
>>>
>>> But I can see lots of potential for errors when emulating this whole
>>> thing.
>>>
>>> I couldn't give exact details on lots of bits without looking in
>>> manuals, but in essence a DECtape is always doing 18-bit words. That
>>> is done by doing 6 groups of 3 bits each.
>>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>>> So the blocks are shorter, but you have more of them, when the tape is
>>> formatted for a PDP-8.
>>>
>>> I hope (assume) that you already know all of this. If not, let me
>>> know, and I can try helping out some more.
>>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>>> ago, which is when I actually had to dig rather deep into all of this.
>>> PIP10 was one of the things I really looked into. But since my tapes
>>> had actually been written on a PDP-15, I had to write my own code in
>>> the end, to just dump the raw data.
>>>
>>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>>> somewhere (like Mediafire) and let me know by email.
>>>
>>> I think someone already posted this, but I know I have that software,
>>> including sources (if I remember right) somewhere. Let me know if it
>>> can't be located anywhere else.
>>>
>>>     Johnny
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/ded201e5/attachment.bin>

From michael.mondy at coffeebird.net  Tue Mar 19 10:36:38 2013
From: michael.mondy at coffeebird.net (Michael Mondy)
Date: Tue, 19 Mar 2013 09:36:38 -0500
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <51486B6E.7080304@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se>
Message-ID: <20130319143638.GA31395@coffeebird.net>

On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> [ ... ]
> 
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many
> comments on why other word lengths were more popular. I've seen
> mentioned that floating point formats was pretty nice to do with
> something like 60 or 72 bits. Reason being that you had large enough
> exponents for useful things, and enough precision for most
> calculations.
> So a word length that related to this made sense.
> 
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> 
> 	Johnny

Wikipedia has an article on 36-bit computing: http://en.wikipedia.org/wiki/36-bit

Snipped from the wikipedia article:

[ ... ]

Many early computers aimed at the scientific market had a 36-bit word length. This word length was just long enough to represent positive and negative integers to an accuracy of ten decimal digits (35 bits would have been the minimum). It also allowed the storage of six alphanumeric characters encoded in a six-bit character encoding. Prior to the introduction of computers, the state of the art in precision scientific and engineering calculation was the ten-digit, electrically powered, mechanical calculator, such as those manufactured by Friden, Marchant and Monroe. These calculators had a column of keys for each digit and operators were trained to use all their fingers when entering numbers, so while some specialized calculators had more columns, ten was a practical limit. Computers, as the new competitor, had to match that accuracy. Decimal computers sold in that era, such as the IBM 650 and the IBM 7070, had a word length of ten digits, as did ENIAC, one of the earliest computers.

[ ... ]

By the time IBM introduced System/360, scientific calculations had shifted to floating point and mechanical calculators were no longer a competitor. [...]  [ At which point the advantages of using powers of two became more important than feature parity with mechanical calculators. ]

-- Mike

From bob at jfcl.com  Tue Mar 19 10:51:15 2013
From: bob at jfcl.com (Bob Armstrong)
Date: Tue, 19 Mar 2013 07:51:15 -0700
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <006001ce24b1$353eea10$9fbcbe30$@com>

>By the time IBM introduced System/360, scientific calculations had shifted
>to floating point and mechanical calculators were no longer a competitor. 

  ... but the PDP-6 and the S/360 are roughly contemporary - both were
introduced around 1964.  I guess IBM was more forward thinking than DEC was
at the time :-)

  Of course DEC had a prior history with 18 bit computers, so I'm sure 36
seemed like a more natural choice.

Bob Armstrong




From bob at supnik.org  Tue Mar 19 11:25:56 2013
From: bob at supnik.org (Bob Supnik)
Date: Tue, 19 Mar 2013 11:25:56 -0400
Subject: [Simh] DECtape format(s)
Message-ID: <51488384.90401@supnik.org>

As was mentioned, DECtape formats are very much the same at the hardware 
level, but the block size does vary.

Block header format, all controllers except Type 55x, in 18b words:

word 0 - 0
word 1 - forward block number
words 2,3 - 0
word 4 - reverse checksum (077)

Block trailer format, all controllers except Type 550/555, in 18b words:

word 0 - forward checksum (one's complement of XOR of each 6b data frame)
words 1,2 - 0
word 3 - reverse block number (complement obverse of block # if read 
forward)
word 4 - 0

The ringer is the Type 55x controllers, which was used in the PDP-1, 4, 
5, 6, 7. The checksum format varied from unit to unit. Some used parity 
checking (XOR); others (like the 7) relied on software and used one's 
complement arithmetic. The reverse checksum was always 0777777 (-0). 
Further, the first five Type 550's had only four word headers.

So "modern" (TC series) DECtapes are all interchangeable. However, 
ancient DECtapes from before 1966 will require unique handling.

/Bob







From oboguev at yahoo.com  Tue Mar 19 12:27:02 2013
From: oboguev at yahoo.com (Sergey Oboguev)
Date: Tue, 19 Mar 2013 09:27:02 -0700 (PDT)
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <1363710422.62699.YahooMailRC@web184306.mail.ne1.yahoo.com>

My very first computer as a kid was a 37-bit computer we had at school, which I 
reckon must be considered superior to 36-bit computers.




________________________________
From: Michael Mondy <michael.mondy at coffeebird.net>
To: simh at trailing-edge.com
Sent: Tue, March 19, 2013 7:39:07 AM
Subject: [Simh] Why 36-bit computing?

On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> [ ... ]
> 
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many
> comments on why other word lengths were more popular. I've seen
> mentioned that floating point formats was pretty nice to do with
> something like 60 or 72 bits. Reason being that you had large enough
> exponents for useful things, and enough precision for most
> calculations.
> So a word length that related to this made sense.
> 
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> 
>     Johnny

Wikipedia has an article on 36-bit computing: 
http://en.wikipedia.org/wiki/36-bit

Snipped from the wikipedia article:

[ ... ]

Many early computers aimed at the scientific market had a 36-bit word length. 
This word length was just long enough to represent positive and negative 
integers to an accuracy of ten decimal digits (35 bits would have been the 
minimum). It also allowed the storage of six alphanumeric characters encoded in 
a six-bit character encoding. Prior to the introduction of computers, the state 
of the art in precision scientific and engineering calculation was the 
ten-digit, electrically powered, mechanical calculator, such as those 
manufactured by Friden, Marchant and Monroe. These calculators had a column of 
keys for each digit and operators were trained to use all their fingers when 
entering numbers, so while some specialized calculators had more columns, ten 
was a practical limit. Computers, as the new competitor, had to match that 
accuracy. Decimal computers sold in that era, such as the IBM 650 and the IBM 
7070, had a word length of ten digits, as did ENIAC, one of the earliest 
computers.

[ ... ]

By the time IBM introduced System/360, scientific calculations had shifted to 
floating point and mechanical calculators were no longer a competitor. [...]  [ 
At which point the advantages of using powers of two became more important than 
feature parity with mechanical calculators. ]

-- Mike
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/cee2d447/attachment.html>

From IanK at vulcan.com  Tue Mar 19 15:04:44 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 19 Mar 2013 19:04:44 +0000
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>

> -----Original Message-----
> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh at trailing-edge.com
> Subject: [Simh] Why 36-bit computing?
> 
> On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> > [ ... ]
> >
> > It wasn't just DEC. Back in the day, most everyone used various word
> > lengths that wasn't a power of two. I can't really make many comments
> > on why other word lengths were more popular. I've seen mentioned that
> > floating point formats was pretty nice to do with something like 60 or
> > 72 bits. Reason being that you had large enough exponents for useful
> > things, and enough precision for most calculations.
> > So a word length that related to this made sense.
> >
> > Number of bits being a power of two started with IBM in the 60s, and
> > became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> >
> > 	Johnny
> 
> Wikipedia has an article on 36-bit computing:
> http://en.wikipedia.org/wiki/36-bit
> 
> Snipped from the wikipedia article:
> 
> [ ... ]
> 
> Many early computers aimed at the scientific market had a 36-bit word
> length. This word length was just long enough to represent positive and
> negative integers to an accuracy of ten decimal digits (35 bits would have
> been the minimum). It also allowed the storage of six alphanumeric
> characters encoded in a six-bit character encoding. Prior to the introduction
> of computers, the state of the art in precision scientific and engineering
> calculation was the ten-digit, electrically powered, mechanical calculator,
> such as those manufactured by Friden, Marchant and Monroe. These
> calculators had a column of keys for each digit and operators were trained to
> use all their fingers when entering numbers, so while some specialized
> calculators had more columns, ten was a practical limit. Computers, as the
> new competitor, had to match that accuracy. Decimal computers sold in that
> era, such as the IBM 650 and the IBM 7070, had a word length of ten digits, as
> did ENIAC, one of the earliest com  puters.
> 
> [ ... ]
> 
> By the time IBM introduced System/360, scientific calculations had shifted to
> floating point and mechanical calculators were no longer a competitor. [...]  [
> At which point the advantages of using powers of two became more
> important than feature parity with mechanical calculators. ]
> 

The following is from a biography of Fred Brooks, the project manager for the IBM 360, on UNC-Chapel Hill's Computer Science department website (http://www.cs.unc.edu/cms/our-people/faculty/frederick-p.-brooks-jr): 

"In 1957, Dr. Brooks and Dura Sweeney invented a Stretch interrupt system that introduced most features of today's interrupt systems. Dr. Brooks coined the term computer architecture. His system/360 team first achieved strict compatibility, upward and downward, in a computer family. His early concern for word processing led to his selection of the 8-bit byte and the lowercase alphabet for the System/360, engineering of many new 8-bit input/output devices, and providing a character-string datatype in PL/I."

Keep in mind that the S/360 was not only targeted for scientific computation.  It was intended to consolidate IBM's customer bases.  -- Ian 


From bqt at softjar.se  Tue Mar 19 16:27:20 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 21:27:20 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486E72.4010508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org> <51486745.3010802@softjar.se>
 <51486E72.4010508@ieee.org>
Message-ID: <5148CA28.5090909@softjar.se>

On 2013-03-19 14:56, Timothe Litt wrote:
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> Consider a timesharing system, with 4 users each trying to transfer from
> their own DTA.  With a TC11, you serviced user 1, user, 3, user 4, user
> 2 sequentially.   The controller was tied up for the whole seek for each
> user - potentially from one end of the tape to the other.

Oh. You are talking about overlapped seeks. I thought you meant 
something else.

I just checked the TC01 controller (for the PDP-8) and it certainly can 
do this too. But you need to programatically time things in this case, 
to go back to the drive when you think it is getting close, and start 
fiddling. Also checked the TC11, and it too can run several tape units, 
as long as you reselect the tape drive when you think you actually want 
to start doing any operations. Both can have tapes continue to run in 
either direction while doing operations on another tape.
Sounds like exactly the same deal as with the TD10.

The TD8E, which I mentioned being the most stupid controller on earth, 
requires this solution all the time, as there is no actual seek, nor is 
there any DMA. You either poll the controller all the time, or else you 
setup a time interrupt when you think it is appropriate to start polling.
(Of course, OS/8 just polls the darn tape the whole time...)

> The TD10-'s dead reckoning allowed  the seeks to proceed in parallel.
> E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by
> the controller.  When the shortest seek was near completion, the driver
> would tell the controller to pay attention to that drive ('connect'), do
> the transfer, and stop.  Then the next.  Besides being impressive to
> watch (8 drives spinning in various directions), the user request
> latency was reduced.   (Some systems had two controllers, for 16 drives!)

I don't know if any driver for any PDP8 OS, or PDP11 OS ever did 
overlapped seeks, but the hardware can definitely do it.
The one OS I can tell about is RSX, and it did not support overlapped 
seeks on TC11. (And of course I know OS/8, but the answer there is that 
nothing ever did overlapped seeks on anything, since all I/O was polled 
anyway.)

> The KA, KI and KL (with the IO Bus adapter) all used the TD10
> controller.  The -6 had another controller - type 551.  I think it was a
> dumb controller, but didn't use it personally.

Ok.

> 129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats. Gory
> details of the TD10 are at

Oh. You just meant the number of bits in a block. Well, you can do any 
size you want, just as you can do any number of blocks you want, withing 
physical limits, and probably some other restrictions that I can't think 
of right now.

> Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the
> format info I provided was for the 10.  TOPS-10.  MAC had another format
> for the -6.  TOPS-20 didn't officially support DECtapes, but internally
> we had systems with them.  They used the PDP-10 format.

Makes sense.
Anyway, yes, PIP10 would parse the format you described, once it 
actually manages to read the blocks. That is the tricky detail that 
seems to not be working...

> Much of the pdp-10 format documentation is a mixture of octal and
> decimal.  I picked decimal because these days, thinking in octal is a
> (mostly) lost art.

:-)

> IBM and many other vendors used 36-bits, because the (BCD) character
> codes of the day were 6-bits, so it packed nicely.  The -8 was 12 bits
> for the same reason, only it was cheaper to build.

I don't know how much the PDP-8 (or rather, PDP-5) was 12 bits because 
of any BCD issues. But it was cheap.

> The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii,
> 8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.

I know. The PDP-10 is a nice architecture.

> The -11 was designed after 8-bit character codes became popular. EBCDIC
> was (and is) an ugly mess; ASCII cemented 8-bit character codes.  And
> machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the
> most popular.

I can only agree about EBCDIC. ASCII wasn't really 8-bit though. But 
7-bit is close enough.

	Johnny

>
> On 19-Mar-13 09:25, Johnny Billquist wrote:
>> On 2013-03-19 14:03, Timothe Litt wrote:
>>>> The DECtape format as such, with all the headers and so on, is the
>>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>>> have 128 18-bit words (if I remember right).
>>> Pretty much right.  129 may be slightly misleading.  The format is 129,
>>> but the -8 used  only 128 of the 129 12-bit words/block for data.
>>
>> Right. :-)
>>
>>> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
>>> formatted DECtape would have 578 blocks of 128 36-bit words. (256
>>> 18-bit words at the hardware level.)
>>
>> I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape
>> as such, which physically always stores 18 bits. A PDP-10 would
>> obviously store its 36-bit words using two DECtape words. Any 18-bit
>> machine is straight forward, while the PDP-11 (as you mention below)
>> only use 16 bits of the 18-bit word.
>>
>> I thought it was 128 18-bit words, but I may well remember that wrong,
>> and the "normal" format is 256 18-bit words. Makes sense, when I think
>> about it.
>>
>> The number of blocks is not absolutely fixed, but 578 is the
>> "standard" except on the PDP-8, I guess.
>>
>>> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
>>> contain user data.
>>
>> That would be very depending on which machine we're talking about, and
>> which controller... :-) But I assume you're talking about the PDP-10
>> here. Did all PDP-10 with DECtapes use the same controller? I assume
>> both the KA and KI had DECtapes, as well as the PDP-6.
>>
>>> Block 100 is the directory block.  Thus 574 blocks for user data. The
>>> directory holds up to 22 files, plus a map of which file owns each
>>> block.
>>>
>>> The user data blocks have a one word header (LH = next block of file; RH
>>> = first block & words used in this block) + 127 words of payload.  This
>>> differed from disk files, where all 128 words were payload, so
>>> inattentive programmers could make a number of mistakes.  (E.g. random
>>> access block isn't word/128; you had to pay attention to the buffer's
>>> word count, etc.)
>>>
>>> Data blocks of a file are (usually) not contiguous; this allowed the
>>> drive to stop and restart while reading or writing without having to
>>> reverse direction.  The spacing depended on what blocks were free when
>>> files were written, and the data mode.  (Files written in 'core dump'
>>> modes were assumed to be read by the monitor without stopping, so the
>>> gap was smaller, allowing larger programs to be read without reversing
>>> direction.)
>>>
>>> The gory details of the format are in the Monitor Calls manual
>>> (TOPS-10).
>>
>> TOPS-10 DECtape format is definitely not something I know anything
>> about. But thanks for the rundown.
>>
>>> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
>>> (except when reading PDP-10 tapes; the hardware for that was tricky as
>>> the high bits had to be read with programmed IO; the low 16 were DMAed
>>> on the TC-11.)
>>
>> Yes! Thanks for bringing another murky memory.
>>
>>> The low-level formatting that established the mark track, end zones and
>>> block delimiters was done via a stand-alone diagnostic. This differs
>>> between the two formats.  The directory block could be initialized under
>>> timesharing.
>>
>> Um? What two formats?
>>
>>> Directory structure given is for the PDP-10; other OSs used different
>>> formats.
>>>
>>>  From an emulation point of view, the PDP-10's controller was the most
>>> interesting; the driver does dead reckoning; that is, it will start a
>>> drive spinning for a seek, disconnect, service other drives, and
>>> reconnect just before the desired block is expected to be over the read
>>> head.  So real-world timing matters.  The other controllers (and thus
>>> OSs) didn't support this.
>>
>> Wow. The TC08 actually did seeks while actually looking at the tape,
>> and then did DMA as well. So you didn't have to pay any more attention
>> than to a disk controller.
>> Essentially, you asked it to seek, and it indicated when the seek was
>> done. You asked it to read, and it read.
>> As far as I can remember, the TC11 is the same.
>> Not sure what you mean by "other controllers didn't support this".
>> What is "this". Doing dead reckoning? Why would you actually want to
>> do dead reckoning. It makes much more sense to actually look at the
>> tape the whole time it is spinning by, and not only when you are
>> getting close to where you want to be. And the hardware can do that
>> without your involvement.
>>
>> In a way, however, I'd say that the TD8E is the most "interesting"
>> controller to emulate, since it is so incredibly stupid that you
>> actually have to emulate the low level format of the tape for that
>> controller to work.
>> It is truly ugly. And that controller was a headache if you ever
>> wanted to use it in a timesharing operating system, since it did not
>> do DMA, it did not really do seeks, or in fact anything at all except
>> just feed the bits from the tape to the computer as they whizzed by.
>>
>>> Oh, all numbers above are radix 10.
>>
>> What's wrong with you. ;-)
>>
>>> The link for OS8 that I posted yesterday was via filewatcher; the direct
>>> link
>>> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
>>> Sorry if this was confusing.
>>>
>>> Of potential interest to low-level folks is
>>> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>>>
>>>
>>> Hope this is useful.
>>>
>>> This communication may not represent my employer's views,
>>> if any, on the matters discussed.
>>
>> Thanks for all the interesting bits and pieces.
>>
>>     Johnny
>>
>>>
>>> On 18-Mar-13 16:26, Johnny Billquist wrote:
>>>> On 2013-03-18 17:44, Bob Supnik wrote:
>>>>> I was trying to get a debug setup for PIP10, per Ian King's mail,
>>>>> when I
>>>>> discovered that none of my OS/8 images have PIP10 on them. This
>>>>> certainly explains why the feature has never been tested before. I
>>>>> suspect that ReadAll and WriteAll either are not working at all, or
>>>>> are
>>>>> not working when the DECtape format is 18b. Another possibility is
>>>>> that
>>>>> PDP-10 DECtape format is not the same as 18b format, at the
>>>>> nitty-gritty
>>>>> level (format of headers and trailers).
>>>>
>>>> The DECtape format as such, with all the headers and so on, is the
>>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>>> have 128 18-bit words (if I remember right).
>>>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>>>> that is rather different from an 18-bit machine. But at the tape as
>>>> such, there is nothing odd about it.
>>>>
>>>> But I can see lots of potential for errors when emulating this whole
>>>> thing.
>>>>
>>>> I couldn't give exact details on lots of bits without looking in
>>>> manuals, but in essence a DECtape is always doing 18-bit words. That
>>>> is done by doing 6 groups of 3 bits each.
>>>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>>>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>>>> So the blocks are shorter, but you have more of them, when the tape is
>>>> formatted for a PDP-8.
>>>>
>>>> I hope (assume) that you already know all of this. If not, let me
>>>> know, and I can try helping out some more.
>>>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>>>> ago, which is when I actually had to dig rather deep into all of this.
>>>> PIP10 was one of the things I really looked into. But since my tapes
>>>> had actually been written on a PDP-15, I had to write my own code in
>>>> the end, to just dump the raw data.
>>>>
>>>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>>>> somewhere (like Mediafire) and let me know by email.
>>>>
>>>> I think someone already posted this, but I know I have that software,
>>>> including sources (if I remember right) somewhere. Let me know if it
>>>> can't be located anywhere else.
>>>>
>>>>     Johnny
>>>>
>>>> _______________________________________________
>>>> Simh mailing list
>>>> Simh at trailing-edge.com
>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>
>>
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


From davel.rss at googlemail.com  Tue Mar 19 17:37:54 2013
From: davel.rss at googlemail.com (Dave L)
Date: Tue, 19 Mar 2013 21:37:54 -0000
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
 <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>
Message-ID: <015601ce24ea$048dc470$0da94d50$@gmail.com>

As I recall from way back, wasn't the 36 bit potentially split into 32-bit
data and 4 bit offset to allow fast jump to the next "card" in the deck on a
branch? Not that (m)any implemented this, but I seem to recall this from my
early days back at ADP 30+ years ago. With the advent of fast memory and
disk drives this effectively became unnecessary but mainframe architecture
took a while to adjust.

Dave

-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com]
On Behalf Of Ian King
Sent: 19 March 2013 19:05
To: simh at trailing-edge.com
Subject: Re: [Simh] Why 36-bit computing?

> -----Original Message-----
> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- 
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh at trailing-edge.com
> Subject: [Simh] Why 36-bit computing?
> 
> On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> > [ ... ]
> >
> > It wasn't just DEC. Back in the day, most everyone used various word 
> > lengths that wasn't a power of two. I can't really make many 
> > comments on why other word lengths were more popular. I've seen 
> > mentioned that floating point formats was pretty nice to do with 
> > something like 60 or
> > 72 bits. Reason being that you had large enough exponents for useful 
> > things, and enough precision for most calculations.
> > So a word length that related to this made sense.
> >
> > Number of bits being a power of two started with IBM in the 60s, and 
> > became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> >
> > 	Johnny
> 
> Wikipedia has an article on 36-bit computing:
> http://en.wikipedia.org/wiki/36-bit
> 
> Snipped from the wikipedia article:
> 
> [ ... ]
> 
> Many early computers aimed at the scientific market had a 36-bit word 
> length. This word length was just long enough to represent positive 
> and negative integers to an accuracy of ten decimal digits (35 bits 
> would have been the minimum). It also allowed the storage of six 
> alphanumeric characters encoded in a six-bit character encoding. Prior 
> to the introduction of computers, the state of the art in precision 
> scientific and engineering calculation was the ten-digit, electrically 
> powered, mechanical calculator, such as those manufactured by Friden, 
> Marchant and Monroe. These calculators had a column of keys for each 
> digit and operators were trained to use all their fingers when 
> entering numbers, so while some specialized calculators had more 
> columns, ten was a practical limit. Computers, as the new competitor, 
> had to match that accuracy. Decimal computers sold in that era, such 
> as the IBM 650 and the IBM 7070, had a word length of ten digits, as did
ENIAC, one of the earliest com  puters.
> 
> [ ... ]
> 
> By the time IBM introduced System/360, scientific calculations had 
> shifted to floating point and mechanical calculators were no longer a 
> competitor. [...]  [ At which point the advantages of using powers of 
> two became more important than feature parity with mechanical 
> calculators. ]
> 

The following is from a biography of Fred Brooks, the project manager for
the IBM 360, on UNC-Chapel Hill's Computer Science department website
(http://www.cs.unc.edu/cms/our-people/faculty/frederick-p.-brooks-jr): 

"In 1957, Dr. Brooks and Dura Sweeney invented a Stretch interrupt system
that introduced most features of today's interrupt systems. Dr. Brooks
coined the term computer architecture. His system/360 team first achieved
strict compatibility, upward and downward, in a computer family. His early
concern for word processing led to his selection of the 8-bit byte and the
lowercase alphabet for the System/360, engineering of many new 8-bit
input/output devices, and providing a character-string datatype in PL/I."


Keep in mind that the S/360 was not only targeted for scientific
computation.  It was intended to consolidate IBM's customer bases.  -- Ian 

_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh


From toby at telegraphics.com.au  Tue Mar 19 22:27:48 2013
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 19 Mar 2013 22:27:48 -0400
Subject: [Simh] Non-2^n architectures - Re:  PIP10 on PDP-8 SIM
In-Reply-To: <51486B6E.7080304@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se>
Message-ID: <51491EA4.20708@telegraphics.com.au>

On 19/03/13 9:43 AM, Johnny Billquist wrote:
> On 2013-03-19 14:30, Armistead, Jason wrote:
>> I had trouble with Timothe?s link to the USPTO, but found this same
>> patent in PDF form at
>>
>> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>>
>> As a relative newbie who started my serious journey into computing with
>> an Apple ][ I?ve never fully understood DEC?s fascination with word
>> lengths that weren?t multiples of 2 ...
>
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many comments on
> why other word lengths were more popular.

12, 15, 18, 36, 60 ...

24 is still common in DSPs (and maybe 48 and 56?) - and even word 
addressing is still used.

 >  I've seen mentioned that
> floating point formats was pretty nice to do with something like 60 or
> 72 bits. Reason being that you had large enough exponents for useful
> things, and enough precision for most calculations.
> So a word length that related to this made sense.
>
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)



And, not insignificantly, the rise of 8-bit microprocessors.

(Though octal was still standard notation for addresses and many 
constants on PDP-11, hence C's octal literals.)

--Toby

>
> Johnny
>


From radioengr at gmail.com  Tue Mar 19 23:21:43 2013
From: radioengr at gmail.com (Rob Doyle)
Date: Tue, 19 Mar 2013 20:21:43 -0700
Subject: [Simh] Non-2^n architectures - Re:  PIP10 on PDP-8 SIM
In-Reply-To: <51491EA4.20708@telegraphics.com.au>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <51491EA4.20708@telegraphics.com.au>
Message-ID: <51492B47.70100@gmail.com>

On 3/19/2013 7:27 PM, Toby Thain wrote:
> On 19/03/13 9:43 AM, Johnny Billquist wrote:
>> On 2013-03-19 14:30, Armistead, Jason wrote:
>>> I had trouble with Timothe?s link to the USPTO, but found this
>>> same patent in PDF form at
>>>
>>> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>>>
>>> As a relative newbie who started my serious journey into
>>> computing with an Apple ][ I?ve never fully understood DEC?s
>>> fascination with word lengths that weren?t multiples of 2 ...
>>
>> It wasn't just DEC. Back in the day, most everyone used various
>> word lengths that wasn't a power of two. I can't really make many
>> comments on why other word lengths were more popular.
>
> 12, 15, 18, 36, 60 ...
>
> 24 is still common in DSPs (and maybe 48 and 56?) - and even word
> addressing is still used.

24-bit data is common for cost sensitive audio applications because
16-bit data is insufficient and 32-bit data is overkill.

GPUs typically have odd data widths for similar reasons.

In these types of applications, the notion of 8-bit bytes is mostly
irrelevant. As stated above, many of these devices can't even address
bytes. Interestingly enough, none of these /limitations/ preclude having
a compliant "C" compiler.

>> I've seen mentioned that floating point formats was pretty nice to
>> do with something like 60 or 72 bits. Reason being that you had
>> large enough exponents for useful things, and enough precision for
>> most calculations. So a word length that related to this made
>> sense.
>>
>> Number of bits being a power of two started with IBM in the 60s,
>> and became common with the PDP-11 in the 70s. (Or so I'd like to
>> think.)
>
>
>
> And, not insignificantly, the rise of 8-bit microprocessors.
>
> (Though octal was still standard notation for addresses and many
> constants on PDP-11, hence C's octal literals.)
>
> --Toby
>
>>
>> Johnny
>>
>
> _______________________________________________ Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


From bob at supnik.org  Wed Mar 20 18:05:12 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 20 Mar 2013 18:05:12 -0400
Subject: [Simh] PIP10
Message-ID: <514A3298.5010508@supnik.org>

I tried running PIP10 from the image Ian was using.

If the simulator is configured for a TC08, it hangs. It is in a loop 
doing IOT 773/JMP .-1, which is a TD8E IOT.

If the simulator is configured for a TD8E, it returns an error. I tried 
DTA0:/Z and got OUTPUT FILE OPEN ERROR.

So the first issue is that PIP10's logic for telling which DECtape 
controller is present uses some feature that the simulator is doing 
incorrectly.

The second issue is what happens beyond that point.

/Bob

From litt at ieee.org  Wed Mar 20 19:13:37 2013
From: litt at ieee.org (Timothe Litt)
Date: Wed, 20 Mar 2013 19:13:37 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A3298.5010508@supnik.org>
References: <514A3298.5010508@supnik.org>
Message-ID: <514A42A1.4010600@ieee.org>

The logic doesn't seem to be in PIP10; PIP10 uses the DCB devtype field 
to decide if it has a DECtape, and if so, which controller.

See 
ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/os8.v3d/sources/system/dectapes/dectape7/pip10.pa 
for PIP10, and table 33 
inhttp://www.grc.com/pdp-8/docs/OS8_System_Reference_Manual.pdf 
<http://www.grc.com/pdp-8/docs/OS8_System_Reference_Manual.pdf>for the 
DCB breakdown.  I'm not an OS8 expert, but I think the DCB is setup by 
CONFIG.

Relevant snippets:

DCB=7760 /DEVICE CONTROL BLOCK (FIELD 1)

DVTYPE, 0 /DEVICE TYPE HOLDER

JMS GTDVTP /COMPARE DCB ENTRY WITH TC08 OR TD8E
SZA CLA
JMP CDIN3 /NOT DECTAPE

GTDVTP, 0
TAD (DCB-1
DCA TEMP1
CDF 10
TAD I TEMP1 /GET DCB ENTRY
CDF
DCA DVTYPE
TAD DVTYPE
AND (770
TAD (-210
SZA
TAD (30
JMP I GTDVTP



This communication may not represent my employer's views,
if any, on the matters discussed.

On 20-Mar-13 18:05, Bob Supnik wrote:
> I tried running PIP10 from the image Ian was using.
>
> If the simulator is configured for a TC08, it hangs. It is in a loop 
> doing IOT 773/JMP .-1, which is a TD8E IOT.
>
> If the simulator is configured for a TD8E, it returns an error. I 
> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>
> So the first issue is that PIP10's logic for telling which DECtape 
> controller is present uses some feature that the simulator is doing 
> incorrectly.
>
> The second issue is what happens beyond that point.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/6f0e8951/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/6f0e8951/attachment-0001.bin>

From litt at ieee.org  Wed Mar 20 20:03:38 2013
From: litt at ieee.org (Timothe Litt)
Date: Wed, 20 Mar 2013 20:03:38 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A3298.5010508@supnik.org>
References: <514A3298.5010508@supnik.org>
Message-ID: <514A4E5A.7090206@ieee.org>

Meant to include the code that uses DVTYPE and actually picks the type 
in my earlier note.  Sorry.

If I had to make a random guess, look at the microprogrammed operate 
codes, e.g SNA CLA; CLL CML RTR;

SETUNT, 0
STL
TAD (-7607
SZA /IF IT IS 7607,
TAD (7 /ITS UNIT 0
AND (7
CLL CML RTR
RTR
DCA UNIT10
TAD DVTYPE
AND (10
SNA CLA
JMP I SETUNT /TC08 - FINISHED
CLL
TAD UNIT10
AND (7000 /TD8E ENTRY POINTS ARE STRANGE -
TAD UNIT10 /MUST ROTATE UNIT NUMBER LEFT 1
SZL
TAD (1000
DCA UNIT10
JMS I (TDUSET /SET UP TD8E OPCODES
JMP I SETUNT

This communication may not represent my employer's views,
if any, on the matters discussed.

On 20-Mar-13 18:05, Bob Supnik wrote:
> I tried running PIP10 from the image Ian was using.
>
> If the simulator is configured for a TC08, it hangs. It is in a loop 
> doing IOT 773/JMP .-1, which is a TD8E IOT.
>
> If the simulator is configured for a TD8E, it returns an error. I 
> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>
> So the first issue is that PIP10's logic for telling which DECtape 
> controller is present uses some feature that the simulator is doing 
> incorrectly.
>
> The second issue is what happens beyond that point.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/4a5bcc2c/attachment.bin>

From bob at supnik.org  Wed Mar 20 21:07:34 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 20 Mar 2013 21:07:34 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A4E5A.7090206@ieee.org>
References: <514A3298.5010508@supnik.org> <514A4E5A.7090206@ieee.org>
Message-ID: <514A5D56.30100@supnik.org>

Thanks, Tim. That means the OS/8 image Ian and I are using is configured 
for a TD8E, so I'll debug that code path. It's more difficult, because 
the DECtape emulator has to provide an accurate emulation of the mark 
track, and I could easily have it wrong in 16b- or 18b- mode. (The TD8E 
does run OS/8, so it's probably okay in 12b mode.)

/Bob

On 3/20/2013 8:03 PM, Timothe Litt wrote:
> Meant to include the code that uses DVTYPE and actually picks the type 
> in my earlier note.  Sorry.
>
> If I had to make a random guess, look at the microprogrammed operate 
> codes, e.g SNA CLA; CLL CML RTR;
>
> SETUNT, 0
> STL
> TAD (-7607
> SZA /IF IT IS 7607,
> TAD (7 /ITS UNIT 0
> AND (7
> CLL CML RTR
> RTR
> DCA UNIT10
> TAD DVTYPE
> AND (10
> SNA CLA
> JMP I SETUNT /TC08 - FINISHED
> CLL
> TAD UNIT10
> AND (7000 /TD8E ENTRY POINTS ARE STRANGE -
> TAD UNIT10 /MUST ROTATE UNIT NUMBER LEFT 1
> SZL
> TAD (1000
> DCA UNIT10
> JMS I (TDUSET /SET UP TD8E OPCODES
> JMP I SETUNT
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 20-Mar-13 18:05, Bob Supnik wrote:
>> I tried running PIP10 from the image Ian was using.
>>
>> If the simulator is configured for a TC08, it hangs. It is in a loop 
>> doing IOT 773/JMP .-1, which is a TD8E IOT.
>>
>> If the simulator is configured for a TD8E, it returns an error. I 
>> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>>
>> So the first issue is that PIP10's logic for telling which DECtape 
>> controller is present uses some feature that the simulator is doing 
>> incorrectly.
>>
>> The second issue is what happens beyond that point.
>>
>> /Bob
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>


From Jason.Armistead at otis.com  Thu Mar 21 09:55:18 2013
From: Jason.Armistead at otis.com (Armistead, Jason)
Date: Thu, 21 Mar 2013 13:55:18 +0000
Subject: [Simh] Formally documenting PDP tape drive behavior (and other
 facets of SIMH and the systems it emulates)
Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>

There has been a lot of interesting discussion about tape drives on PDP systems in the last week or so.  It's great to hear those familiar with the inner workings of these devices, or with access to the manuals, share their wisdom.

One question though - after the "old timers" are gone, would a newbie to SIMH be able to figure these same things out ?

Or, in other words, do the accompanying comments in the code and the SIMH documentation adequately capture the "nuggets" of the conversations that take place on this list ?  And do we provide enough in the way of "breadcrumbs" to allow a newbie to re-discover this same information ?

Capturing this knowledge is a hard thing to do, and with retrocomputing we are presently at a point in time where we can still rely on folks who designed, built, tested, operated and programmed these systems, and in some cases they still even have running systems available for experimentation and measurement.  But what happens when that is no longer the case ?

Just food for thought ... let's make sure SIMH and its fellow emulators like MAME / MESS can still be enjoyed and understood by future generations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130321/9fd93c6f/attachment.html>

From dott.piergiorgio at fastwebnet.it  Thu Mar 21 17:34:24 2013
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Thu, 21 Mar 2013 22:34:24 +0100
Subject: [Simh] Formally documenting PDP tape drive behavior (and other
 facets of SIMH and the systems it emulates)
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>
References: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>
Message-ID: <514B7CE0.1060207@fastwebnet.it>

Il 21/03/2013 14:55, Armistead, Jason ha scritto:
> There has been a lot of interesting discussion about tape drives on
> PDP systems in the last week or so.  It's great to hear those
> familiar with the inner workings of these devices, or with access to
> the manuals, share their wisdom.
>
> One question though - after the "old timers" are gone, would a newbie
> to SIMH be able to figure these same things out ?
>
> Or, in other words, do the accompanying comments in the code and the
> SIMH documentation adequately capture the "nuggets" of the
> conversations that take place on this list ?  And do we provide
> enough in the way of "breadcrumbs" to allow a newbie to re-discover
> this same information ?
>
> Capturing this knowledge is a hard thing to do, and with
> retrocomputing we are presently at a point in time where we can still
> rely on folks who designed, built, tested, operated and programmed
> these systems, and in some cases they still even have running systems
> available for experimentation and measurement.  But what happens when
> that is no longer the case ?
>
> Just food for thought ... let's make sure SIMH and its fellow
> emulators like MAME / MESS can still be enjoyed and understood by
> future generations.

I have reported, and was discussed here, the issues with PDP-4/7 DECsys, 
whose is rooted in the partial emulation of the DECTape formatting; In 
more recent time, I have haved little time to fool with SIMH, so I guess 
that a .txt or .odt shared "Notebook of SIMH" can be a good idea.

oh, and about the issues with ex and de, e.g. Librascope emulation ?

Best regards from Italy,
dott. Piergiorgio.

From bob at supnik.org  Wed Mar 27 22:08:01 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 27 Mar 2013 22:08:01 -0400
Subject: [Simh] PDP-10 DECtapes
Message-ID: <5153A601.2090004@supnik.org>

I believe the PDP-10 DECtape images that are floating around the web may 
not be accurate transcriptions.

All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
words in a 32b container (a 36b word in a 72b container). Thus, each 
256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
Therefore, the unage length, in KB, should equal the number of blocks, 
which is 578. And in fact, all extent 18b PDP DECtape images are 578KB long.

A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W 
x 16b DECtape block requires 1/2 KB of storage. Therefore, the image 
length, in KB, should equal half the number of blocks, or 578 / 2 = 289. 
And that's what we have.

This is confirmed by the fact that if you let the simulator "autosize" 
the 289KB images, it comes up with PDP-11 format.

I verified, by patching the simulator, that there is data in both halves 
of each 32b word in the image. This too points to a PDP-11 image.

Even if the PDP-10 DECtape were packed with no  padding, it should be 
18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images 
were transcribed on a TC11 and are missing 2b in every 18b.

This is not to say that the TD8E simulator is correct. I cannot get it 
to zero (initialize) a fresh 18b DECtape through PIP10, so something is 
broken. However, the TD8E is so arcane that it will take a considerable 
period of time to figure out what the software is trying to do and why 
the simulator is responding incorrectly.

/Bob

From litt at ieee.org  Thu Mar 28 06:43:05 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 06:43:05 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5153A601.2090004@supnik.org>
References: <5153A601.2090004@supnik.org>
Message-ID: <51541EB9.6080204@ieee.org>

Bob,

It might be useful to know exactly which images you tested.  A number of 
the 'PDP-10 DECtape images' that turned up on a quick Google search are 
actually for the PDP-11 front-end of a KL1090/1090.  These are in fact 
16-bit tapes: the file format would be Files-11 for RSX20F tapes; I 
think the KLAD DECtapes were DOS-11 format, but it's been a while.  The 
KLAD tapes were accessed by the -11 and loaded into the -10 via the 
DTE20.   This is distinct from 10-side DECtape diagnostics, which also 
exist. Google 'AA-JS16A-TC' for some Files-11 format information; I'd 
have to think a bit on the DOS-11 format.

Knowing which images you're working with would let the custodians of the 
images indicate their source, and perhaps from that we can work back to 
the people/method/tools used to create them.

Also, if the data that you're working with is in fact truncated saves of 
36-bit data, the directory block should still be recognizable.  
Filenames are in sixbit, and the block numbers in links fit in 16 bits.  
So the data should make sense, even if it is incomplete.  I posted the 
key format information for TOPS-10 DECtapes a while back in this 
string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.

I could look at an image file if you need help untangling the data.

On the pip10 /z, pip10 seems to use a private DTA service routine; it's 
in the sources that I pointed you to earlier.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 27-Mar-13 22:08, Bob Supnik wrote:
> I believe the PDP-10 DECtape images that are floating around the web 
> may not be accurate transcriptions.
>
> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
> words in a 32b container (a 36b word in a 72b container). Thus, each 
> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
> Therefore, the unage length, in KB, should equal the number of blocks, 
> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB 
> long.
>
> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
> image length, in KB, should equal half the number of blocks, or 578 / 
> 2 = 289. And that's what we have.
>
> This is confirmed by the fact that if you let the simulator "autosize" 
> the 289KB images, it comes up with PDP-11 format.
>
> I verified, by patching the simulator, that there is data in both 
> halves of each 32b word in the image. This too points to a PDP-11 image.
>
> Even if the PDP-10 DECtape were packed with no  padding, it should be 
> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
> images were transcribed on a TC11 and are missing 2b in every 18b.
>
> This is not to say that the TD8E simulator is correct. I cannot get it 
> to zero (initialize) a fresh 18b DECtape through PIP10, so something 
> is broken. However, the TD8E is so arcane that it will take a 
> considerable period of time to figure out what the software is trying 
> to do and why the simulator is responding incorrectly.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/a6f35470/attachment.bin>

From bob at supnik.org  Thu Mar 28 07:45:31 2013
From: bob at supnik.org (Bob Supnik)
Date: Thu, 28 Mar 2013 07:45:31 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51541EB9.6080204@ieee.org>
References: <5153A601.2090004@supnik.org> <51541EB9.6080204@ieee.org>
Message-ID: <51542D5B.8030806@supnik.org>

I think you've got it, Tim. Here's what I've found:

05/13/2004  02:29 PM           295,936 J189B.DTA
05/13/2004  02:29 PM           295,936 J190C.DTA
05/13/2004  02:29 PM           295,936 J331A.DTA
06/24/2006  05:21 PM           295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta

The last is the image Tim provided.

Still have to debug PIP10; it would be easier with an OS/8 system 
generated for the TC08.

/Bob

On 3/28/2013 6:43 AM, Timothe Litt wrote:
> Bob,
>
> It might be useful to know exactly which images you tested.  A number 
> of the 'PDP-10 DECtape images' that turned up on a quick Google search 
> are actually for the PDP-11 front-end of a KL1090/1090.  These are in 
> fact 16-bit tapes: the file format would be Files-11 for RSX20F tapes; 
> I think the KLAD DECtapes were DOS-11 format, but it's been a while.  
> The KLAD tapes were accessed by the -11 and loaded into the -10 via 
> the DTE20.   This is distinct from 10-side DECtape diagnostics, which 
> also exist. Google 'AA-JS16A-TC' for some Files-11 format information; 
> I'd have to think a bit on the DOS-11 format.
>
> Knowing which images you're working with would let the custodians of 
> the images indicate their source, and perhaps from that we can work 
> back to the people/method/tools used to create them.
>
> Also, if the data that you're working with is in fact truncated saves 
> of 36-bit data, the directory block should still be recognizable.  
> Filenames are in sixbit, and the block numbers in links fit in 16 
> bits.  So the data should make sense, even if it is incomplete.  I 
> posted the key format information for TOPS-10 DECtapes a while back in 
> this string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.
>
> I could look at an image file if you need help untangling the data.
>
> On the pip10 /z, pip10 seems to use a private DTA service routine; 
> it's in the sources that I pointed you to earlier.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 27-Mar-13 22:08, Bob Supnik wrote:
>> I believe the PDP-10 DECtape images that are floating around the web 
>> may not be accurate transcriptions.
>>
>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
>> words in a 32b container (a 36b word in a 72b container). Thus, each 
>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
>> Therefore, the unage length, in KB, should equal the number of 
>> blocks, which is 578. And in fact, all extent 18b PDP DECtape images 
>> are 578KB long.
>>
>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
>> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
>> image length, in KB, should equal half the number of blocks, or 578 / 
>> 2 = 289. And that's what we have.
>>
>> This is confirmed by the fact that if you let the simulator 
>> "autosize" the 289KB images, it comes up with PDP-11 format.
>>
>> I verified, by patching the simulator, that there is data in both 
>> halves of each 32b word in the image. This too points to a PDP-11 image.
>>
>> Even if the PDP-10 DECtape were packed with no  padding, it should be 
>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
>> images were transcribed on a TC11 and are missing 2b in every 18b.
>>
>> This is not to say that the TD8E simulator is correct. I cannot get 
>> it to zero (initialize) a fresh 18b DECtape through PIP10, so 
>> something is broken. However, the TD8E is so arcane that it will take 
>> a considerable period of time to figure out what the software is 
>> trying to do and why the simulator is responding incorrectly.
>>
>> /Bob
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>


From bqt at softjar.se  Thu Mar 28 08:17:57 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 13:17:57 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5153A601.2090004@supnik.org>
References: <5153A601.2090004@supnik.org>
Message-ID: <515434F5.9090100@softjar.se>

On 2013-03-28 03:08, Bob Supnik wrote:
> I believe the PDP-10 DECtape images that are floating around the web may
> not be accurate transcriptions.
>
> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
> words in a 32b container (a 36b word in a 72b container). Thus, each
> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
> Therefore, the unage length, in KB, should equal the number of blocks,
> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
> long.
>
> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
> And that's what we have.
>
> This is confirmed by the fact that if you let the simulator "autosize"
> the 289KB images, it comes up with PDP-11 format.
>
> I verified, by patching the simulator, that there is data in both halves
> of each 32b word in the image. This too points to a PDP-11 image.
>
> Even if the PDP-10 DECtape were packed with no  padding, it should be
> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
> were transcribed on a TC11 and are missing 2b in every 18b.
>
> This is not to say that the TD8E simulator is correct. I cannot get it
> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
> broken. However, the TD8E is so arcane that it will take a considerable
> period of time to figure out what the software is trying to do and why
> the simulator is responding incorrectly.

I don't know if I'd call the TD8E arcane. Like I said before, it is the 
most stupid controller ever invented.
I had to write code last year to extract 18b images from a PDP-15 using 
the TD8E. Reading through the documentation, and reading through the 
TD8E driver as well as PIP10 was enough for me to understand how it 
worked, so you should be able to do the same.
Basically, the TD8E gives you almost nothing at all. You need to do just 
about all the fiddling yourself.
It is horribly stupid and primitive.

	Johnny


From litt at ieee.org  Thu Mar 28 08:24:16 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 08:24:16 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51542D5B.8030806@supnik.org>
References: <5153A601.2090004@supnik.org> <51541EB9.6080204@ieee.org>
 <51542D5B.8030806@supnik.org>
Message-ID: <51543670.90309@ieee.org>

J189B is the RSX20F V14-17 AUX dectape
J190C is the V14-45 system tape
J331A is the the V12-40 AUX tape.

All of these are Files-11 format (16-bit).

DCZBA decodes to a KA/KI diagnostic, but it turns out to be the 'basic 
peripheral diagnostic'; it probably wasn't renamed for the KL.  
According to the label on bitsavers 
(http://bitsavers.trailing-edge.com/bits/DEC/pdp10/dectape/diag/MAINDEC-10-DCZBA-C-UB_4-73.dta.txt), 
this is a 16-bit formatted tape containing 11-based KL10 diagnostics.  
So the filename may be wrong...

In any case, you don't have any -10 format DECtape images.

I have some physical 10-format tapes, but not the means to transcribe 
them. They're not of general interest; personal files.

I vaguely remember that someone has captured real 36-bit DECtapes, but 
the details escape me.  Al Kossow may remember...

A previous note pointed you to the OS/8 doc on how to configure for 
different hardware.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 07:45, Bob Supnik wrote:
> I think you've got it, Tim. Here's what I've found:
>
> 05/13/2004  02:29 PM           295,936 J189B.DTA
> 05/13/2004  02:29 PM           295,936 J190C.DTA
> 05/13/2004  02:29 PM           295,936 J331A.DTA
> 06/24/2006  05:21 PM           295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta
>
> The last is the image Tim provided.
>
> Still have to debug PIP10; it would be easier with an OS/8 system 
> generated for the TC08.
>
> /Bob
>
> On 3/28/2013 6:43 AM, Timothe Litt wrote:
>> Bob,
>>
>> It might be useful to know exactly which images you tested.  A number 
>> of the 'PDP-10 DECtape images' that turned up on a quick Google 
>> search are actually for the PDP-11 front-end of a KL1090/1090.  These 
>> are in fact 16-bit tapes: the file format would be Files-11 for 
>> RSX20F tapes; I think the KLAD DECtapes were DOS-11 format, but it's 
>> been a while.  The KLAD tapes were accessed by the -11 and loaded 
>> into the -10 via the DTE20. This is distinct from 10-side DECtape 
>> diagnostics, which also exist. Google 'AA-JS16A-TC' for some Files-11 
>> format information; I'd have to think a bit on the DOS-11 format.
>>
>> Knowing which images you're working with would let the custodians of 
>> the images indicate their source, and perhaps from that we can work 
>> back to the people/method/tools used to create them.
>>
>> Also, if the data that you're working with is in fact truncated saves 
>> of 36-bit data, the directory block should still be recognizable.  
>> Filenames are in sixbit, and the block numbers in links fit in 16 
>> bits.  So the data should make sense, even if it is incomplete.  I 
>> posted the key format information for TOPS-10 DECtapes a while back 
>> in this string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.
>>
>> I could look at an image file if you need help untangling the data.
>>
>> On the pip10 /z, pip10 seems to use a private DTA service routine; 
>> it's in the sources that I pointed you to earlier.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>> On 27-Mar-13 22:08, Bob Supnik wrote:
>>> I believe the PDP-10 DECtape images that are floating around the web 
>>> may not be accurate transcriptions.
>>>
>>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
>>> words in a 32b container (a 36b word in a 72b container). Thus, each 
>>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
>>> Therefore, the unage length, in KB, should equal the number of 
>>> blocks, which is 578. And in fact, all extent 18b PDP DECtape images 
>>> are 578KB long.
>>>
>>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
>>> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
>>> image length, in KB, should equal half the number of blocks, or 578 
>>> / 2 = 289. And that's what we have.
>>>
>>> This is confirmed by the fact that if you let the simulator 
>>> "autosize" the 289KB images, it comes up with PDP-11 format.
>>>
>>> I verified, by patching the simulator, that there is data in both 
>>> halves of each 32b word in the image. This too points to a PDP-11 
>>> image.
>>>
>>> Even if the PDP-10 DECtape were packed with no  padding, it should 
>>> be 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
>>> images were transcribed on a TC11 and are missing 2b in every 18b.
>>>
>>> This is not to say that the TD8E simulator is correct. I cannot get 
>>> it to zero (initialize) a fresh 18b DECtape through PIP10, so 
>>> something is broken. However, the TD8E is so arcane that it will 
>>> take a considerable period of time to figure out what the software 
>>> is trying to do and why the simulator is responding incorrectly.
>>>
>>> /Bob
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/f246d257/attachment-0001.bin>

From litt at ieee.org  Thu Mar 28 08:41:44 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 08:41:44 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <515434F5.9090100@softjar.se>
References: <5153A601.2090004@supnik.org> <515434F5.9090100@softjar.se>
Message-ID: <51543A88.5060802@ieee.org>

> I don't know if I'd call the TD8E arcane. 

I'll side with Bob on this one.  You would too, if you glance at the 
simh code for emulating it.  Even the imperfect emulation has to deal 
with mechanical timing - acceleration, deceleration and timing marks.   
(Imperfect = linear approximation; speed actually varies as a function 
of position due to the diameter changes as tape goes on and off the 
reels.)  And there are other oddities that software may or may not be 
sensitive to.  Like the fact that you don't just wait for acceleration; 
the tape moves, so the next valid block number over the read head is a 
function of when the tape is up to speed.  For the smart controllers, 
you don't see the block number until up-to-speed.  For the TD8E, I don't 
know.

Dumb hardware doesn't mean that the emulation is easy or simple. 
Sometimes it is; sometimes not.  This is not.


This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 08:17, Johnny Billquist wrote:
> On 2013-03-28 03:08, Bob Supnik wrote:
>> I believe the PDP-10 DECtape images that are floating around the web may
>> not be accurate transcriptions.
>>
>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
>> words in a 32b container (a 36b word in a 72b container). Thus, each
>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
>> Therefore, the unage length, in KB, should equal the number of blocks,
>> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
>> long.
>>
>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
>> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
>> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
>> And that's what we have.
>>
>> This is confirmed by the fact that if you let the simulator "autosize"
>> the 289KB images, it comes up with PDP-11 format.
>>
>> I verified, by patching the simulator, that there is data in both halves
>> of each 32b word in the image. This too points to a PDP-11 image.
>>
>> Even if the PDP-10 DECtape were packed with no  padding, it should be
>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
>> were transcribed on a TC11 and are missing 2b in every 18b.
>>
>> This is not to say that the TD8E simulator is correct. I cannot get it
>> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
>> broken. However, the TD8E is so arcane that it will take a considerable
>> period of time to figure out what the software is trying to do and why
>> the simulator is responding incorrectly.
>
> I don't know if I'd call the TD8E arcane. Like I said before, it is 
> the most stupid controller ever invented.
> I had to write code last year to extract 18b images from a PDP-15 
> using the TD8E. Reading through the documentation, and reading through 
> the TD8E driver as well as PIP10 was enough for me to understand how 
> it worked, so you should be able to do the same.
> Basically, the TD8E gives you almost nothing at all. You need to do 
> just about all the fiddling yourself.
> It is horribly stupid and primitive.
>
>     Johnny
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/0c844f29/attachment.bin>

From bob at supnik.org  Thu Mar 28 11:43:54 2013
From: bob at supnik.org (Bob Supnik)
Date: Thu, 28 Mar 2013 11:43:54 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.133.1364473463.1077.simh@trailing-edge.com>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
Message-ID: <5154653A.8080004@supnik.org>

Johnny Billquist wrote:

I don't know if I'd call the TD8E arcane. Like I said before, it is the
most stupid controller ever invented.
I had to write code last year to extract 18b images from a PDP-15 using
the TD8E. Reading through the documentation, and reading through the
TD8E driver as well as PIP10 was enough for me to understand how it
worked, so you should be able to do the same.
Basically, the TD8E gives you almost nothing at all. You need to do just
about all the fiddling yourself.
It is horribly stupid and primitive.

I agree; and the TD8E simulator reads and writes OS/8 format DECtapes just fine.

The problem is that it doesn't work with Mark Bramhall's handcrafted DECtape drivers in PIP10. Tracing what the TD8E simulator is doing, versus what Mark's driver is expecting, is the complication.

On the TC08, all the cruft is hidden, and the simulator operates on a word-by-word basis. On the TD8E, all the cruft is exposed, and the simulator operates on a line-by-line basis. It also has to simulate the the mark track codes on a bit-by-bit basis. I suspect that the mark track simulation isn't quite right with non-standard block sizes.

/Bob


From bqt at softjar.se  Thu Mar 28 12:47:37 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 17:47:37 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51543A88.5060802@ieee.org>
References: <5153A601.2090004@supnik.org> <515434F5.9090100@softjar.se>
 <51543A88.5060802@ieee.org>
Message-ID: <51547429.1080206@softjar.se>

On 2013-03-28 13:41, Timothe Litt wrote:
>> I don't know if I'd call the TD8E arcane.
>
> I'll side with Bob on this one.  You would too, if you glance at the
> simh code for emulating it.  Even the imperfect emulation has to deal
> with mechanical timing - acceleration, deceleration and timing marks.
> (Imperfect = linear approximation; speed actually varies as a function
> of position due to the diameter changes as tape goes on and off the
> reels.)  And there are other oddities that software may or may not be
> sensitive to.  Like the fact that you don't just wait for acceleration;
> the tape moves, so the next valid block number over the read head is a
> function of when the tape is up to speed.  For the smart controllers,
> you don't see the block number until up-to-speed.  For the TD8E, I don't
> know.
>
> Dumb hardware doesn't mean that the emulation is easy or simple.
> Sometimes it is; sometimes not.  This is not.

I wasn't arguing that it was easy. In this case the opposite is 
definitely true. The TD8E is horrible. I've been saying that a number of 
times now. But I wouldn't call it arcane. It's simple.
That is the problem. It is too simple. It essentially exposes more or 
less just the electrical interface to the TU56, and that's it.

And that is the unfortunate part, because that means it exposes a very 
analog, stupid interface. It is very complex to emulate right, since it 
does so little.
Really. A TD8E does almost nothing. It is so simple and cheap it is 
ridiculous. The board have very little logic. And it was really cheap. 
And easy to design. And easy to manufacture.

It was the super-cheap option for a PDP-8 if you wanted DECtape.

Like I said, it is anything but complex in real life. Emulating it is a 
totally different story, for the same reason.

Depending on what you try to emulate, you can afford a few shortcuts. 
For OS/8, as well as all other DEC software I know of, you don't need to 
emulate the tape acceleration. You can pretend acceleration is 
instantaneous. Since all DEC software run the TD8E in polled mode, it is 
always just sitting there reading data until the right stuff comes. If 
you start feeding data a little earlier from the tape, it don't change 
anything.
Software like MULTOS, which actually try to use the TD8E in a 
timesharing system on the other hand, is a problem, since it does timing 
calculations for the tape to estimate how long before it comes to the 
right place, in order to not just do a polling loop all the time (not 
fun if you timeshare). However, no DEC software ever supported the TD8E 
in anything but just polled I/O.

(Yes, I really dislike the TD8E. And yes, I have a real one.)

	Johnny

>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 28-Mar-13 08:17, Johnny Billquist wrote:
>> On 2013-03-28 03:08, Bob Supnik wrote:
>>> I believe the PDP-10 DECtape images that are floating around the web may
>>> not be accurate transcriptions.
>>>
>>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
>>> words in a 32b container (a 36b word in a 72b container). Thus, each
>>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
>>> Therefore, the unage length, in KB, should equal the number of blocks,
>>> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
>>> long.
>>>
>>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
>>> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
>>> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
>>> And that's what we have.
>>>
>>> This is confirmed by the fact that if you let the simulator "autosize"
>>> the 289KB images, it comes up with PDP-11 format.
>>>
>>> I verified, by patching the simulator, that there is data in both halves
>>> of each 32b word in the image. This too points to a PDP-11 image.
>>>
>>> Even if the PDP-10 DECtape were packed with no  padding, it should be
>>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
>>> were transcribed on a TC11 and are missing 2b in every 18b.
>>>
>>> This is not to say that the TD8E simulator is correct. I cannot get it
>>> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
>>> broken. However, the TD8E is so arcane that it will take a considerable
>>> period of time to figure out what the software is trying to do and why
>>> the simulator is responding incorrectly.
>>
>> I don't know if I'd call the TD8E arcane. Like I said before, it is
>> the most stupid controller ever invented.
>> I had to write code last year to extract 18b images from a PDP-15
>> using the TD8E. Reading through the documentation, and reading through
>> the TD8E driver as well as PIP10 was enough for me to understand how
>> it worked, so you should be able to do the same.
>> Basically, the TD8E gives you almost nothing at all. You need to do
>> just about all the fiddling yourself.
>> It is horribly stupid and primitive.
>>
>>     Johnny
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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

From bqt at softjar.se  Thu Mar 28 12:53:42 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 17:53:42 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5154653A.8080004@supnik.org>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <5154653A.8080004@supnik.org>
Message-ID: <51547596.8000900@softjar.se>

On 2013-03-28 16:43, Bob Supnik wrote:
> Johnny Billquist wrote:
>
>> Basically, the TD8E gives you almost nothing at all. You need to do just
>> about all the fiddling yourself.
>> It is horribly stupid and primitive.
>
> I agree; and the TD8E simulator reads and writes OS/8 format DECtapes
> just fine.

Even that is actually quite an accomplishment, if you ask me.

> The problem is that it doesn't work with Mark Bramhall's handcrafted
> DECtape drivers in PIP10. Tracing what the TD8E simulator is doing,
> versus what Mark's driver is expecting, is the complication.

I bet.

> On the TC08, all the cruft is hidden, and the simulator operates on a
> word-by-word basis. On the TD8E, all the cruft is exposed, and the
> simulator operates on a line-by-line basis. It also has to simulate the
> the mark track codes on a bit-by-bit basis. I suspect that the mark
> track simulation isn't quite right with non-standard block sizes.

Yes. The TC08 is a sane thing in comparison. Not to mention that the 
emulation can be done at a reasonable level.
I would also suspect the mark track simulation. That is where most of 
the magic happens.

Sorry that I can't offer more help. I'm way too busy with other things 
right now to add yet another project. All I can do is to make some 
comments that I hope might atleast offer encouragement. (I did send some 
patches to the VAX8600 code in simh last week, and I'm trying to fix 
NetBSD working on that emulation, as well as all my pdp11-related work 
(not all simh related though)...)

	Johnny

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

From baker at usgs.gov  Thu Mar 28 14:09:40 2013
From: baker at usgs.gov (Larry Baker)
Date: Thu, 28 Mar 2013 11:09:40 -0700
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.133.1364473463.1077.simh@trailing-edge.com>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
Message-ID: <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>

On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> Google 'AA-JS16A-TC' for some Files-11 format information; I'd 
> have to think a bit on the DOS-11 format.


RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also used HDR3/4 labels for RMS information.  There was a MOUNT option to suppress writing those labels.

I wrote an RSX/VMS  program that will scan an unknown tape and decode it for you.  (If anyone wants it, let me know where I should upload it.)  The DOS format decoder looks for a 14 byte (physical) record at the start of the file.  It is decoded by the following code:

C
C...  DEC DOS labels
C
      Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
      Call R50ASC ( 3, buffer(13), ascbuf( 7) )
      ascbuf(10) = '.'
      Call R50ASC ( 3, buffer( 5), ascbuf(11) )
      ltemp(1) = buffer(7)
      ltemp(2) = 0
      mem = itemp
      ltemp(1) = buffer(8)
      grp = itemp
      ltemp(1) = buffer(11)
      ltemp(2) = buffer(12)
      jday = MOD(itemp,1000)
      year = itemp/1000 + 70
      Call JDCONV ( jday, mon, day, year )
      ltemp(1) = buffer( 9)
      ltemp(2) = buffer(10)
      Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
     1                   year, itemp
  619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
     1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')

The DOS label contents are:

Words 1-2 RAD50 characters 1-6 of the file name part (before the implied period)
Word 3 RAD50 characters 1-3 of the file type (after the implied period)
Word 4 Octal File owner's User Identification Code (group code in high-order byte, member code in low-order byte)
Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
Word 6 Octal File protection (low-order to high-order RWED bits: read, write, extend, delete; grouped low-order to high-order for system, owner, group, world)
Word 7 RAD50 characters 7-9 of the file name part (before the implied period)

The references I used to write the program (back in the 1980's) are below.  Which reference had the DOS label format I don't remember (if any of them did).

6  References

[1]  American National Standards Institute, 1978, Magnetic Tape Labels
     and File Structure for Information Interchange (ANSI X3.27-1978).

[2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
     Manual (Order no. AA-FD10A-TC).

[3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
     Manual (Order no. AA-FD04A-TC).

[4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
     Operations Reference Manual (Order no. AA-FD14A-TC).

[5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus   I/O   Drivers
     Reference Manual (Order no. AA-FD09A-TC).

[6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
     Reference Manual (Order no. AA-Z408A-TE).

[7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
     AA-Z200C-TE).

[8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
     Manual (Order no. AA-Z424C-TE).

[9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
     Tape Operations (Order no. AI-Y506B-TE).

[10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
     Manual:  Part I (Order no. AA-Z600C-TE).

[11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
     (Order No. GC26-3795-1).

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/92355a70/attachment-0001.html>

From litt at ieee.org  Thu Mar 28 14:23:57 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 14:23:57 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>
Message-ID: <51548ABD.7060708@ieee.org>

Good information, but this thread is about DECtape, not 9-Track magtapes...

The format looks about right for 9-track DOS-11 magtapes; I remember 
writing code to extract files from them on the -10.

It's not right (or at least, not complete) for the block-addressable 
DECtapes.

I don't think DOS-11 would have been documented in any of the references 
cited.

There's now a SIMH repo on github; your utility could go into the tools 
section.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 14:09, Larry Baker wrote:
> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> 
> <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> wrote:
>
>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>> have to think a bit on the DOS-11 format.
>
> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also 
> used HDR3/4 labels for RMS information.  There was a MOUNT option to 
> suppress writing those labels.
>
> I wrote an RSX/VMS  program that will scan an unknown tape and decode 
> it for you.  (If anyone wants it, let me know where I should upload 
> it.)  The DOS format decoder looks for a 14 byte (physical) record at 
> the start of the file.  It is decoded by the following code:
>
> C
> C...  DEC DOS labels
> C
>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>       ascbuf(10) = '.'
>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>       ltemp(1) = buffer(7)
>       ltemp(2) = 0
>       mem = itemp
>       ltemp(1) = buffer(8)
>       grp = itemp
>       ltemp(1) = buffer(11)
>       ltemp(2) = buffer(12)
>       jday = MOD(itemp,1000)
>       year = itemp/1000 + 70
>       Call JDCONV ( jday, mon, day, year )
>       ltemp(1) = buffer( 9)
>       ltemp(2) = buffer(10)
>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>      1                   year, itemp
>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>
> The DOS label contents are:
>
> Words 1-2 RAD50 characters 1-6 of the file name part (before the 
> implied period)
> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
> Word 4 Octal File owner's User Identification Code (group code in 
> high-order byte, member code in low-order byte)
> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
> Word 6 Octal File protection (low-order to high-order RWED bits: read, 
> write, extend, delete; grouped low-order to high-order for system, 
> owner, group, world)
> Word 7 RAD50 characters 7-9 of the file name part (before the implied 
> period)
>
> The references I used to write the program (back in the 1980's) are 
> below.  Which reference had the DOS label format I don't remember (if 
> any of them did).
>
> 6  References
>
> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>      and File Structure for Information Interchange (ANSI X3.27-1978).
>
> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
>      Manual (Order no. AA-FD10A-TC).
>
> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
>      Manual (Order no. AA-FD04A-TC).
>
> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
>      Operations Reference Manual (Order no. AA-FD14A-TC).
>
> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O   Drivers
>      Reference Manual (Order no. AA-FD09A-TC).
>
> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>      Reference Manual (Order no. AA-Z408A-TE).
>
> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>      AA-Z200C-TE).
>
> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
>      Manual (Order no. AA-Z424C-TE).
>
> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>      Tape Operations (Order no. AI-Y506B-TE).
>
> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
>      Manual:  Part I (Order no. AA-Z600C-TE).
>
> [11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
>      (Order No. GC26-3795-1).
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov <mailto:baker at usgs.gov>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/1a6d7fe0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/1a6d7fe0/attachment.bin>

From bqt at softjar.se  Thu Mar 28 15:19:41 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 20:19:41 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51548ABD.7060708@ieee.org>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov> <51548ABD.7060708@ieee.org>
Message-ID: <515497CD.2020201@softjar.se>

On 2013-03-28 19:23, Timothe Litt wrote:
> Good information, but this thread is about DECtape, not 9-Track magtapes...

Right.

> The format looks about right for 9-track DOS-11 magtapes; I remember
> writing code to extract files from them on the -10.
>
> It's not right (or at least, not complete) for the block-addressable
> DECtapes.

DECtapes (atleast on RSX) are Files-11 ODS-1 volumes, and not ANSI 
labelled tapes. They have nothing in common with each other, apart from 
both being tapes. The closest relative to a DECtape is a floppy.

Also, the DOS-11 tape format is not the same as ANSI labelled tapes. 
They are not compatible.

In RSX, ANSI labelled tapes are accessed through MTAACP, and the tapes 
are mounted as a known format. You then access them with the normal 
tools you'd use for any normal work in RSX. (Such as PIP.)
DOS-11 tapes are instead mounted foreign, and you need FLX to read/write 
to them.

	Johnny

> I don't think DOS-11 would have been documented in any of the references
> cited.
>
> There's now a SIMH repo on github; your utility could go into the tools
> section.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 28-Mar-13 14:09, Larry Baker wrote:
>> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com
>> <mailto:simh-request at trailing-edge.com>>
>> <simh-request at trailing-edge.com
>> <mailto:simh-request at trailing-edge.com>> wrote:
>>
>>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>>> have to think a bit on the DOS-11 format.
>>
>> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also
>> used HDR3/4 labels for RMS information.  There was a MOUNT option to
>> suppress writing those labels.
>>
>> I wrote an RSX/VMS  program that will scan an unknown tape and decode
>> it for you.  (If anyone wants it, let me know where I should upload
>> it.)  The DOS format decoder looks for a 14 byte (physical) record at
>> the start of the file.  It is decoded by the following code:
>>
>> C
>> C...  DEC DOS labels
>> C
>>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>>       ascbuf(10) = '.'
>>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>>       ltemp(1) = buffer(7)
>>       ltemp(2) = 0
>>       mem = itemp
>>       ltemp(1) = buffer(8)
>>       grp = itemp
>>       ltemp(1) = buffer(11)
>>       ltemp(2) = buffer(12)
>>       jday = MOD(itemp,1000)
>>       year = itemp/1000 + 70
>>       Call JDCONV ( jday, mon, day, year )
>>       ltemp(1) = buffer( 9)
>>       ltemp(2) = buffer(10)
>>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>>      1                   year, itemp
>>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>>
>> The DOS label contents are:
>>
>> Words 1-2 RAD50 characters 1-6 of the file name part (before the
>> implied period)
>> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
>> Word 4 Octal File owner's User Identification Code (group code in
>> high-order byte, member code in low-order byte)
>> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
>> Word 6 Octal File protection (low-order to high-order RWED bits: read,
>> write, extend, delete; grouped low-order to high-order for system,
>> owner, group, world)
>> Word 7 RAD50 characters 7-9 of the file name part (before the implied
>> period)
>>
>> The references I used to write the program (back in the 1980's) are
>> below.  Which reference had the DOS label format I don't remember (if
>> any of them did).
>>
>> 6  References
>>
>> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>>      and File Structure for Information Interchange (ANSI X3.27-1978).
>>
>> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
>>      Manual (Order no. AA-FD10A-TC).
>>
>> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
>>      Manual (Order no. AA-FD04A-TC).
>>
>> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
>>      Operations Reference Manual (Order no. AA-FD14A-TC).
>>
>> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O   Drivers
>>      Reference Manual (Order no. AA-FD09A-TC).
>>
>> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>>      Reference Manual (Order no. AA-Z408A-TE).
>>
>> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>>      AA-Z200C-TE).
>>
>> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
>>      Manual (Order no. AA-Z424C-TE).
>>
>> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>>      Tape Operations (Order no. AI-Y506B-TE).
>>
>> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
>>      Manual:  Part I (Order no. AA-Z600C-TE).
>>
>> [11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
>>      (Order No. GC26-3795-1).
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker at usgs.gov <mailto:baker at usgs.gov>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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

From baker at usgs.gov  Thu Mar 28 15:50:18 2013
From: baker at usgs.gov (Larry Baker)
Date: Thu, 28 Mar 2013 12:50:18 -0700
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.137.1364498391.1077.simh@trailing-edge.com>
References: <mailman.137.1364498391.1077.simh@trailing-edge.com>
Message-ID: <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>

On 28 Mar 2013, at 12:19 PM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> It's not right (or at least, not complete) for the block-addressable 
> DECtapes.


Right.  I forgot DECtapes are block addressable.

Does anyone need any RSX Files-11 on-disk format documentation?  I have a paper copy of Andy Goldstein's 1979 Files-11 documentation.  I imagine Al does too.  I could try to find out what the RSX manuals say about the initialization parameters used for a DECtape.  It is quote likely they don't make DECtape a special case, but use the same parameters for any small capacity disk (like a floppy).

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/72893cbc/attachment.html>

From litt at ieee.org  Thu Mar 28 16:09:56 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 16:09:56 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <515497CD.2020201@softjar.se>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov> <51548ABD.7060708@ieee.org>
 <515497CD.2020201@softjar.se>
Message-ID: <5154A394.70905@ieee.org>

I guess I'm not allowed a convenient memory lapse.

DOS-11 predates RSX & Files-11.  It has a MFD/UFD directory structure, 
vaguely echoing TOPS-10.  I think that the 14-bye tape file header is 
most of the directory entry from the on-disk DOS-11 structure.  This 
caused some grief on tape, as the ANSI standard (and some 
drives/drivers) require a minimum record length of 18 bytes; thus the 
directory entries on MM could be skipped as 'noise records'.

The DECtape file structure for DOS-11 is documented in 
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/dos-batch/DOS_CourseHandouts.pdf, 
mostly in 
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/dos-batch/DosBatchHandbook_v9_Apr74/02.pdf, 
with other random bits in the other chapters.

It's not the same as RSX or RT.  Different design goals - and different 
engineering groups :-)

DOS was serially multi-user.  So it had permissions, contiguous and 
linked files.  RT single user; no permissions, contiguous only.  RSX got 
Files-11 - the everything to everyone format - at the cost of ACPs, 
complexity and memory.

I think - but I'd have to dissect a tape - that KLDCP used the DOS file 
structure on -11 DECtape for simplicity, and the fact that there were 
interchange programs (flx,etc) that could read/write them on the other 
OSs.  It was the least common denominator file structure.

Of course, DTAs were so slow and expensive that you wanted to run from 
disk instead, even when floppies replaced DECtape as the KL's front-end 
device.

In any case, the simh problem appears to be a low-level format 
emulation; my remarks on the file structure were only provided to assist 
in identifying the data.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 15:19, Johnny Billquist wrote:
> On 2013-03-28 19:23, Timothe Litt wrote:
>> Good information, but this thread is about DECtape, not 9-Track 
>> magtapes...
>
> Right.
>
>> The format looks about right for 9-track DOS-11 magtapes; I remember
>> writing code to extract files from them on the -10.
>>
>> It's not right (or at least, not complete) for the block-addressable
>> DECtapes.
>
> DECtapes (atleast on RSX) are Files-11 ODS-1 volumes, and not ANSI 
> labelled tapes. They have nothing in common with each other, apart 
> from both being tapes. The closest relative to a DECtape is a floppy.
>
> Also, the DOS-11 tape format is not the same as ANSI labelled tapes. 
> They are not compatible.
>
> In RSX, ANSI labelled tapes are accessed through MTAACP, and the tapes 
> are mounted as a known format. You then access them with the normal 
> tools you'd use for any normal work in RSX. (Such as PIP.)
> DOS-11 tapes are instead mounted foreign, and you need FLX to 
> read/write to them.
>
>     Johnny
>
>> I don't think DOS-11 would have been documented in any of the references
>> cited.
>>
>> There's now a SIMH repo on github; your utility could go into the tools
>> section.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>> On 28-Mar-13 14:09, Larry Baker wrote:
>>> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com
>>> <mailto:simh-request at trailing-edge.com>>
>>> <simh-request at trailing-edge.com
>>> <mailto:simh-request at trailing-edge.com>> wrote:
>>>
>>>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>>>> have to think a bit on the DOS-11 format.
>>>
>>> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also
>>> used HDR3/4 labels for RMS information.  There was a MOUNT option to
>>> suppress writing those labels.
>>>
>>> I wrote an RSX/VMS  program that will scan an unknown tape and decode
>>> it for you.  (If anyone wants it, let me know where I should upload
>>> it.)  The DOS format decoder looks for a 14 byte (physical) record at
>>> the start of the file.  It is decoded by the following code:
>>>
>>> C
>>> C...  DEC DOS labels
>>> C
>>>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>>>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>>>       ascbuf(10) = '.'
>>>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>>>       ltemp(1) = buffer(7)
>>>       ltemp(2) = 0
>>>       mem = itemp
>>>       ltemp(1) = buffer(8)
>>>       grp = itemp
>>>       ltemp(1) = buffer(11)
>>>       ltemp(2) = buffer(12)
>>>       jday = MOD(itemp,1000)
>>>       year = itemp/1000 + 70
>>>       Call JDCONV ( jday, mon, day, year )
>>>       ltemp(1) = buffer( 9)
>>>       ltemp(2) = buffer(10)
>>>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>>>      1                   year, itemp
>>>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>>>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>>>
>>> The DOS label contents are:
>>>
>>> Words 1-2 RAD50 characters 1-6 of the file name part (before the
>>> implied period)
>>> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
>>> Word 4 Octal File owner's User Identification Code (group code in
>>> high-order byte, member code in low-order byte)
>>> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian 
>>> day )
>>> Word 6 Octal File protection (low-order to high-order RWED bits: read,
>>> write, extend, delete; grouped low-order to high-order for system,
>>> owner, group, world)
>>> Word 7 RAD50 characters 7-9 of the file name part (before the implied
>>> period)
>>>
>>> The references I used to write the program (back in the 1980's) are
>>> below.  Which reference had the DOS label format I don't remember (if
>>> any of them did).
>>>
>>> 6  References
>>>
>>> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>>>      and File Structure for Information Interchange (ANSI X3.27-1978).
>>>
>>> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR Operations
>>>      Manual (Order no. AA-FD10A-TC).
>>>
>>> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command Language
>>>      Manual (Order no. AA-FD04A-TC).
>>>
>>> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and Micro/RSX  I/O
>>>      Operations Reference Manual (Order no. AA-FD14A-TC).
>>>
>>> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O Drivers
>>>      Reference Manual (Order no. AA-FD09A-TC).
>>>
>>> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>>>      Reference Manual (Order no. AA-Z408A-TE).
>>>
>>> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>>>      AA-Z200C-TE).
>>>
>>> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility Reference
>>>      Manual (Order no. AA-Z424C-TE).
>>>
>>> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>>>      Tape Operations (Order no. AI-Y506B-TE).
>>>
>>> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's Reference
>>>      Manual:  Part I (Order no. AA-Z600C-TE).
>>>
>>> [11] International Business Machines Corp., 1978,  OS/VS Tape  Labels
>>>      (Order No. GC26-3795-1).
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> baker at usgs.gov <mailto:baker at usgs.gov>
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/3a3271fb/attachment.bin>

From litt at ieee.org  Thu Mar 28 16:16:05 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 16:16:05 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>
References: <mailman.137.1364498391.1077.simh@trailing-edge.com>
 <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>
Message-ID: <5154A505.6060202@ieee.org>

> Does anyone need any RSX Files-11 on-disk format documentation?

I have hardcopy ODS-1 and ODS-2 documentation.  But it's not necessary 
for the current work; I've identified the tapes by other means.  I'm 
sure Al will chime in if he doesn't have a copy.

No need for further research; thanks.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 15:50, Larry Baker wrote:
> On 28 Mar 2013, at 12:19 PM, <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> 
> <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> wrote:
>
>> It's not right (or at least, not complete) for the block-addressable
>> DECtapes.
>
> Right.  I forgot DECtapes are block addressable.
>
> Does anyone need any RSX Files-11 on-disk format documentation?  I 
> have a paper copy of Andy Goldstein's 1979 Files-11 documentation.  I 
> imagine Al does too.  I could try to find out what the RSX manuals say 
> about the initialization parameters used for a DECtape.  It is quote 
> likely they don't make DECtape a special case, but use the same 
> parameters for any small capacity disk (like a floppy).
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov <mailto:baker at usgs.gov>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/7ee5bf61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/7ee5bf61/attachment-0001.bin>

From radioengr at gmail.com  Fri Mar 29 14:12:52 2013
From: radioengr at gmail.com (Rob Doyle)
Date: Fri, 29 Mar 2013 11:12:52 -0700
Subject: [Simh] PDP8, Adventure, and SIMH
Message-ID: <5155D9A4.5080107@gmail.com>


I just noticed that my PDP8 FPGA implementation differs from SIMH
when dealing with mixed/lower case text.

I also checked the operation on David Gesswein's online PDP8 and the
operation of a real PDP8 matches the operation of my PDP8 FPGA and
differs from SIMH.

I did use exactly the same RK05 disk image for both SIMH and the PDP8
FPGA. The image for the real PDP8 /could/ be different.

I'm guessing that SIMH intentionally forces upper case because I didn't
do anything special to the PDP8 FPGA. I didn't see any SIMH
configuration options to change this.

Is this intentional?

Rob.

*------ Using SIMH ------*

.EX ADVENT.LD

WELCOME TO ADVENTURE!!  WOULD YOU LIKE INSTRUCTIONS?

 > YES
SOMEWHERE NEARBY IS COLOSSAL CAVE, WHERE OTHERS HAVE FOUND FORTUNES
IN TREASURE AND GOLD,THOUGH IT IS RUMORED THAT SOME WHO ENTER ARE NEVER
SEEN AGAIN. MAGIC IS SAID TO WORK IN THE CAVE.  I WILL BE YOUR EYES
AND HANDS.  DIRECT ME WITH COMMANDS OF 1 OR 2 WORDS.  I SHOULD WARN
YOU THAT I LOOK AT ONLY THE FIRST FOUR LETTERS OF EACH WORD,SO YOU'LL
HAVE TO ENTER "NORTHEAST" AS "NE" TO DISTINGUISH IT FROM "NORTH".
(SHOULD YOU GET STUCK, TYPE "HELP" FOR SOME GENERAL HINTS.  FOR
INFORMATION ON HOW TO END YOUR ADVENTURE, ETC., TYPE "INFO".)
       - - -
THIS PROGRAM WAS ORIGINALLY DEVELOPED BY WILLIE CROWTHER. MOST OF
THE FEATURES OF THE CURRENT PROGRAM WERE ADDED BY DON WOODS.
THIS VERSION, FOR THE PDP-8, WAS DONE BY DICK MURPHY. IT IS
BASED ON A VERSION FOR RT-11 DONE BY BOB SUPNIK.

* ------ My PDP8 FPGA: ------ *

.EX ADVENT.LD

Welcome to Adventure!!  Would you like instructions?

 > yes
Somewhere nearby is Colossal Cave, where others have found fortunes
in treasure and gold,though it is rumored that some who enter are never
seen again. Magic is said to work in the cave.  I will be your eyes
and hands.  Direct me with commands of 1 or 2 words.  I should warn
you that I look at only the first four letters of each word,so you'll
have to enter "northeast" as "ne" to distinguish it from "north".
(Should you get stuck, type "help" for some general hints.  For
information on how to end your adventure, etc., type "INFO".)
       - - -
This program was originally developed by Willie Crowther. Most of
the features of the current program were added by Don Woods.
This version, for the PDP-8, was done by Dick Murphy. it is
based on a version for RT-11 done by Bob Supnik.

* ------ David Gesswein's Online PDP8: ------ *

RUN RKB0:ADVENT
 

Welcome to Adventure!! Would you like instructions?

YES
Somewhere nearby is Colossal Cave, where others have found fortunes
in treasure and gold,though it is rumored that some who enter are never
seen again. Magic is said to work in the cave. I will be your eyes
and hands. Direct me with commands of 1 or 2 words. I should warn
you that I look at only the first four letters of each word,so you'll
have to enter "northeast" as "ne" to distinguish it from "north".
(Should you get stuck, type "help" for some general hints. For
information on how to end your adventure, etc., type "INFO".)
- - -
This program was originally developed by Willie Crowther. Most of
the features of the current program were added by Don Woods.
This version, for the PDP-8, was done by Dick Murphy. it is
based on a version for RT-11 done by Bob Supnik.


From IanK at vulcan.com  Mon Mar 11 21:00:18 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 12 Mar 2013 01:00:18 +0000
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D77AE0@505MBX2.corp.vnw.com>

Hi folks, 

I'm doing some work where I need to build some DECtapes for a PDP-10,
using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
emulated TC08/TU56.  The emulator simply hangs.  I also tried just
creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
resulting in a hang.

Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
recognized on SIMH?  :-)  Thanks -- Ian

I'm done with this two-bit town.  Show me a twelve-bit town ­ now we're
talking.  

Ian S. King, Sr. Vintage Systems Engineer
Living Computer Museum
A presentation of Vulcan, Inc.
http://www.livingcomputermuseum.org



From IanK at vulcan.com  Tue Mar 12 00:53:23 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 12 Mar 2013 04:53:23 +0000
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D77AE0@505MBX2.corp.vnw.com>
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>

On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:

>Hi folks, 
>
>I'm doing some work where I need to build some DECtapes for a PDP-10,
>using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>resulting in a hang.
>
>Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>recognized on SIMH?  :-)  Thanks -- Ian
>
>I'm done with this two-bit town.  Show me a twelve-bit town ­ now we're
>talking.  
>
>Ian S. King, Sr. Vintage Systems Engineer
>Living Computer Museum
>A presentation of Vulcan, Inc.
>http://www.livingcomputermuseum.org
>
>_______________________________________________
>Simh mailing list
>Simh at trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>

To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
emulation, using PIP10.  A couple of (thank you so much) replies made me
realize my statement of the problem was ambiguous.  -- Ian 


From bqt at softjar.se  Tue Mar 12 06:50:17 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 12 Mar 2013 11:50:17 +0100
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
References: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
Message-ID: <513F0869.10300@softjar.se>

On 2013-03-12 05:53, Ian King wrote:
> On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:
> 
>> Hi folks,
>>
>> I'm doing some work where I need to build some DECtapes for a PDP-10,
>> using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>> some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>> emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>> creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>> resulting in a hang.
>>
>> Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>> recognized on SIMH?  :-)  Thanks -- Ian
>>
>> I'm done with this two-bit town.  Show me a twelve-bit town ­ now we're
>> talking.
>>
>> Ian S. King, Sr. Vintage Systems Engineer
>> Living Computer Museum
>> A presentation of Vulcan, Inc.
>> http://www.livingcomputermuseum.org
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
> 
> To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
> emulation, using PIP10.  A couple of (thank you so much) replies made me
> realize my statement of the problem was ambiguous.  -- Ian

I understood you the first time. My big question would be if you are
sure the TC08 emulation is good enough. PIP10 uses its own code to
handle the drive, and uses it in ways no other PDP8 code likely do. It
definitely would test the emulation much harder than anything else I can
think of.

	Johnny

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


From bqt at softjar.se  Tue Mar 12 07:40:33 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 12 Mar 2013 12:40:33 +0100
Subject: [Simh] DECtape simulation for 36b tapes on PDP-8?
In-Reply-To: <513F0869.10300@softjar.se>
References: <2F25BE3D5F64F342B56139F31854C9B998D77DCA@505MBX2.corp.vnw.com>
 <513F0869.10300@softjar.se>
Message-ID: <513F1431.6000505@softjar.se>

On 2013-03-12 11:50, Johnny Billquist wrote:
> On 2013-03-12 05:53, Ian King wrote:
>> On 3/11/13 6:00 PM, "Ian King" <IanK at vulcan.com> wrote:
>>
>>> Hi folks,
>>>
>>> I'm doing some work where I need to build some DECtapes for a PDP-10,
>>> using a PDP-8 and PIP10.  Long story short, I decided to use SIMH to test
>>> some ideas but I cannot access a PDP-10-formatted DECtape mounted on the
>>> emulated TC08/TU56.  The emulator simply hangs.  I also tried just
>>> creating a new 'tape' in 18/36b mode and looking at it with PIP10, again
>>> resulting in a hang.
>>>
>>> Do you know of a way to hold one's mouth to get a PDP-10 DECtape to be
>>> recognized on SIMH?  :-)  Thanks -- Ian
>>>
>>> I'm done with this two-bit town.  Show me a twelve-bit town ­ now we're
>>> talking.
>>>
>>> Ian S. King, Sr. Vintage Systems Engineer
>>> Living Computer Museum
>>> A presentation of Vulcan, Inc.
>>> http://www.livingcomputermuseum.org
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>>
>>
>> To clarify: I'm trying to access PDP-10-formatted DECtape on the PDP-8
>> emulation, using PIP10.  A couple of (thank you so much) replies made me
>> realize my statement of the problem was ambiguous.  -- Ian
> 
> I understood you the first time. My big question would be if you are
> sure the TC08 emulation is good enough. PIP10 uses its own code to
> handle the drive, and uses it in ways no other PDP8 code likely do. It
> definitely would test the emulation much harder than anything else I can
> think of.

By the way, another question is how your PDP-10 formatted tapes got onto
the host running simh, and connected to the simulated TU56. Did you have
some real PDP-10 DECtapes that you transferred somehow? If so, then how?
Or did you get them using some PDP-10 simulator to create them on a
smimulated DECtape on the ten side?
Are the simulated tape format in the files compatible? Exactly how do
the format look like? DECtape as such have a rather free form in some
ways. It's not totally clear to me in which way I would represent these
tapes on disk in a way that would allow me to operate correctly on them.
Especially if we want to deal with both 12-bit and 18-bit formatted
tapes. This can get rather hairy. On the real systems, this is mostly
done in hardware, but it is rather fiddly.

	Johnny

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


From aek at bitsavers.org  Thu Mar 14 14:24:15 2013
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 14 Mar 2013 11:24:15 -0700
Subject: [Simh] Fwd: SimH, PDP8 OS/8 and RKLFMT hang
In-Reply-To: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
References: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
Message-ID: <514215CF.6090803@bitsavers.org>

forwarded from the classiccmp mailing list


-------- Original Message --------
Subject: SimH, PDP8 OS/8 and RKLFMT hang
Date: Thu, 14 Mar 2013 11:03:47 -0700
From: Rick Bensene <rickb at bensene.com>
Reply-To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>

I'm running SimH V3.9 on a PC under Windows 7  using the binaries from
the primary SimH website.
I'm running the OS8 distribution on floppy that is packaged on the Simh
site.
I attached an 'empty' RK disk drive file as RK0, and tried to run RKLFMT
on it to "format" the drive.
The RKLFMT program asks its questions (which drives to format), then
says "ARE YOU SURE?" and expects a Y or N.  If N is typed, the questions
about which drives to format are repeated.  If Y is typed, the
formatting process begins.

On real PDP8/e hardware, it all does what it is supposed to...the drive
does a bunch of writes, then goes back and reads the sectors to verify
that they were written correctly, then prints out a message indicating
that the format passes are complete, and then starts over with the
"which disks to format" question, at which point you can type ^C to
exit.

However, in SimH, the program starts up and asks which drives to format,
and I say "Y" to drive 0, and "N" to the other 7 drives, then the "ARE
YOU SURE?" prompt comes up, and I type "Y", and the Y echoes back, and
then  it just sits there.
On real hardware, it takes about 80 seconds to format a drive.  I waited
MUCH longer than this to see if the simulated RKLFMT would eventually
come back indicating that it had completed.  It didn't.

I used ^E to interrupt the execution, and stepped through a few
instructions, and it appears to be hung in a loop waiting for the disk
drive to do something.  I checked to see if the disk file holding the
emulated RK05 drive had changed in size, and it was still at 0 bytes.

The RKLFMT program uses the RK8E disk controller's "WRITE ALL" and "READ
ALL" functions to format and verify the drive.  These RK8E commands
ignore header information on the sectors, and just writes/reads the
data, as opposed to the normal READ and WRITE commands that pay
attention to the sector header information.

I am wondering if perhaps the SimH emulation of the RK8E is flawed in
some way such that the READ ALL and WRITE ALL commands don't work
properly, causing RKLFMT to fail.

I can get the emulated RK05 to work by simply issuing a "ZERO RKA0:"
command to OS8, which writes the directory information on the disk,
making it accessible to OS8.

Has anyone run into this before?  It isn't a big deal in terms of
usability of emulated RK05s in the PDP 8 SimH implementation, but I'm
wondering if it might be a technical detail in the emulation  of the
RK8E that isn't quite correct.

I'd be interesting in hearing anything that folks may have run into or
heard about this.

Thanks,
Rick Bensene








From Mark at infocomm.com  Thu Mar 14 16:34:03 2013
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 14 Mar 2013 13:34:03 -0700
Subject: [Simh] Fwd: SimH, PDP8 OS/8 and RKLFMT hang
In-Reply-To: <514215CF.6090803@bitsavers.org>
References: <B9639BAE3F34504E83FEEDD71D4AFB465AEE47@mail.bensene.com>
 <514215CF.6090803@bitsavers.org>
Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E6884B18A@REDROOF2.alohasunset.com>

On Thursday, March 14, 2013 at 11:24 AM, Al Kossow wrote:
> forwarded from the classiccmp mailing list
> 
> 
> -------- Original Message --------
> Subject: SimH, PDP8 OS/8 and RKLFMT hang
> Date: Thu, 14 Mar 2013 11:03:47 -0700
> From: Rick Bensene <rickb at bensene.com>
> Reply-To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> 
> I'm running SimH V3.9 on a PC under Windows 7  using the binaries from the
> primary SimH website.
> I'm running the OS8 distribution on floppy that is packaged on the Simh site.
> I attached an 'empty' RK disk drive file as RK0, and tried to run RKLFMT on it
> to "format" the drive.
> The RKLFMT program asks its questions (which drives to format), then says
> "ARE YOU SURE?" and expects a Y or N.  If N is typed, the questions about
> which drives to format are repeated.  If Y is typed, the formatting process
> begins.
> 
> On real PDP8/e hardware, it all does what it is supposed to...the drive does a
> bunch of writes, then goes back and reads the sectors to verify that they
> were written correctly, then prints out a message indicating that the format
> passes are complete, and then starts over with the "which disks to format"
> question, at which point you can type ^C to exit.
> 
> However, in SimH, the program starts up and asks which drives to format,
> and I say "Y" to drive 0, and "N" to the other 7 drives, then the "ARE YOU
> SURE?" prompt comes up, and I type "Y", and the Y echoes back, and then  it
> just sits there.
> On real hardware, it takes about 80 seconds to format a drive.  I waited
> MUCH longer than this to see if the simulated RKLFMT would eventually
> come back indicating that it had completed.  It didn't.

Hi Rick,

Great description.  100% reproducible.

The issue was that the initial RK disk operation was completing too quickly.  Changing RK_MIN from 10 to 45 allows things to work as expected.

The problem is fixed in the latest source at https://github.com/simh/simh/archive/master.zip

Pre Compiled binaries are available at:  https://github.com/simh/Win32-Development-Binaries/blob/Win32-Development-Binaries/simh-4.0-Beta--2013-03-14-b06505ab.zip

- Mark





From bob at supnik.org  Mon Mar 18 12:44:44 2013
From: bob at supnik.org (Bob Supnik)
Date: Mon, 18 Mar 2013 12:44:44 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
Message-ID: <5147447C.9000501@supnik.org>

I was trying to get a debug setup for PIP10, per Ian King's mail, when I 
discovered that none of my OS/8 images have PIP10 on them. This 
certainly explains why the feature has never been tested before. I 
suspect that ReadAll and WriteAll either are not working at all, or are 
not working when the DECtape format is 18b. Another possibility is that 
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty 
level (format of headers and trailers).

If anyone has a canned OS/8 V3C image with PIP10, please post it 
somewhere (like Mediafire) and let me know by email.

Thanks,

/Bob Supnik



From litt at ieee.org  Mon Mar 18 13:20:03 2013
From: litt at ieee.org (Timothe Litt)
Date: Mon, 18 Mar 2013 13:20:03 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147447C.9000501@supnik.org>
References: <5147447C.9000501@supnik.org>
Message-ID: <51474CC3.5040408@ieee.org>

Well, there's 
http://www.filewatcher.com/b/ftp/sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8-0.html, 
which has V3d (and sources)...

This communication may not represent my employer's views,
if any, on the matters discussed.

On 18-Mar-13 12:44, Bob Supnik wrote:
> I was trying to get a debug setup for PIP10, per Ian King's mail, when 
> I discovered that none of my OS/8 images have PIP10 on them. This 
> certainly explains why the feature has never been tested before. I 
> suspect that ReadAll and WriteAll either are not working at all, or 
> are not working when the DECtape format is 18b. Another possibility is 
> that PDP-10 DECtape format is not the same as 18b format, at the 
> nitty-gritty level (format of headers and trailers).
>
> If anyone has a canned OS/8 V3C image with PIP10, please post it 
> somewhere (like Mediafire) and let me know by email.
>
> Thanks,
>
> /Bob Supnik
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130318/9b6836b6/attachment-0002.bin>

From bqt at softjar.se  Mon Mar 18 16:26:52 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Mon, 18 Mar 2013 21:26:52 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147447C.9000501@supnik.org>
References: <5147447C.9000501@supnik.org>
Message-ID: <5147788C.2090901@softjar.se>

On 2013-03-18 17:44, Bob Supnik wrote:
> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
> discovered that none of my OS/8 images have PIP10 on them. This
> certainly explains why the feature has never been tested before. I
> suspect that ReadAll and WriteAll either are not working at all, or are
> not working when the DECtape format is 18b. Another possibility is that
> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
> level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same 
on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) 
words, however, while a PDP-10 (or any other 18-bitter) would have 128 
18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way 
that is rather different from an 18-bit machine. But at the tape as 
such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in 
manuals, but in essence a DECtape is always doing 18-bit words. That is 
done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means 
that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is 
formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, 
and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months 
ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had 
actually been written on a PDP-15, I had to write my own code in the 
end, to just dump the raw data.

> If anyone has a canned OS/8 V3C image with PIP10, please post it
> somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, 
including sources (if I remember right) somewhere. Let me know if it 
can't be located anywhere else.

	Johnny



From litt at ieee.org  Tue Mar 19 09:03:15 2013
From: litt at ieee.org (Timothe Litt)
Date: Tue, 19 Mar 2013 09:03:15 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <5147788C.2090901@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
Message-ID: <51486213.8040508@ieee.org>

> The DECtape format as such, with all the headers and so on, is the 
> same on all tapes. A normal PDP-8 formatted tape will have 129 
> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would 
> have 128 18-bit words (if I remember right). 
Pretty much right.  129 may be slightly misleading.  The format is 129, 
but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) 
formatted DECtape would have 578 blocks of 128 36-bit words.  (256 
18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't 
contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data. The 
directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH 
= first block & words used in this block) + 127 words of payload.  This 
differed from disk files, where all 128 words were payload, so 
inattentive programmers could make a number of mistakes.  (E.g. random 
access block isn't word/128; you had to pay attention to the buffer's 
word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the 
drive to stop and restart while reading or writing without having to 
reverse direction.  The spacing depended on what blocks were free when 
files were written, and the data mode.  (Files written in 'core dump' 
modes were assumed to be read by the monitor without stopping, so the 
gap was smaller, allowing larger programs to be read without reversing 
direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word 
(except when reading PDP-10 tapes; the hardware for that was tricky as 
the high bits had to be read with programmed IO; the low 16 were DMAed 
on the TC-11.)

The low-level formatting that established the mark track, end zones and 
block delimiters was done via a stand-alone diagnostic. This differs 
between the two formats.  The directory block could be initialized under 
timesharing.

Directory structure given is for the PDP-10; other OSs used different 
formats.

 From an emulation point of view, the PDP-10's controller was the most 
interesting; the driver does dead reckoning; that is, it will start a 
drive spinning for a seek, disconnect, service other drives, and 
reconnect just before the desired block is expected to be over the read 
head.  So real-world timing matters.  The other controllers (and thus 
OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct 
link 
isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ 
Sorry if this was confusing.

Of potential interest to low-level folks is 
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 18-Mar-13 16:26, Johnny Billquist wrote:
> On 2013-03-18 17:44, Bob Supnik wrote:
>> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
>> discovered that none of my OS/8 images have PIP10 on them. This
>> certainly explains why the feature has never been tested before. I
>> suspect that ReadAll and WriteAll either are not working at all, or are
>> not working when the DECtape format is 18b. Another possibility is that
>> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
>> level (format of headers and trailers).
>
> The DECtape format as such, with all the headers and so on, is the 
> same on all tapes. A normal PDP-8 formatted tape will have 129 
> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would 
> have 128 18-bit words (if I remember right).
> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way 
> that is rather different from an 18-bit machine. But at the tape as 
> such, there is nothing odd about it.
>
> But I can see lots of potential for errors when emulating this whole 
> thing.
>
> I couldn't give exact details on lots of bits without looking in 
> manuals, but in essence a DECtape is always doing 18-bit words. That 
> is done by doing 6 groups of 3 bits each.
> A PDP-8 will pack three 12-bit words into two 18-bit words. This means 
> that a DECtape block for a PDP-8 will only have 86 18-bit words.
> So the blocks are shorter, but you have more of them, when the tape is 
> formatted for a PDP-8.
>
> I hope (assume) that you already know all of this. If not, let me 
> know, and I can try helping out some more.
> I actually did dump a few 18-bit tapes on my PDP-8 only a few months 
> ago, which is when I actually had to dig rather deep into all of this.
> PIP10 was one of the things I really looked into. But since my tapes 
> had actually been written on a PDP-15, I had to write my own code in 
> the end, to just dump the raw data.
>
>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>> somewhere (like Mediafire) and let me know by email.
>
> I think someone already posted this, but I know I have that software, 
> including sources (if I remember right) somewhere. Let me know if it 
> can't be located anywhere else.
>
>     Johnny
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/57ae2877/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/57ae2877/attachment-0002.bin>

From bqt at softjar.se  Tue Mar 19 09:25:25 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 14:25:25 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486213.8040508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
Message-ID: <51486745.3010802@softjar.se>

On 2013-03-19 14:03, Timothe Litt wrote:
>> The DECtape format as such, with all the headers and so on, is the
>> same on all tapes. A normal PDP-8 formatted tape will have 129
>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>> have 128 18-bit words (if I remember right).
> Pretty much right.  129 may be slightly misleading.  The format is 129,
> but the -8 used  only 128 of the 129 12-bit words/block for data.

Right. :-)

> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
> formatted DECtape would have 578 blocks of 128 36-bit words.  (256
> 18-bit words at the hardware level.)

I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape 
as such, which physically always stores 18 bits. A PDP-10 would 
obviously store its 36-bit words using two DECtape words. Any 18-bit 
machine is straight forward, while the PDP-11 (as you mention below) 
only use 16 bits of the 18-bit word.

I thought it was 128 18-bit words, but I may well remember that wrong, 
and the "normal" format is 256 18-bit words. Makes sense, when I think 
about it.

The number of blocks is not absolutely fixed, but 578 is the "standard" 
except on the PDP-8, I guess.

> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
> contain user data.

That would be very depending on which machine we're talking about, and 
which controller... :-) But I assume you're talking about the PDP-10 
here. Did all PDP-10 with DECtapes use the same controller? I assume 
both the KA and KI had DECtapes, as well as the PDP-6.

> Block 100 is the directory block.  Thus 574 blocks for user data. The
> directory holds up to 22 files, plus a map of which file owns each block.
>
> The user data blocks have a one word header (LH = next block of file; RH
> = first block & words used in this block) + 127 words of payload.  This
> differed from disk files, where all 128 words were payload, so
> inattentive programmers could make a number of mistakes.  (E.g. random
> access block isn't word/128; you had to pay attention to the buffer's
> word count, etc.)
>
> Data blocks of a file are (usually) not contiguous; this allowed the
> drive to stop and restart while reading or writing without having to
> reverse direction.  The spacing depended on what blocks were free when
> files were written, and the data mode.  (Files written in 'core dump'
> modes were assumed to be read by the monitor without stopping, so the
> gap was smaller, allowing larger programs to be read without reversing
> direction.)
>
> The gory details of the format are in the Monitor Calls manual (TOPS-10).

TOPS-10 DECtape format is definitely not something I know anything 
about. But thanks for the rundown.

> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
> (except when reading PDP-10 tapes; the hardware for that was tricky as
> the high bits had to be read with programmed IO; the low 16 were DMAed
> on the TC-11.)

Yes! Thanks for bringing another murky memory.

> The low-level formatting that established the mark track, end zones and
> block delimiters was done via a stand-alone diagnostic. This differs
> between the two formats.  The directory block could be initialized under
> timesharing.

Um? What two formats?

> Directory structure given is for the PDP-10; other OSs used different
> formats.
>
>  From an emulation point of view, the PDP-10's controller was the most
> interesting; the driver does dead reckoning; that is, it will start a
> drive spinning for a seek, disconnect, service other drives, and
> reconnect just before the desired block is expected to be over the read
> head.  So real-world timing matters.  The other controllers (and thus
> OSs) didn't support this.

Wow. The TC08 actually did seeks while actually looking at the tape, and 
then did DMA as well. So you didn't have to pay any more attention than 
to a disk controller.
Essentially, you asked it to seek, and it indicated when the seek was 
done. You asked it to read, and it read.
As far as I can remember, the TC11 is the same.
Not sure what you mean by "other controllers didn't support this". What 
is "this". Doing dead reckoning? Why would you actually want to do dead 
reckoning. It makes much more sense to actually look at the tape the 
whole time it is spinning by, and not only when you are getting close to 
where you want to be. And the hardware can do that without your involvement.

In a way, however, I'd say that the TD8E is the most "interesting" 
controller to emulate, since it is so incredibly stupid that you 
actually have to emulate the low level format of the tape for that 
controller to work.
It is truly ugly. And that controller was a headache if you ever wanted 
to use it in a timesharing operating system, since it did not do DMA, it 
did not really do seeks, or in fact anything at all except just feed the 
bits from the tape to the computer as they whizzed by.

> Oh, all numbers above are radix 10.

What's wrong with you. ;-)

> The link for OS8 that I posted yesterday was via filewatcher; the direct
> link
> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
> Sorry if this was confusing.
>
> Of potential interest to low-level folks is
> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>
> Hope this is useful.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.

Thanks for all the interesting bits and pieces.

	Johnny

>
> On 18-Mar-13 16:26, Johnny Billquist wrote:
>> On 2013-03-18 17:44, Bob Supnik wrote:
>>> I was trying to get a debug setup for PIP10, per Ian King's mail, when I
>>> discovered that none of my OS/8 images have PIP10 on them. This
>>> certainly explains why the feature has never been tested before. I
>>> suspect that ReadAll and WriteAll either are not working at all, or are
>>> not working when the DECtape format is 18b. Another possibility is that
>>> PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
>>> level (format of headers and trailers).
>>
>> The DECtape format as such, with all the headers and so on, is the
>> same on all tapes. A normal PDP-8 formatted tape will have 129
>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>> have 128 18-bit words (if I remember right).
>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>> that is rather different from an 18-bit machine. But at the tape as
>> such, there is nothing odd about it.
>>
>> But I can see lots of potential for errors when emulating this whole
>> thing.
>>
>> I couldn't give exact details on lots of bits without looking in
>> manuals, but in essence a DECtape is always doing 18-bit words. That
>> is done by doing 6 groups of 3 bits each.
>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>> So the blocks are shorter, but you have more of them, when the tape is
>> formatted for a PDP-8.
>>
>> I hope (assume) that you already know all of this. If not, let me
>> know, and I can try helping out some more.
>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>> ago, which is when I actually had to dig rather deep into all of this.
>> PIP10 was one of the things I really looked into. But since my tapes
>> had actually been written on a PDP-15, I had to write my own code in
>> the end, to just dump the raw data.
>>
>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>> somewhere (like Mediafire) and let me know by email.
>>
>> I think someone already posted this, but I know I have that software,
>> including sources (if I remember right) somewhere. Let me know if it
>> can't be located anywhere else.
>>
>>     Johnny
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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


From Jason.Armistead at otis.com  Tue Mar 19 09:30:07 2013
From: Jason.Armistead at otis.com (Armistead, Jason)
Date: Tue, 19 Mar 2013 13:30:07 +0000
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486213.8040508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>

I had trouble with Timothe’s link to the USPTO, but found this same patent in PDF form at

http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf

As a relative newbie who started my serious journey into computing with an Apple ][  I’ve never fully understood DEC’s fascination with word lengths that weren’t multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer – mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN).  Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words.  All I’ve ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!)

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh at trailing-edge.com
Subject: Re: [Simh] PIP10 on PDP-8 SIM

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
Pretty much right.  129 may be slightly misleading.  The format is 129, but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words.  (256 18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data.  The directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload.  This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes.  (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction.  The spacing depended on what blocks were free when files were written, and the data mode.  (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.)

The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic.  This differs between the two formats.  The directory block could be initialized under timesharing.

Directory structure given is for the PDP-10; other OSs used different formats.

>From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head.  So real-world timing matters.  The other controllers (and thus OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing.

Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.



This communication may not represent my employer's views,

if any, on the matters discussed.
On 18-Mar-13 16:26, Johnny Billquist wrote:
On 2013-03-18 17:44, Bob Supnik wrote:

I was trying to get a debug setup for PIP10, per Ian King's mail, when I
discovered that none of my OS/8 images have PIP10 on them. This
certainly explains why the feature has never been tested before. I
suspect that ReadAll and WriteAll either are not working at all, or are
not working when the DECtape format is 18b. Another possibility is that
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to write my own code in the end, to just dump the raw data.


If anyone has a canned OS/8 V3C image with PIP10, please post it
somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, including sources (if I remember right) somewhere. Let me know if it can't be located anywhere else.

    Johnny

_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/05720b28/attachment-0002.html>

From bqt at softjar.se  Tue Mar 19 09:43:10 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 14:43:10 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
Message-ID: <51486B6E.7080304@softjar.se>

On 2013-03-19 14:30, Armistead, Jason wrote:
> I had trouble with Timothe’s link to the USPTO, but found this same
> patent in PDF form at
>
> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>
> As a relative newbie who started my serious journey into computing with
> an Apple ][  I’ve never fully understood DEC’s fascination with word
> lengths that weren’t multiples of 2 (even though I dabbled with the
> PDP-11s at the local council my father worked at as a civil engineer –
> mainly to play Mugwump and Wumpus after giving up on trying to learn
> FORTRAN).  Maybe someone can give a brief history behind the 12-bit,
> 18-bit and 36-bit sizing of words.  All I’ve ever had to deal with are
> 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I
> do remember the 4004 !!!)

It wasn't just DEC. Back in the day, most everyone used various word 
lengths that wasn't a power of two. I can't really make many comments on 
why other word lengths were more popular. I've seen mentioned that 
floating point formats was pretty nice to do with something like 60 or 
72 bits. Reason being that you had large enough exponents for useful 
things, and enough precision for most calculations.
So a word length that related to this made sense.

Number of bits being a power of two started with IBM in the 60s, and 
became common with the PDP-11 in the 70s. (Or so I'd like to think.)

	Johnny

>
> *From:*simh-bounces at trailing-edge.com
> [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *Timothe Litt
> *Sent:* Tuesday, 19 March 2013 9:03 AM
> *To:* simh at trailing-edge.com
> *Subject:* Re: [Simh] PIP10 on PDP-8 SIM
>
>     The DECtape format as such, with all the headers and so on, is the
>     same on all tapes. A normal PDP-8 formatted tape will have 129
>     (12-bit) words, however, while a PDP-10 (or any other 18-bitter)
>     would have 128 18-bit words (if I remember right).
>
> Pretty much right.  129 may be slightly misleading.  The format is 129,
> but the -8 used  only 128 of the 129 12-bit words/block for data.
>
> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
> formatted DECtape would have 578 blocks of 128 36-bit words.  (256
> 18-bit words at the hardware level.)
>
> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
> contain user data.
>
> Block 100 is the directory block.  Thus 574 blocks for user data.  The
> directory holds up to 22 files, plus a map of which file owns each block.
>
> The user data blocks have a one word header (LH = next block of file; RH
> = first block & words used in this block) + 127 words of payload.  This
> differed from disk files, where all 128 words were payload, so
> inattentive programmers could make a number of mistakes. (E.g. random
> access block isn't word/128; you had to pay attention to the buffer's
> word count, etc.)
>
> Data blocks of a file are (usually) not contiguous; this allowed the
> drive to stop and restart while reading or writing without having to
> reverse direction.  The spacing depended on what blocks were free when
> files were written, and the data mode.  (Files written in 'core dump'
> modes were assumed to be read by the monitor without stopping, so the
> gap was smaller, allowing larger programs to be read without reversing
> direction.)
>
> The gory details of the format are in the Monitor Calls manual (TOPS-10).
>
> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
> (except when reading PDP-10 tapes; the hardware for that was tricky as
> the high bits had to be read with programmed IO; the low 16 were DMAed
> on the TC-11.)
>
> The low-level formatting that established the mark track, end zones and
> block delimiters was done via a stand-alone diagnostic.  This differs
> between the two formats.  The directory block could be initialized under
> timesharing.
>
> Directory structure given is for the PDP-10; other OSs used different
> formats.
>
>  From an emulation point of view, the PDP-10's controller was the most
> interesting; the driver does dead reckoning; that is, it will start a
> drive spinning for a seek, disconnect, service other drives, and
> reconnect just before the desired block is expected to be over the read
> head.  So real-world timing matters.  The other controllers (and thus
> OSs) didn't support this.
>
> Oh, all numbers above are radix 10.
>
> The link for OS8 that I posted yesterday was via filewatcher; the direct
> link
> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
> <ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/>
> Sorry if this was confusing.
>
> Of potential interest to low-level folks is
> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>
> Hope this is useful.
>
>
> This communication may not represent my employer's views,
>
> if any, on the matters discussed.
>
> On 18-Mar-13 16:26, Johnny Billquist wrote:
>
>     On 2013-03-18 17:44, Bob Supnik wrote:
>
>     I was trying to get a debug setup for PIP10, per Ian King's mail,
>     when I
>     discovered that none of my OS/8 images have PIP10 on them. This
>     certainly explains why the feature has never been tested before. I
>     suspect that ReadAll and WriteAll either are not working at all, or are
>     not working when the DECtape format is 18b. Another possibility is that
>     PDP-10 DECtape format is not the same as 18b format, at the
>     nitty-gritty
>     level (format of headers and trailers).
>
>
>     The DECtape format as such, with all the headers and so on, is the
>     same on all tapes. A normal PDP-8 formatted tape will have 129
>     (12-bit) words, however, while a PDP-10 (or any other 18-bitter)
>     would have 128 18-bit words (if I remember right).
>     The PDP-8, when doing 12-bit formatted tapes, just packs data in a
>     way that is rather different from an 18-bit machine. But at the tape
>     as such, there is nothing odd about it.
>
>     But I can see lots of potential for errors when emulating this whole
>     thing.
>
>     I couldn't give exact details on lots of bits without looking in
>     manuals, but in essence a DECtape is always doing 18-bit words. That
>     is done by doing 6 groups of 3 bits each.
>     A PDP-8 will pack three 12-bit words into two 18-bit words. This
>     means that a DECtape block for a PDP-8 will only have 86 18-bit words.
>     So the blocks are shorter, but you have more of them, when the tape
>     is formatted for a PDP-8.
>
>     I hope (assume) that you already know all of this. If not, let me
>     know, and I can try helping out some more.
>     I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>     ago, which is when I actually had to dig rather deep into all of this.
>     PIP10 was one of the things I really looked into. But since my tapes
>     had actually been written on a PDP-15, I had to write my own code in
>     the end, to just dump the raw data.
>
>
>     If anyone has a canned OS/8 V3C image with PIP10, please post it
>     somewhere (like Mediafire) and let me know by email.
>
>
>     I think someone already posted this, but I know I have that
>     software, including sources (if I remember right) somewhere. Let me
>     know if it can't be located anywhere else.
>
>          Johnny
>
>     _______________________________________________
>     Simh mailing list
>     Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>     http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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


From tshoppa at wmata.com  Tue Mar 19 09:47:37 2013
From: tshoppa at wmata.com (Shoppa, Tim)
Date: Tue, 19 Mar 2013 13:47:37 +0000
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
Message-ID: <303A17BD5F8FA34DA45EEC245271AC0B7434C07E@JGEX2K10MBX2.wmata.local>

Non-power-of-2 word sizes are in many applications today. 12- and 14-bit instruction width PIC processors are sold by the billions.  24-bit data width DSP's are extremely common, and other sizes including
28-bit, 36-bit, 48-bit, and 56-bit data widths abound in DSP audio/video processing and other applications.

Tim.

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason
Sent: Tuesday, March 19, 2013 9:30 AM
To: simh at trailing-edge.com
Subject: Re: [Simh] PIP10 on PDP-8 SIM

I had trouble with Timothe's link to the USPTO, but found this same patent in PDF form at

http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf

As a relative newbie who started my serious journey into computing with an Apple ][  I've never fully understood DEC's fascination with word lengths that weren't multiples of 2 (even though I dabbled with the PDP-11s at the local council my father worked at as a civil engineer - mainly to play Mugwump and Wumpus after giving up on trying to learn FORTRAN).  Maybe someone can give a brief history behind the 12-bit, 18-bit and 36-bit sizing of words.  All I've ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their O/S. (But yes, I do remember the 4004 !!!)

From: simh-bounces at trailing-edge.com<mailto:simh-bounces at trailing-edge.com> [mailto:simh-bounces at trailing-edge.com] On Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: Re: [Simh] PIP10 on PDP-8 SIM

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
Pretty much right.  129 may be slightly misleading.  The format is 129, but the -8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) formatted DECtape would have 578 blocks of 128 36-bit words.  (256 18-bit words at the hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain user data.

Block 100 is the directory block.  Thus 574 blocks for user data.  The directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH = first block & words used in this block) + 127 words of payload.  This differed from disk files, where all 128 words were payload, so inattentive programmers could make a number of mistakes.  (E.g. random access block isn't word/128; you had to pay attention to the buffer's word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the drive to stop and restart while reading or writing without having to reverse direction.  The spacing depended on what blocks were free when files were written, and the data mode.  (Files written in 'core dump' modes were assumed to be read by the monitor without stopping, so the gap was smaller, allowing larger programs to be read without reversing direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except when reading PDP-10 tapes; the hardware for that was tricky as the high bits had to be read with programmed IO; the low 16 were DMAed on the TC-11.)

The low-level formatting that established the mark track, end zones and block delimiters was done via a stand-alone diagnostic.  This differs between the two formats.  The directory block could be initialized under timesharing.

Directory structure given is for the PDP-10; other OSs used different formats.

>From an emulation point of view, the PDP-10's controller was the most interesting; the driver does dead reckoning; that is, it will start a drive spinning for a seek, disconnect, service other drives, and reconnect just before the desired block is expected to be over the read head.  So real-world timing matters.  The other controllers (and thus OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct link is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry if this was confusing.

Of potential interest to low-level folks is http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293

Hope this is useful.


This communication may not represent my employer's views,

if any, on the matters discussed.
On 18-Mar-13 16:26, Johnny Billquist wrote:
On 2013-03-18 17:44, Bob Supnik wrote:
I was trying to get a debug setup for PIP10, per Ian King's mail, when I
discovered that none of my OS/8 images have PIP10 on them. This
certainly explains why the feature has never been tested before. I
suspect that ReadAll and WriteAll either are not working at all, or are
not working when the DECtape format is 18b. Another possibility is that
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same on all tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is rather different from an 18-bit machine. But at the tape as such, there is nothing odd about it.

But I can see lots of potential for errors when emulating this whole thing.

I couldn't give exact details on lots of bits without looking in manuals, but in essence a DECtape is always doing 18-bit words. That is done by doing 6 groups of 3 bits each.
A PDP-8 will pack three 12-bit words into two 18-bit words. This means that a DECtape block for a PDP-8 will only have 86 18-bit words.
So the blocks are shorter, but you have more of them, when the tape is formatted for a PDP-8.

I hope (assume) that you already know all of this. If not, let me know, and I can try helping out some more.
I actually did dump a few 18-bit tapes on my PDP-8 only a few months ago, which is when I actually had to dig rather deep into all of this.
PIP10 was one of the things I really looked into. But since my tapes had actually been written on a PDP-15, I had to write my own code in the end, to just dump the raw data.

If anyone has a canned OS/8 V3C image with PIP10, please post it
somewhere (like Mediafire) and let me know by email.

I think someone already posted this, but I know I have that software, including sources (if I remember right) somewhere. Let me know if it can't be located anywhere else.

    Johnny

_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/cd973e66/attachment-0002.html>

From litt at ieee.org  Tue Mar 19 09:56:02 2013
From: litt at ieee.org (Timothe Litt)
Date: Tue, 19 Mar 2013 09:56:02 -0400
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486745.3010802@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org> <51486745.3010802@softjar.se>
Message-ID: <51486E72.4010508@ieee.org>


This communication may not represent my employer's views,
if any, on the matters discussed.

Consider a timesharing system, with 4 users each trying to transfer from 
their own DTA.  With a TC11, you serviced user 1, user, 3, user 4, user 
2 sequentially.   The controller was tied up for the whole seek for each 
user - potentially from one end of the tape to the other.

The TD10-'s dead reckoning allowed  the seeks to proceed in parallel.  
E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by 
the controller.  When the shortest seek was near completion, the driver 
would tell the controller to pay attention to that drive ('connect'), do 
the transfer, and stop.  Then the next.  Besides being impressive to 
watch (8 drives spinning in various directions), the user request 
latency was reduced.   (Some systems had two controllers, for 16 drives!)

The KA, KI and KL (with the IO Bus adapter) all used the TD10 
controller.  The -6 had another controller - type 551.  I think it was a 
dumb controller, but didn't use it personally.

129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats.  
Gory details of the TD10 are at

http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/DEC-10-I3AA-D%20TD10%20DECtape%20Control%20Maintenance%20Manual.pdf

Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the 
format info I provided was for the 10.  TOPS-10.  MAC had another format 
for the -6.  TOPS-20 didn't officially support DECtapes, but internally 
we had systems with them.  They used the PDP-10 format.

Much of the pdp-10 format documentation is a mixture of octal and 
decimal.  I picked decimal because these days, thinking in octal is a 
(mostly) lost art.

IBM and many other vendors used 36-bits, because the (BCD) character 
codes of the day were 6-bits, so it packed nicely.  The -8 was 12 bits 
for the same reason, only it was cheaper to build.

The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii, 
8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.

The -11 was designed after 8-bit character codes became popular. EBCDIC 
was (and is) an ugly mess; ASCII cemented 8-bit character codes.  And 
machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the 
most popular.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 19-Mar-13 09:25, Johnny Billquist wrote:
> On 2013-03-19 14:03, Timothe Litt wrote:
>>> The DECtape format as such, with all the headers and so on, is the
>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>> have 128 18-bit words (if I remember right).
>> Pretty much right.  129 may be slightly misleading.  The format is 129,
>> but the -8 used  only 128 of the 129 12-bit words/block for data.
>
> Right. :-)
>
>> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
>> formatted DECtape would have 578 blocks of 128 36-bit words. (256
>> 18-bit words at the hardware level.)
>
> I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape 
> as such, which physically always stores 18 bits. A PDP-10 would 
> obviously store its 36-bit words using two DECtape words. Any 18-bit 
> machine is straight forward, while the PDP-11 (as you mention below) 
> only use 16 bits of the 18-bit word.
>
> I thought it was 128 18-bit words, but I may well remember that wrong, 
> and the "normal" format is 256 18-bit words. Makes sense, when I think 
> about it.
>
> The number of blocks is not absolutely fixed, but 578 is the 
> "standard" except on the PDP-8, I guess.
>
>> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
>> contain user data.
>
> That would be very depending on which machine we're talking about, and 
> which controller... :-) But I assume you're talking about the PDP-10 
> here. Did all PDP-10 with DECtapes use the same controller? I assume 
> both the KA and KI had DECtapes, as well as the PDP-6.
>
>> Block 100 is the directory block.  Thus 574 blocks for user data. The
>> directory holds up to 22 files, plus a map of which file owns each 
>> block.
>>
>> The user data blocks have a one word header (LH = next block of file; RH
>> = first block & words used in this block) + 127 words of payload.  This
>> differed from disk files, where all 128 words were payload, so
>> inattentive programmers could make a number of mistakes.  (E.g. random
>> access block isn't word/128; you had to pay attention to the buffer's
>> word count, etc.)
>>
>> Data blocks of a file are (usually) not contiguous; this allowed the
>> drive to stop and restart while reading or writing without having to
>> reverse direction.  The spacing depended on what blocks were free when
>> files were written, and the data mode.  (Files written in 'core dump'
>> modes were assumed to be read by the monitor without stopping, so the
>> gap was smaller, allowing larger programs to be read without reversing
>> direction.)
>>
>> The gory details of the format are in the Monitor Calls manual 
>> (TOPS-10).
>
> TOPS-10 DECtape format is definitely not something I know anything 
> about. But thanks for the rundown.
>
>> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
>> (except when reading PDP-10 tapes; the hardware for that was tricky as
>> the high bits had to be read with programmed IO; the low 16 were DMAed
>> on the TC-11.)
>
> Yes! Thanks for bringing another murky memory.
>
>> The low-level formatting that established the mark track, end zones and
>> block delimiters was done via a stand-alone diagnostic. This differs
>> between the two formats.  The directory block could be initialized under
>> timesharing.
>
> Um? What two formats?
>
>> Directory structure given is for the PDP-10; other OSs used different
>> formats.
>>
>>  From an emulation point of view, the PDP-10's controller was the most
>> interesting; the driver does dead reckoning; that is, it will start a
>> drive spinning for a seek, disconnect, service other drives, and
>> reconnect just before the desired block is expected to be over the read
>> head.  So real-world timing matters.  The other controllers (and thus
>> OSs) didn't support this.
>
> Wow. The TC08 actually did seeks while actually looking at the tape, 
> and then did DMA as well. So you didn't have to pay any more attention 
> than to a disk controller.
> Essentially, you asked it to seek, and it indicated when the seek was 
> done. You asked it to read, and it read.
> As far as I can remember, the TC11 is the same.
> Not sure what you mean by "other controllers didn't support this". 
> What is "this". Doing dead reckoning? Why would you actually want to 
> do dead reckoning. It makes much more sense to actually look at the 
> tape the whole time it is spinning by, and not only when you are 
> getting close to where you want to be. And the hardware can do that 
> without your involvement.
>
> In a way, however, I'd say that the TD8E is the most "interesting" 
> controller to emulate, since it is so incredibly stupid that you 
> actually have to emulate the low level format of the tape for that 
> controller to work.
> It is truly ugly. And that controller was a headache if you ever 
> wanted to use it in a timesharing operating system, since it did not 
> do DMA, it did not really do seeks, or in fact anything at all except 
> just feed the bits from the tape to the computer as they whizzed by.
>
>> Oh, all numbers above are radix 10.
>
> What's wrong with you. ;-)
>
>> The link for OS8 that I posted yesterday was via filewatcher; the direct
>> link
>> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
>> Sorry if this was confusing.
>>
>> Of potential interest to low-level folks is
>> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293 
>>
>>
>> Hope this is useful.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>
> Thanks for all the interesting bits and pieces.
>
>     Johnny
>
>>
>> On 18-Mar-13 16:26, Johnny Billquist wrote:
>>> On 2013-03-18 17:44, Bob Supnik wrote:
>>>> I was trying to get a debug setup for PIP10, per Ian King's mail, 
>>>> when I
>>>> discovered that none of my OS/8 images have PIP10 on them. This
>>>> certainly explains why the feature has never been tested before. I
>>>> suspect that ReadAll and WriteAll either are not working at all, or 
>>>> are
>>>> not working when the DECtape format is 18b. Another possibility is 
>>>> that
>>>> PDP-10 DECtape format is not the same as 18b format, at the 
>>>> nitty-gritty
>>>> level (format of headers and trailers).
>>>
>>> The DECtape format as such, with all the headers and so on, is the
>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>> have 128 18-bit words (if I remember right).
>>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>>> that is rather different from an 18-bit machine. But at the tape as
>>> such, there is nothing odd about it.
>>>
>>> But I can see lots of potential for errors when emulating this whole
>>> thing.
>>>
>>> I couldn't give exact details on lots of bits without looking in
>>> manuals, but in essence a DECtape is always doing 18-bit words. That
>>> is done by doing 6 groups of 3 bits each.
>>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>>> So the blocks are shorter, but you have more of them, when the tape is
>>> formatted for a PDP-8.
>>>
>>> I hope (assume) that you already know all of this. If not, let me
>>> know, and I can try helping out some more.
>>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>>> ago, which is when I actually had to dig rather deep into all of this.
>>> PIP10 was one of the things I really looked into. But since my tapes
>>> had actually been written on a PDP-15, I had to write my own code in
>>> the end, to just dump the raw data.
>>>
>>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>>> somewhere (like Mediafire) and let me know by email.
>>>
>>> I think someone already posted this, but I know I have that software,
>>> including sources (if I remember right) somewhere. Let me know if it
>>> can't be located anywhere else.
>>>
>>>     Johnny
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/ded201e5/attachment-0002.bin>

From michael.mondy at coffeebird.net  Tue Mar 19 10:36:38 2013
From: michael.mondy at coffeebird.net (Michael Mondy)
Date: Tue, 19 Mar 2013 09:36:38 -0500
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <51486B6E.7080304@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se>
Message-ID: <20130319143638.GA31395@coffeebird.net>

On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> [ ... ]
> 
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many
> comments on why other word lengths were more popular. I've seen
> mentioned that floating point formats was pretty nice to do with
> something like 60 or 72 bits. Reason being that you had large enough
> exponents for useful things, and enough precision for most
> calculations.
> So a word length that related to this made sense.
> 
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> 
> 	Johnny

Wikipedia has an article on 36-bit computing: http://en.wikipedia.org/wiki/36-bit

Snipped from the wikipedia article:

[ ... ]

Many early computers aimed at the scientific market had a 36-bit word length. This word length was just long enough to represent positive and negative integers to an accuracy of ten decimal digits (35 bits would have been the minimum). It also allowed the storage of six alphanumeric characters encoded in a six-bit character encoding. Prior to the introduction of computers, the state of the art in precision scientific and engineering calculation was the ten-digit, electrically powered, mechanical calculator, such as those manufactured by Friden, Marchant and Monroe. These calculators had a column of keys for each digit and operators were trained to use all their fingers when entering numbers, so while some specialized calculators had more columns, ten was a practical limit. Computers, as the new competitor, had to match that accuracy. Decimal computers sold in that era, such as the IBM 650 and the IBM 7070, had a word length of ten digits, as did ENIAC, one of the earliest computers.

[ ... ]

By the time IBM introduced System/360, scientific calculations had shifted to floating point and mechanical calculators were no longer a competitor. [...]  [ At which point the advantages of using powers of two became more important than feature parity with mechanical calculators. ]

-- Mike


From bob at jfcl.com  Tue Mar 19 10:51:15 2013
From: bob at jfcl.com (Bob Armstrong)
Date: Tue, 19 Mar 2013 07:51:15 -0700
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <006001ce24b1$353eea10$9fbcbe30$@com>

>By the time IBM introduced System/360, scientific calculations had shifted
>to floating point and mechanical calculators were no longer a competitor. 

  ... but the PDP-6 and the S/360 are roughly contemporary - both were
introduced around 1964.  I guess IBM was more forward thinking than DEC was
at the time :-)

  Of course DEC had a prior history with 18 bit computers, so I'm sure 36
seemed like a more natural choice.

Bob Armstrong





From bob at supnik.org  Tue Mar 19 11:25:56 2013
From: bob at supnik.org (Bob Supnik)
Date: Tue, 19 Mar 2013 11:25:56 -0400
Subject: [Simh] DECtape format(s)
Message-ID: <51488384.90401@supnik.org>

As was mentioned, DECtape formats are very much the same at the hardware 
level, but the block size does vary.

Block header format, all controllers except Type 55x, in 18b words:

word 0 - 0
word 1 - forward block number
words 2,3 - 0
word 4 - reverse checksum (077)

Block trailer format, all controllers except Type 550/555, in 18b words:

word 0 - forward checksum (one's complement of XOR of each 6b data frame)
words 1,2 - 0
word 3 - reverse block number (complement obverse of block # if read 
forward)
word 4 - 0

The ringer is the Type 55x controllers, which was used in the PDP-1, 4, 
5, 6, 7. The checksum format varied from unit to unit. Some used parity 
checking (XOR); others (like the 7) relied on software and used one's 
complement arithmetic. The reverse checksum was always 0777777 (-0). 
Further, the first five Type 550's had only four word headers.

So "modern" (TC series) DECtapes are all interchangeable. However, 
ancient DECtapes from before 1966 will require unique handling.

/Bob








From oboguev at yahoo.com  Tue Mar 19 12:27:02 2013
From: oboguev at yahoo.com (Sergey Oboguev)
Date: Tue, 19 Mar 2013 09:27:02 -0700 (PDT)
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <1363710422.62699.YahooMailRC@web184306.mail.ne1.yahoo.com>

My very first computer as a kid was a 37-bit computer we had at school, which I 
reckon must be considered superior to 36-bit computers.




________________________________
From: Michael Mondy <michael.mondy at coffeebird.net>
To: simh at trailing-edge.com
Sent: Tue, March 19, 2013 7:39:07 AM
Subject: [Simh] Why 36-bit computing?

On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> [ ... ]
> 
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many
> comments on why other word lengths were more popular. I've seen
> mentioned that floating point formats was pretty nice to do with
> something like 60 or 72 bits. Reason being that you had large enough
> exponents for useful things, and enough precision for most
> calculations.
> So a word length that related to this made sense.
> 
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> 
>     Johnny

Wikipedia has an article on 36-bit computing: 
http://en.wikipedia.org/wiki/36-bit

Snipped from the wikipedia article:

[ ... ]

Many early computers aimed at the scientific market had a 36-bit word length. 
This word length was just long enough to represent positive and negative 
integers to an accuracy of ten decimal digits (35 bits would have been the 
minimum). It also allowed the storage of six alphanumeric characters encoded in 
a six-bit character encoding. Prior to the introduction of computers, the state 
of the art in precision scientific and engineering calculation was the 
ten-digit, electrically powered, mechanical calculator, such as those 
manufactured by Friden, Marchant and Monroe. These calculators had a column of 
keys for each digit and operators were trained to use all their fingers when 
entering numbers, so while some specialized calculators had more columns, ten 
was a practical limit. Computers, as the new competitor, had to match that 
accuracy. Decimal computers sold in that era, such as the IBM 650 and the IBM 
7070, had a word length of ten digits, as did ENIAC, one of the earliest 
computers.

[ ... ]

By the time IBM introduced System/360, scientific calculations had shifted to 
floating point and mechanical calculators were no longer a competitor. [...]  [ 
At which point the advantages of using powers of two became more important than 
feature parity with mechanical calculators. ]

-- Mike
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130319/cee2d447/attachment-0002.html>

From IanK at vulcan.com  Tue Mar 19 15:04:44 2013
From: IanK at vulcan.com (Ian King)
Date: Tue, 19 Mar 2013 19:04:44 +0000
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <20130319143638.GA31395@coffeebird.net>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
Message-ID: <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>

> -----Original Message-----
> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh at trailing-edge.com
> Subject: [Simh] Why 36-bit computing?
> 
> On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> > [ ... ]
> >
> > It wasn't just DEC. Back in the day, most everyone used various word
> > lengths that wasn't a power of two. I can't really make many comments
> > on why other word lengths were more popular. I've seen mentioned that
> > floating point formats was pretty nice to do with something like 60 or
> > 72 bits. Reason being that you had large enough exponents for useful
> > things, and enough precision for most calculations.
> > So a word length that related to this made sense.
> >
> > Number of bits being a power of two started with IBM in the 60s, and
> > became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> >
> > 	Johnny
> 
> Wikipedia has an article on 36-bit computing:
> http://en.wikipedia.org/wiki/36-bit
> 
> Snipped from the wikipedia article:
> 
> [ ... ]
> 
> Many early computers aimed at the scientific market had a 36-bit word
> length. This word length was just long enough to represent positive and
> negative integers to an accuracy of ten decimal digits (35 bits would have
> been the minimum). It also allowed the storage of six alphanumeric
> characters encoded in a six-bit character encoding. Prior to the introduction
> of computers, the state of the art in precision scientific and engineering
> calculation was the ten-digit, electrically powered, mechanical calculator,
> such as those manufactured by Friden, Marchant and Monroe. These
> calculators had a column of keys for each digit and operators were trained to
> use all their fingers when entering numbers, so while some specialized
> calculators had more columns, ten was a practical limit. Computers, as the
> new competitor, had to match that accuracy. Decimal computers sold in that
> era, such as the IBM 650 and the IBM 7070, had a word length of ten digits, as
> did ENIAC, one of the earliest com  puters.
> 
> [ ... ]
> 
> By the time IBM introduced System/360, scientific calculations had shifted to
> floating point and mechanical calculators were no longer a competitor. [...]  [
> At which point the advantages of using powers of two became more
> important than feature parity with mechanical calculators. ]
> 

The following is from a biography of Fred Brooks, the project manager for the IBM 360, on UNC-Chapel Hill's Computer Science department website (http://www.cs.unc.edu/cms/our-people/faculty/frederick-p.-brooks-jr): 

"In 1957, Dr. Brooks and Dura Sweeney invented a Stretch interrupt system that introduced most features of today's interrupt systems. Dr. Brooks coined the term computer architecture. His system/360 team first achieved strict compatibility, upward and downward, in a computer family. His early concern for word processing led to his selection of the 8-bit byte and the lowercase alphabet for the System/360, engineering of many new 8-bit input/output devices, and providing a character-string datatype in PL/I."

Keep in mind that the S/360 was not only targeted for scientific computation.  It was intended to consolidate IBM's customer bases.  -- Ian 



From bqt at softjar.se  Tue Mar 19 16:27:20 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Tue, 19 Mar 2013 21:27:20 +0100
Subject: [Simh] PIP10 on PDP-8 SIM
In-Reply-To: <51486E72.4010508@ieee.org>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org> <51486745.3010802@softjar.se>
 <51486E72.4010508@ieee.org>
Message-ID: <5148CA28.5090909@softjar.se>

On 2013-03-19 14:56, Timothe Litt wrote:
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> Consider a timesharing system, with 4 users each trying to transfer from
> their own DTA.  With a TC11, you serviced user 1, user, 3, user 4, user
> 2 sequentially.   The controller was tied up for the whole seek for each
> user - potentially from one end of the tape to the other.

Oh. You are talking about overlapped seeks. I thought you meant 
something else.

I just checked the TC01 controller (for the PDP-8) and it certainly can 
do this too. But you need to programatically time things in this case, 
to go back to the drive when you think it is getting close, and start 
fiddling. Also checked the TC11, and it too can run several tape units, 
as long as you reselect the tape drive when you think you actually want 
to start doing any operations. Both can have tapes continue to run in 
either direction while doing operations on another tape.
Sounds like exactly the same deal as with the TD10.

The TD8E, which I mentioned being the most stupid controller on earth, 
requires this solution all the time, as there is no actual seek, nor is 
there any DMA. You either poll the controller all the time, or else you 
setup a time interrupt when you think it is appropriate to start polling.
(Of course, OS/8 just polls the darn tape the whole time...)

> The TD10-'s dead reckoning allowed  the seeks to proceed in parallel.
> E.g. we'd start all 4 seeks, allowing the drives to run unsupervised by
> the controller.  When the shortest seek was near completion, the driver
> would tell the controller to pay attention to that drive ('connect'), do
> the transfer, and stop.  Then the next.  Besides being impressive to
> watch (8 drives spinning in various directions), the user request
> latency was reduced.   (Some systems had two controllers, for 16 drives!)

I don't know if any driver for any PDP8 OS, or PDP11 OS ever did 
overlapped seeks, but the hardware can definitely do it.
The one OS I can tell about is RSX, and it did not support overlapped 
seeks on TC11. (And of course I know OS/8, but the answer there is that 
nothing ever did overlapped seeks on anything, since all I/O was polled 
anyway.)

> The KA, KI and KL (with the IO Bus adapter) all used the TD10
> controller.  The -6 had another controller - type 551.  I think it was a
> dumb controller, but didn't use it personally.

Ok.

> 129 x 12 = 1548 bits/block; 256 x 18 = 4608 bits/block ; 2 formats. Gory
> details of the TD10 are at

Oh. You just meant the number of bits in a block. Well, you can do any 
size you want, just as you can do any number of blocks you want, withing 
physical limits, and probably some other restrictions that I can't think 
of right now.

> Since PIP10 (the pdp-8 reader for pdp-10 tapes) was the question, the
> format info I provided was for the 10.  TOPS-10.  MAC had another format
> for the -6.  TOPS-20 didn't officially support DECtapes, but internally
> we had systems with them.  They used the PDP-10 format.

Makes sense.
Anyway, yes, PIP10 would parse the format you described, once it 
actually manages to read the blocks. That is the tricky detail that 
seems to not be working...

> Much of the pdp-10 format documentation is a mixture of octal and
> decimal.  I picked decimal because these days, thinking in octal is a
> (mostly) lost art.

:-)

> IBM and many other vendors used 36-bits, because the (BCD) character
> codes of the day were 6-bits, so it packed nicely.  The -8 was 12 bits
> for the same reason, only it was cheaper to build.

I don't know how much the PDP-8 (or rather, PDP-5) was 12 bits because 
of any BCD issues. But it was cheap.

> The PDP-10 supported arbitrary byte sizes (1-36 bits), so 7-bit ascii,
> 8-bit ascii or 9-bit ITS emacs encodings were all easy to deal with.

I know. The PDP-10 is a nice architecture.

> The -11 was designed after 8-bit character codes became popular. EBCDIC
> was (and is) an ugly mess; ASCII cemented 8-bit character codes.  And
> machines were then built as multiples of 8 bits, 8, 16, 32, 64 being the
> most popular.

I can only agree about EBCDIC. ASCII wasn't really 8-bit though. But 
7-bit is close enough.

	Johnny

>
> On 19-Mar-13 09:25, Johnny Billquist wrote:
>> On 2013-03-19 14:03, Timothe Litt wrote:
>>>> The DECtape format as such, with all the headers and so on, is the
>>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>>> have 128 18-bit words (if I remember right).
>>> Pretty much right.  129 may be slightly misleading.  The format is 129,
>>> but the -8 used  only 128 of the 129 12-bit words/block for data.
>>
>> Right. :-)
>>
>>> The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
>>> formatted DECtape would have 578 blocks of 128 36-bit words. (256
>>> 18-bit words at the hardware level.)
>>
>> I know that the PDP-10 is 36 bits. :-) I was talking about the DECtape
>> as such, which physically always stores 18 bits. A PDP-10 would
>> obviously store its 36-bit words using two DECtape words. Any 18-bit
>> machine is straight forward, while the PDP-11 (as you mention below)
>> only use 16 bits of the 18-bit word.
>>
>> I thought it was 128 18-bit words, but I may well remember that wrong,
>> and the "normal" format is 256 18-bit words. Makes sense, when I think
>> about it.
>>
>> The number of blocks is not absolutely fixed, but 578 is the
>> "standard" except on the PDP-8, I guess.
>>
>>> Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't
>>> contain user data.
>>
>> That would be very depending on which machine we're talking about, and
>> which controller... :-) But I assume you're talking about the PDP-10
>> here. Did all PDP-10 with DECtapes use the same controller? I assume
>> both the KA and KI had DECtapes, as well as the PDP-6.
>>
>>> Block 100 is the directory block.  Thus 574 blocks for user data. The
>>> directory holds up to 22 files, plus a map of which file owns each
>>> block.
>>>
>>> The user data blocks have a one word header (LH = next block of file; RH
>>> = first block & words used in this block) + 127 words of payload.  This
>>> differed from disk files, where all 128 words were payload, so
>>> inattentive programmers could make a number of mistakes.  (E.g. random
>>> access block isn't word/128; you had to pay attention to the buffer's
>>> word count, etc.)
>>>
>>> Data blocks of a file are (usually) not contiguous; this allowed the
>>> drive to stop and restart while reading or writing without having to
>>> reverse direction.  The spacing depended on what blocks were free when
>>> files were written, and the data mode.  (Files written in 'core dump'
>>> modes were assumed to be read by the monitor without stopping, so the
>>> gap was smaller, allowing larger programs to be read without reversing
>>> direction.)
>>>
>>> The gory details of the format are in the Monitor Calls manual
>>> (TOPS-10).
>>
>> TOPS-10 DECtape format is definitely not something I know anything
>> about. But thanks for the rundown.
>>
>>> The PDP-11 used 18-bit format, but ignored the high 2 bits of each word
>>> (except when reading PDP-10 tapes; the hardware for that was tricky as
>>> the high bits had to be read with programmed IO; the low 16 were DMAed
>>> on the TC-11.)
>>
>> Yes! Thanks for bringing another murky memory.
>>
>>> The low-level formatting that established the mark track, end zones and
>>> block delimiters was done via a stand-alone diagnostic. This differs
>>> between the two formats.  The directory block could be initialized under
>>> timesharing.
>>
>> Um? What two formats?
>>
>>> Directory structure given is for the PDP-10; other OSs used different
>>> formats.
>>>
>>>  From an emulation point of view, the PDP-10's controller was the most
>>> interesting; the driver does dead reckoning; that is, it will start a
>>> drive spinning for a seek, disconnect, service other drives, and
>>> reconnect just before the desired block is expected to be over the read
>>> head.  So real-world timing matters.  The other controllers (and thus
>>> OSs) didn't support this.
>>
>> Wow. The TC08 actually did seeks while actually looking at the tape,
>> and then did DMA as well. So you didn't have to pay any more attention
>> than to a disk controller.
>> Essentially, you asked it to seek, and it indicated when the seek was
>> done. You asked it to read, and it read.
>> As far as I can remember, the TC11 is the same.
>> Not sure what you mean by "other controllers didn't support this".
>> What is "this". Doing dead reckoning? Why would you actually want to
>> do dead reckoning. It makes much more sense to actually look at the
>> tape the whole time it is spinning by, and not only when you are
>> getting close to where you want to be. And the hardware can do that
>> without your involvement.
>>
>> In a way, however, I'd say that the TD8E is the most "interesting"
>> controller to emulate, since it is so incredibly stupid that you
>> actually have to emulate the low level format of the tape for that
>> controller to work.
>> It is truly ugly. And that controller was a headache if you ever
>> wanted to use it in a timesharing operating system, since it did not
>> do DMA, it did not really do seeks, or in fact anything at all except
>> just feed the bits from the tape to the computer as they whizzed by.
>>
>>> Oh, all numbers above are radix 10.
>>
>> What's wrong with you. ;-)
>>
>>> The link for OS8 that I posted yesterday was via filewatcher; the direct
>>> link
>>> isftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/
>>> Sorry if this was confusing.
>>>
>>> Of potential interest to low-level folks is
>>> http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293
>>>
>>>
>>> Hope this is useful.
>>>
>>> This communication may not represent my employer's views,
>>> if any, on the matters discussed.
>>
>> Thanks for all the interesting bits and pieces.
>>
>>     Johnny
>>
>>>
>>> On 18-Mar-13 16:26, Johnny Billquist wrote:
>>>> On 2013-03-18 17:44, Bob Supnik wrote:
>>>>> I was trying to get a debug setup for PIP10, per Ian King's mail,
>>>>> when I
>>>>> discovered that none of my OS/8 images have PIP10 on them. This
>>>>> certainly explains why the feature has never been tested before. I
>>>>> suspect that ReadAll and WriteAll either are not working at all, or
>>>>> are
>>>>> not working when the DECtape format is 18b. Another possibility is
>>>>> that
>>>>> PDP-10 DECtape format is not the same as 18b format, at the
>>>>> nitty-gritty
>>>>> level (format of headers and trailers).
>>>>
>>>> The DECtape format as such, with all the headers and so on, is the
>>>> same on all tapes. A normal PDP-8 formatted tape will have 129
>>>> (12-bit) words, however, while a PDP-10 (or any other 18-bitter) would
>>>> have 128 18-bit words (if I remember right).
>>>> The PDP-8, when doing 12-bit formatted tapes, just packs data in a way
>>>> that is rather different from an 18-bit machine. But at the tape as
>>>> such, there is nothing odd about it.
>>>>
>>>> But I can see lots of potential for errors when emulating this whole
>>>> thing.
>>>>
>>>> I couldn't give exact details on lots of bits without looking in
>>>> manuals, but in essence a DECtape is always doing 18-bit words. That
>>>> is done by doing 6 groups of 3 bits each.
>>>> A PDP-8 will pack three 12-bit words into two 18-bit words. This means
>>>> that a DECtape block for a PDP-8 will only have 86 18-bit words.
>>>> So the blocks are shorter, but you have more of them, when the tape is
>>>> formatted for a PDP-8.
>>>>
>>>> I hope (assume) that you already know all of this. If not, let me
>>>> know, and I can try helping out some more.
>>>> I actually did dump a few 18-bit tapes on my PDP-8 only a few months
>>>> ago, which is when I actually had to dig rather deep into all of this.
>>>> PIP10 was one of the things I really looked into. But since my tapes
>>>> had actually been written on a PDP-15, I had to write my own code in
>>>> the end, to just dump the raw data.
>>>>
>>>>> If anyone has a canned OS/8 V3C image with PIP10, please post it
>>>>> somewhere (like Mediafire) and let me know by email.
>>>>
>>>> I think someone already posted this, but I know I have that software,
>>>> including sources (if I remember right) somewhere. Let me know if it
>>>> can't be located anywhere else.
>>>>
>>>>     Johnny
>>>>
>>>> _______________________________________________
>>>> Simh mailing list
>>>> Simh at trailing-edge.com
>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>
>>
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>



From davel.rss at googlemail.com  Tue Mar 19 17:37:54 2013
From: davel.rss at googlemail.com (Dave L)
Date: Tue, 19 Mar 2013 21:37:54 -0000
Subject: [Simh] Why 36-bit computing?
In-Reply-To: <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <20130319143638.GA31395@coffeebird.net>
 <2F25BE3D5F64F342B56139F31854C9B998D7C13A@505MBX2.corp.vnw.com>
Message-ID: <015601ce24ea$048dc470$0da94d50$@gmail.com>

As I recall from way back, wasn't the 36 bit potentially split into 32-bit
data and 4 bit offset to allow fast jump to the next "card" in the deck on a
branch? Not that (m)any implemented this, but I seem to recall this from my
early days back at ADP 30+ years ago. With the advent of fast memory and
disk drives this effectively became unnecessary but mainframe architecture
took a while to adjust.

Dave

-----Original Message-----
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com]
On Behalf Of Ian King
Sent: 19 March 2013 19:05
To: simh at trailing-edge.com
Subject: Re: [Simh] Why 36-bit computing?

> -----Original Message-----
> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- 
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh at trailing-edge.com
> Subject: [Simh] Why 36-bit computing?
> 
> On Tue, Mar 19, 2013 at 02:43:10PM +0100, Johnny Billquist wrote:
> > [ ... ]
> >
> > It wasn't just DEC. Back in the day, most everyone used various word 
> > lengths that wasn't a power of two. I can't really make many 
> > comments on why other word lengths were more popular. I've seen 
> > mentioned that floating point formats was pretty nice to do with 
> > something like 60 or
> > 72 bits. Reason being that you had large enough exponents for useful 
> > things, and enough precision for most calculations.
> > So a word length that related to this made sense.
> >
> > Number of bits being a power of two started with IBM in the 60s, and 
> > became common with the PDP-11 in the 70s. (Or so I'd like to think.)
> >
> > 	Johnny
> 
> Wikipedia has an article on 36-bit computing:
> http://en.wikipedia.org/wiki/36-bit
> 
> Snipped from the wikipedia article:
> 
> [ ... ]
> 
> Many early computers aimed at the scientific market had a 36-bit word 
> length. This word length was just long enough to represent positive 
> and negative integers to an accuracy of ten decimal digits (35 bits 
> would have been the minimum). It also allowed the storage of six 
> alphanumeric characters encoded in a six-bit character encoding. Prior 
> to the introduction of computers, the state of the art in precision 
> scientific and engineering calculation was the ten-digit, electrically 
> powered, mechanical calculator, such as those manufactured by Friden, 
> Marchant and Monroe. These calculators had a column of keys for each 
> digit and operators were trained to use all their fingers when 
> entering numbers, so while some specialized calculators had more 
> columns, ten was a practical limit. Computers, as the new competitor, 
> had to match that accuracy. Decimal computers sold in that era, such 
> as the IBM 650 and the IBM 7070, had a word length of ten digits, as did
ENIAC, one of the earliest com  puters.
> 
> [ ... ]
> 
> By the time IBM introduced System/360, scientific calculations had 
> shifted to floating point and mechanical calculators were no longer a 
> competitor. [...]  [ At which point the advantages of using powers of 
> two became more important than feature parity with mechanical 
> calculators. ]
> 

The following is from a biography of Fred Brooks, the project manager for
the IBM 360, on UNC-Chapel Hill's Computer Science department website
(http://www.cs.unc.edu/cms/our-people/faculty/frederick-p.-brooks-jr): 

"In 1957, Dr. Brooks and Dura Sweeney invented a Stretch interrupt system
that introduced most features of today's interrupt systems. Dr. Brooks
coined the term computer architecture. His system/360 team first achieved
strict compatibility, upward and downward, in a computer family. His early
concern for word processing led to his selection of the 8-bit byte and the
lowercase alphabet for the System/360, engineering of many new 8-bit
input/output devices, and providing a character-string datatype in PL/I."


Keep in mind that the S/360 was not only targeted for scientific
computation.  It was intended to consolidate IBM's customer bases.  -- Ian 

_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh



From toby at telegraphics.com.au  Tue Mar 19 22:27:48 2013
From: toby at telegraphics.com.au (Toby Thain)
Date: Tue, 19 Mar 2013 22:27:48 -0400
Subject: [Simh] Non-2^n architectures - Re:  PIP10 on PDP-8 SIM
In-Reply-To: <51486B6E.7080304@softjar.se>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se>
Message-ID: <51491EA4.20708@telegraphics.com.au>

On 19/03/13 9:43 AM, Johnny Billquist wrote:
> On 2013-03-19 14:30, Armistead, Jason wrote:
>> I had trouble with Timothe’s link to the USPTO, but found this same
>> patent in PDF form at
>>
>> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>>
>> As a relative newbie who started my serious journey into computing with
>> an Apple ][ I’ve never fully understood DEC’s fascination with word
>> lengths that weren’t multiples of 2 ...
>
> It wasn't just DEC. Back in the day, most everyone used various word
> lengths that wasn't a power of two. I can't really make many comments on
> why other word lengths were more popular.

12, 15, 18, 36, 60 ...

24 is still common in DSPs (and maybe 48 and 56?) - and even word 
addressing is still used.

 >  I've seen mentioned that
> floating point formats was pretty nice to do with something like 60 or
> 72 bits. Reason being that you had large enough exponents for useful
> things, and enough precision for most calculations.
> So a word length that related to this made sense.
>
> Number of bits being a power of two started with IBM in the 60s, and
> became common with the PDP-11 in the 70s. (Or so I'd like to think.)



And, not insignificantly, the rise of 8-bit microprocessors.

(Though octal was still standard notation for addresses and many 
constants on PDP-11, hence C's octal literals.)

--Toby

>
> Johnny
>



From radioengr at gmail.com  Tue Mar 19 23:21:43 2013
From: radioengr at gmail.com (Rob Doyle)
Date: Tue, 19 Mar 2013 20:21:43 -0700
Subject: [Simh] Non-2^n architectures - Re:  PIP10 on PDP-8 SIM
In-Reply-To: <51491EA4.20708@telegraphics.com.au>
References: <5147447C.9000501@supnik.org> <5147788C.2090901@softjar.se>
 <51486213.8040508@ieee.org>
 <78CD6B448AA1E54FBAB5EF46F90F9B381F249680@UUSNWE1S.na.utcmail.com>
 <51486B6E.7080304@softjar.se> <51491EA4.20708@telegraphics.com.au>
Message-ID: <51492B47.70100@gmail.com>

On 3/19/2013 7:27 PM, Toby Thain wrote:
> On 19/03/13 9:43 AM, Johnny Billquist wrote:
>> On 2013-03-19 14:30, Armistead, Jason wrote:
>>> I had trouble with Timothe’s link to the USPTO, but found this
>>> same patent in PDF form at
>>>
>>> http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf
>>>
>>> As a relative newbie who started my serious journey into
>>> computing with an Apple ][ I’ve never fully understood DEC’s
>>> fascination with word lengths that weren’t multiples of 2 ...
>>
>> It wasn't just DEC. Back in the day, most everyone used various
>> word lengths that wasn't a power of two. I can't really make many
>> comments on why other word lengths were more popular.
>
> 12, 15, 18, 36, 60 ...
>
> 24 is still common in DSPs (and maybe 48 and 56?) - and even word
> addressing is still used.

24-bit data is common for cost sensitive audio applications because
16-bit data is insufficient and 32-bit data is overkill.

GPUs typically have odd data widths for similar reasons.

In these types of applications, the notion of 8-bit bytes is mostly
irrelevant. As stated above, many of these devices can't even address
bytes. Interestingly enough, none of these /limitations/ preclude having
a compliant "C" compiler.

>> I've seen mentioned that floating point formats was pretty nice to
>> do with something like 60 or 72 bits. Reason being that you had
>> large enough exponents for useful things, and enough precision for
>> most calculations. So a word length that related to this made
>> sense.
>>
>> Number of bits being a power of two started with IBM in the 60s,
>> and became common with the PDP-11 in the 70s. (Or so I'd like to
>> think.)
>
>
>
> And, not insignificantly, the rise of 8-bit microprocessors.
>
> (Though octal was still standard notation for addresses and many
> constants on PDP-11, hence C's octal literals.)
>
> --Toby
>
>>
>> Johnny
>>
>
> _______________________________________________ Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>



From bob at supnik.org  Wed Mar 20 18:05:12 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 20 Mar 2013 18:05:12 -0400
Subject: [Simh] PIP10
Message-ID: <514A3298.5010508@supnik.org>

I tried running PIP10 from the image Ian was using.

If the simulator is configured for a TC08, it hangs. It is in a loop 
doing IOT 773/JMP .-1, which is a TD8E IOT.

If the simulator is configured for a TD8E, it returns an error. I tried 
DTA0:/Z and got OUTPUT FILE OPEN ERROR.

So the first issue is that PIP10's logic for telling which DECtape 
controller is present uses some feature that the simulator is doing 
incorrectly.

The second issue is what happens beyond that point.

/Bob


From litt at ieee.org  Wed Mar 20 19:13:37 2013
From: litt at ieee.org (Timothe Litt)
Date: Wed, 20 Mar 2013 19:13:37 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A3298.5010508@supnik.org>
References: <514A3298.5010508@supnik.org>
Message-ID: <514A42A1.4010600@ieee.org>

The logic doesn't seem to be in PIP10; PIP10 uses the DCB devtype field 
to decide if it has a DECtape, and if so, which controller.

See 
ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/os8.v3d/sources/system/dectapes/dectape7/pip10.pa 
for PIP10, and table 33 
inhttp://www.grc.com/pdp-8/docs/OS8_System_Reference_Manual.pdf 
<http://www.grc.com/pdp-8/docs/OS8_System_Reference_Manual.pdf>for the 
DCB breakdown.  I'm not an OS8 expert, but I think the DCB is setup by 
CONFIG.

Relevant snippets:

DCB=7760 /DEVICE CONTROL BLOCK (FIELD 1)

DVTYPE, 0 /DEVICE TYPE HOLDER

JMS GTDVTP /COMPARE DCB ENTRY WITH TC08 OR TD8E
SZA CLA
JMP CDIN3 /NOT DECTAPE

GTDVTP, 0
TAD (DCB-1
DCA TEMP1
CDF 10
TAD I TEMP1 /GET DCB ENTRY
CDF
DCA DVTYPE
TAD DVTYPE
AND (770
TAD (-210
SZA
TAD (30
JMP I GTDVTP



This communication may not represent my employer's views,
if any, on the matters discussed.

On 20-Mar-13 18:05, Bob Supnik wrote:
> I tried running PIP10 from the image Ian was using.
>
> If the simulator is configured for a TC08, it hangs. It is in a loop 
> doing IOT 773/JMP .-1, which is a TD8E IOT.
>
> If the simulator is configured for a TD8E, it returns an error. I 
> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>
> So the first issue is that PIP10's logic for telling which DECtape 
> controller is present uses some feature that the simulator is doing 
> incorrectly.
>
> The second issue is what happens beyond that point.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/6f0e8951/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/6f0e8951/attachment-0002.bin>

From litt at ieee.org  Wed Mar 20 20:03:38 2013
From: litt at ieee.org (Timothe Litt)
Date: Wed, 20 Mar 2013 20:03:38 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A3298.5010508@supnik.org>
References: <514A3298.5010508@supnik.org>
Message-ID: <514A4E5A.7090206@ieee.org>

Meant to include the code that uses DVTYPE and actually picks the type 
in my earlier note.  Sorry.

If I had to make a random guess, look at the microprogrammed operate 
codes, e.g SNA CLA; CLL CML RTR;

SETUNT, 0
STL
TAD (-7607
SZA /IF IT IS 7607,
TAD (7 /ITS UNIT 0
AND (7
CLL CML RTR
RTR
DCA UNIT10
TAD DVTYPE
AND (10
SNA CLA
JMP I SETUNT /TC08 - FINISHED
CLL
TAD UNIT10
AND (7000 /TD8E ENTRY POINTS ARE STRANGE -
TAD UNIT10 /MUST ROTATE UNIT NUMBER LEFT 1
SZL
TAD (1000
DCA UNIT10
JMS I (TDUSET /SET UP TD8E OPCODES
JMP I SETUNT

This communication may not represent my employer's views,
if any, on the matters discussed.

On 20-Mar-13 18:05, Bob Supnik wrote:
> I tried running PIP10 from the image Ian was using.
>
> If the simulator is configured for a TC08, it hangs. It is in a loop 
> doing IOT 773/JMP .-1, which is a TD8E IOT.
>
> If the simulator is configured for a TD8E, it returns an error. I 
> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>
> So the first issue is that PIP10's logic for telling which DECtape 
> controller is present uses some feature that the simulator is doing 
> incorrectly.
>
> The second issue is what happens beyond that point.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130320/4a5bcc2c/attachment-0002.bin>

From bob at supnik.org  Wed Mar 20 21:07:34 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 20 Mar 2013 21:07:34 -0400
Subject: [Simh] PIP10
In-Reply-To: <514A4E5A.7090206@ieee.org>
References: <514A3298.5010508@supnik.org> <514A4E5A.7090206@ieee.org>
Message-ID: <514A5D56.30100@supnik.org>

Thanks, Tim. That means the OS/8 image Ian and I are using is configured 
for a TD8E, so I'll debug that code path. It's more difficult, because 
the DECtape emulator has to provide an accurate emulation of the mark 
track, and I could easily have it wrong in 16b- or 18b- mode. (The TD8E 
does run OS/8, so it's probably okay in 12b mode.)

/Bob

On 3/20/2013 8:03 PM, Timothe Litt wrote:
> Meant to include the code that uses DVTYPE and actually picks the type 
> in my earlier note.  Sorry.
>
> If I had to make a random guess, look at the microprogrammed operate 
> codes, e.g SNA CLA; CLL CML RTR;
>
> SETUNT, 0
> STL
> TAD (-7607
> SZA /IF IT IS 7607,
> TAD (7 /ITS UNIT 0
> AND (7
> CLL CML RTR
> RTR
> DCA UNIT10
> TAD DVTYPE
> AND (10
> SNA CLA
> JMP I SETUNT /TC08 - FINISHED
> CLL
> TAD UNIT10
> AND (7000 /TD8E ENTRY POINTS ARE STRANGE -
> TAD UNIT10 /MUST ROTATE UNIT NUMBER LEFT 1
> SZL
> TAD (1000
> DCA UNIT10
> JMS I (TDUSET /SET UP TD8E OPCODES
> JMP I SETUNT
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 20-Mar-13 18:05, Bob Supnik wrote:
>> I tried running PIP10 from the image Ian was using.
>>
>> If the simulator is configured for a TC08, it hangs. It is in a loop 
>> doing IOT 773/JMP .-1, which is a TD8E IOT.
>>
>> If the simulator is configured for a TD8E, it returns an error. I 
>> tried DTA0:/Z and got OUTPUT FILE OPEN ERROR.
>>
>> So the first issue is that PIP10's logic for telling which DECtape 
>> controller is present uses some feature that the simulator is doing 
>> incorrectly.
>>
>> The second issue is what happens beyond that point.
>>
>> /Bob
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>



From Jason.Armistead at otis.com  Thu Mar 21 09:55:18 2013
From: Jason.Armistead at otis.com (Armistead, Jason)
Date: Thu, 21 Mar 2013 13:55:18 +0000
Subject: [Simh] Formally documenting PDP tape drive behavior (and other
 facets of SIMH and the systems it emulates)
Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>

There has been a lot of interesting discussion about tape drives on PDP systems in the last week or so.  It's great to hear those familiar with the inner workings of these devices, or with access to the manuals, share their wisdom.

One question though - after the "old timers" are gone, would a newbie to SIMH be able to figure these same things out ?

Or, in other words, do the accompanying comments in the code and the SIMH documentation adequately capture the "nuggets" of the conversations that take place on this list ?  And do we provide enough in the way of "breadcrumbs" to allow a newbie to re-discover this same information ?

Capturing this knowledge is a hard thing to do, and with retrocomputing we are presently at a point in time where we can still rely on folks who designed, built, tested, operated and programmed these systems, and in some cases they still even have running systems available for experimentation and measurement.  But what happens when that is no longer the case ?

Just food for thought ... let's make sure SIMH and its fellow emulators like MAME / MESS can still be enjoyed and understood by future generations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130321/9fd93c6f/attachment-0002.html>

From dott.piergiorgio at fastwebnet.it  Thu Mar 21 17:34:24 2013
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Thu, 21 Mar 2013 22:34:24 +0100
Subject: [Simh] Formally documenting PDP tape drive behavior (and other
 facets of SIMH and the systems it emulates)
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>
References: <78CD6B448AA1E54FBAB5EF46F90F9B381F24CC83@UUSNWE1S.na.utcmail.com>
Message-ID: <514B7CE0.1060207@fastwebnet.it>

Il 21/03/2013 14:55, Armistead, Jason ha scritto:
> There has been a lot of interesting discussion about tape drives on
> PDP systems in the last week or so.  It's great to hear those
> familiar with the inner workings of these devices, or with access to
> the manuals, share their wisdom.
>
> One question though - after the "old timers" are gone, would a newbie
> to SIMH be able to figure these same things out ?
>
> Or, in other words, do the accompanying comments in the code and the
> SIMH documentation adequately capture the "nuggets" of the
> conversations that take place on this list ?  And do we provide
> enough in the way of "breadcrumbs" to allow a newbie to re-discover
> this same information ?
>
> Capturing this knowledge is a hard thing to do, and with
> retrocomputing we are presently at a point in time where we can still
> rely on folks who designed, built, tested, operated and programmed
> these systems, and in some cases they still even have running systems
> available for experimentation and measurement.  But what happens when
> that is no longer the case ?
>
> Just food for thought ... let's make sure SIMH and its fellow
> emulators like MAME / MESS can still be enjoyed and understood by
> future generations.

I have reported, and was discussed here, the issues with PDP-4/7 DECsys, 
whose is rooted in the partial emulation of the DECTape formatting; In 
more recent time, I have haved little time to fool with SIMH, so I guess 
that a .txt or .odt shared "Notebook of SIMH" can be a good idea.

oh, and about the issues with ex and de, e.g. Librascope emulation ?

Best regards from Italy,
dott. Piergiorgio.


From bob at supnik.org  Wed Mar 27 22:08:01 2013
From: bob at supnik.org (Bob Supnik)
Date: Wed, 27 Mar 2013 22:08:01 -0400
Subject: [Simh] PDP-10 DECtapes
Message-ID: <5153A601.2090004@supnik.org>

I believe the PDP-10 DECtape images that are floating around the web may 
not be accurate transcriptions.

All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
words in a 32b container (a 36b word in a 72b container). Thus, each 
256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
Therefore, the unage length, in KB, should equal the number of blocks, 
which is 578. And in fact, all extent 18b PDP DECtape images are 578KB long.

A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W 
x 16b DECtape block requires 1/2 KB of storage. Therefore, the image 
length, in KB, should equal half the number of blocks, or 578 / 2 = 289. 
And that's what we have.

This is confirmed by the fact that if you let the simulator "autosize" 
the 289KB images, it comes up with PDP-11 format.

I verified, by patching the simulator, that there is data in both halves 
of each 32b word in the image. This too points to a PDP-11 image.

Even if the PDP-10 DECtape were packed with no  padding, it should be 
18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images 
were transcribed on a TC11 and are missing 2b in every 18b.

This is not to say that the TD8E simulator is correct. I cannot get it 
to zero (initialize) a fresh 18b DECtape through PIP10, so something is 
broken. However, the TD8E is so arcane that it will take a considerable 
period of time to figure out what the software is trying to do and why 
the simulator is responding incorrectly.

/Bob


From litt at ieee.org  Thu Mar 28 06:43:05 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 06:43:05 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5153A601.2090004@supnik.org>
References: <5153A601.2090004@supnik.org>
Message-ID: <51541EB9.6080204@ieee.org>

Bob,

It might be useful to know exactly which images you tested.  A number of 
the 'PDP-10 DECtape images' that turned up on a quick Google search are 
actually for the PDP-11 front-end of a KL1090/1090.  These are in fact 
16-bit tapes: the file format would be Files-11 for RSX20F tapes; I 
think the KLAD DECtapes were DOS-11 format, but it's been a while.  The 
KLAD tapes were accessed by the -11 and loaded into the -10 via the 
DTE20.   This is distinct from 10-side DECtape diagnostics, which also 
exist. Google 'AA-JS16A-TC' for some Files-11 format information; I'd 
have to think a bit on the DOS-11 format.

Knowing which images you're working with would let the custodians of the 
images indicate their source, and perhaps from that we can work back to 
the people/method/tools used to create them.

Also, if the data that you're working with is in fact truncated saves of 
36-bit data, the directory block should still be recognizable.  
Filenames are in sixbit, and the block numbers in links fit in 16 bits.  
So the data should make sense, even if it is incomplete.  I posted the 
key format information for TOPS-10 DECtapes a while back in this 
string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.

I could look at an image file if you need help untangling the data.

On the pip10 /z, pip10 seems to use a private DTA service routine; it's 
in the sources that I pointed you to earlier.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 27-Mar-13 22:08, Bob Supnik wrote:
> I believe the PDP-10 DECtape images that are floating around the web 
> may not be accurate transcriptions.
>
> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
> words in a 32b container (a 36b word in a 72b container). Thus, each 
> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
> Therefore, the unage length, in KB, should equal the number of blocks, 
> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB 
> long.
>
> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
> image length, in KB, should equal half the number of blocks, or 578 / 
> 2 = 289. And that's what we have.
>
> This is confirmed by the fact that if you let the simulator "autosize" 
> the 289KB images, it comes up with PDP-11 format.
>
> I verified, by patching the simulator, that there is data in both 
> halves of each 32b word in the image. This too points to a PDP-11 image.
>
> Even if the PDP-10 DECtape were packed with no  padding, it should be 
> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
> images were transcribed on a TC11 and are missing 2b in every 18b.
>
> This is not to say that the TD8E simulator is correct. I cannot get it 
> to zero (initialize) a fresh 18b DECtape through PIP10, so something 
> is broken. However, the TD8E is so arcane that it will take a 
> considerable period of time to figure out what the software is trying 
> to do and why the simulator is responding incorrectly.
>
> /Bob
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/a6f35470/attachment-0002.bin>

From bob at supnik.org  Thu Mar 28 07:45:31 2013
From: bob at supnik.org (Bob Supnik)
Date: Thu, 28 Mar 2013 07:45:31 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51541EB9.6080204@ieee.org>
References: <5153A601.2090004@supnik.org> <51541EB9.6080204@ieee.org>
Message-ID: <51542D5B.8030806@supnik.org>

I think you've got it, Tim. Here's what I've found:

05/13/2004  02:29 PM           295,936 J189B.DTA
05/13/2004  02:29 PM           295,936 J190C.DTA
05/13/2004  02:29 PM           295,936 J331A.DTA
06/24/2006  05:21 PM           295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta

The last is the image Tim provided.

Still have to debug PIP10; it would be easier with an OS/8 system 
generated for the TC08.

/Bob

On 3/28/2013 6:43 AM, Timothe Litt wrote:
> Bob,
>
> It might be useful to know exactly which images you tested.  A number 
> of the 'PDP-10 DECtape images' that turned up on a quick Google search 
> are actually for the PDP-11 front-end of a KL1090/1090.  These are in 
> fact 16-bit tapes: the file format would be Files-11 for RSX20F tapes; 
> I think the KLAD DECtapes were DOS-11 format, but it's been a while.  
> The KLAD tapes were accessed by the -11 and loaded into the -10 via 
> the DTE20.   This is distinct from 10-side DECtape diagnostics, which 
> also exist. Google 'AA-JS16A-TC' for some Files-11 format information; 
> I'd have to think a bit on the DOS-11 format.
>
> Knowing which images you're working with would let the custodians of 
> the images indicate their source, and perhaps from that we can work 
> back to the people/method/tools used to create them.
>
> Also, if the data that you're working with is in fact truncated saves 
> of 36-bit data, the directory block should still be recognizable.  
> Filenames are in sixbit, and the block numbers in links fit in 16 
> bits.  So the data should make sense, even if it is incomplete.  I 
> posted the key format information for TOPS-10 DECtapes a while back in 
> this string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.
>
> I could look at an image file if you need help untangling the data.
>
> On the pip10 /z, pip10 seems to use a private DTA service routine; 
> it's in the sources that I pointed you to earlier.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 27-Mar-13 22:08, Bob Supnik wrote:
>> I believe the PDP-10 DECtape images that are floating around the web 
>> may not be accurate transcriptions.
>>
>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
>> words in a 32b container (a 36b word in a 72b container). Thus, each 
>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
>> Therefore, the unage length, in KB, should equal the number of 
>> blocks, which is 578. And in fact, all extent 18b PDP DECtape images 
>> are 578KB long.
>>
>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
>> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
>> image length, in KB, should equal half the number of blocks, or 578 / 
>> 2 = 289. And that's what we have.
>>
>> This is confirmed by the fact that if you let the simulator 
>> "autosize" the 289KB images, it comes up with PDP-11 format.
>>
>> I verified, by patching the simulator, that there is data in both 
>> halves of each 32b word in the image. This too points to a PDP-11 image.
>>
>> Even if the PDP-10 DECtape were packed with no  padding, it should be 
>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
>> images were transcribed on a TC11 and are missing 2b in every 18b.
>>
>> This is not to say that the TD8E simulator is correct. I cannot get 
>> it to zero (initialize) a fresh 18b DECtape through PIP10, so 
>> something is broken. However, the TD8E is so arcane that it will take 
>> a considerable period of time to figure out what the software is 
>> trying to do and why the simulator is responding incorrectly.
>>
>> /Bob
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>



From bqt at softjar.se  Thu Mar 28 08:17:57 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 13:17:57 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5153A601.2090004@supnik.org>
References: <5153A601.2090004@supnik.org>
Message-ID: <515434F5.9090100@softjar.se>

On 2013-03-28 03:08, Bob Supnik wrote:
> I believe the PDP-10 DECtape images that are floating around the web may
> not be accurate transcriptions.
>
> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
> words in a 32b container (a 36b word in a 72b container). Thus, each
> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
> Therefore, the unage length, in KB, should equal the number of blocks,
> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
> long.
>
> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
> And that's what we have.
>
> This is confirmed by the fact that if you let the simulator "autosize"
> the 289KB images, it comes up with PDP-11 format.
>
> I verified, by patching the simulator, that there is data in both halves
> of each 32b word in the image. This too points to a PDP-11 image.
>
> Even if the PDP-10 DECtape were packed with no  padding, it should be
> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
> were transcribed on a TC11 and are missing 2b in every 18b.
>
> This is not to say that the TD8E simulator is correct. I cannot get it
> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
> broken. However, the TD8E is so arcane that it will take a considerable
> period of time to figure out what the software is trying to do and why
> the simulator is responding incorrectly.

I don't know if I'd call the TD8E arcane. Like I said before, it is the 
most stupid controller ever invented.
I had to write code last year to extract 18b images from a PDP-15 using 
the TD8E. Reading through the documentation, and reading through the 
TD8E driver as well as PIP10 was enough for me to understand how it 
worked, so you should be able to do the same.
Basically, the TD8E gives you almost nothing at all. You need to do just 
about all the fiddling yourself.
It is horribly stupid and primitive.

	Johnny



From litt at ieee.org  Thu Mar 28 08:24:16 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 08:24:16 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51542D5B.8030806@supnik.org>
References: <5153A601.2090004@supnik.org> <51541EB9.6080204@ieee.org>
 <51542D5B.8030806@supnik.org>
Message-ID: <51543670.90309@ieee.org>

J189B is the RSX20F V14-17 AUX dectape
J190C is the V14-45 system tape
J331A is the the V12-40 AUX tape.

All of these are Files-11 format (16-bit).

DCZBA decodes to a KA/KI diagnostic, but it turns out to be the 'basic 
peripheral diagnostic'; it probably wasn't renamed for the KL.  
According to the label on bitsavers 
(http://bitsavers.trailing-edge.com/bits/DEC/pdp10/dectape/diag/MAINDEC-10-DCZBA-C-UB_4-73.dta.txt), 
this is a 16-bit formatted tape containing 11-based KL10 diagnostics.  
So the filename may be wrong...

In any case, you don't have any -10 format DECtape images.

I have some physical 10-format tapes, but not the means to transcribe 
them. They're not of general interest; personal files.

I vaguely remember that someone has captured real 36-bit DECtapes, but 
the details escape me.  Al Kossow may remember...

A previous note pointed you to the OS/8 doc on how to configure for 
different hardware.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 07:45, Bob Supnik wrote:
> I think you've got it, Tim. Here's what I've found:
>
> 05/13/2004  02:29 PM           295,936 J189B.DTA
> 05/13/2004  02:29 PM           295,936 J190C.DTA
> 05/13/2004  02:29 PM           295,936 J331A.DTA
> 06/24/2006  05:21 PM           295,936 MAINDEC-10-DCZBA-C-UB_4-73.dta
>
> The last is the image Tim provided.
>
> Still have to debug PIP10; it would be easier with an OS/8 system 
> generated for the TC08.
>
> /Bob
>
> On 3/28/2013 6:43 AM, Timothe Litt wrote:
>> Bob,
>>
>> It might be useful to know exactly which images you tested.  A number 
>> of the 'PDP-10 DECtape images' that turned up on a quick Google 
>> search are actually for the PDP-11 front-end of a KL1090/1090.  These 
>> are in fact 16-bit tapes: the file format would be Files-11 for 
>> RSX20F tapes; I think the KLAD DECtapes were DOS-11 format, but it's 
>> been a while.  The KLAD tapes were accessed by the -11 and loaded 
>> into the -10 via the DTE20. This is distinct from 10-side DECtape 
>> diagnostics, which also exist. Google 'AA-JS16A-TC' for some Files-11 
>> format information; I'd have to think a bit on the DOS-11 format.
>>
>> Knowing which images you're working with would let the custodians of 
>> the images indicate their source, and perhaps from that we can work 
>> back to the people/method/tools used to create them.
>>
>> Also, if the data that you're working with is in fact truncated saves 
>> of 36-bit data, the directory block should still be recognizable.  
>> Filenames are in sixbit, and the block numbers in links fit in 16 
>> bits.  So the data should make sense, even if it is incomplete.  I 
>> posted the key format information for TOPS-10 DECtapes a while back 
>> in this string.  PDP-11 filenames were encoded in (PDP-11) Raxdix50.
>>
>> I could look at an image file if you need help untangling the data.
>>
>> On the pip10 /z, pip10 seems to use a private DTA service routine; 
>> it's in the sources that I pointed you to earlier.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>> On 27-Mar-13 22:08, Bob Supnik wrote:
>>> I believe the PDP-10 DECtape images that are floating around the web 
>>> may not be accurate transcriptions.
>>>
>>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b 
>>> words in a 32b container (a 36b word in a 72b container). Thus, each 
>>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage. 
>>> Therefore, the unage length, in KB, should equal the number of 
>>> blocks, which is 578. And in fact, all extent 18b PDP DECtape images 
>>> are 578KB long.
>>>
>>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 
>>> 256W x 16b DECtape block requires 1/2 KB of storage. Therefore, the 
>>> image length, in KB, should equal half the number of blocks, or 578 
>>> / 2 = 289. And that's what we have.
>>>
>>> This is confirmed by the fact that if you let the simulator 
>>> "autosize" the 289KB images, it comes up with PDP-11 format.
>>>
>>> I verified, by patching the simulator, that there is data in both 
>>> halves of each 32b word in the image. This too points to a PDP-11 
>>> image.
>>>
>>> Even if the PDP-10 DECtape were packed with no  padding, it should 
>>> be 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the 
>>> images were transcribed on a TC11 and are missing 2b in every 18b.
>>>
>>> This is not to say that the TD8E simulator is correct. I cannot get 
>>> it to zero (initialize) a fresh 18b DECtape through PIP10, so 
>>> something is broken. However, the TD8E is so arcane that it will 
>>> take a considerable period of time to figure out what the software 
>>> is trying to do and why the simulator is responding incorrectly.
>>>
>>> /Bob
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/f246d257/attachment-0002.bin>

From litt at ieee.org  Thu Mar 28 08:41:44 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 08:41:44 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <515434F5.9090100@softjar.se>
References: <5153A601.2090004@supnik.org> <515434F5.9090100@softjar.se>
Message-ID: <51543A88.5060802@ieee.org>

> I don't know if I'd call the TD8E arcane. 

I'll side with Bob on this one.  You would too, if you glance at the 
simh code for emulating it.  Even the imperfect emulation has to deal 
with mechanical timing - acceleration, deceleration and timing marks.   
(Imperfect = linear approximation; speed actually varies as a function 
of position due to the diameter changes as tape goes on and off the 
reels.)  And there are other oddities that software may or may not be 
sensitive to.  Like the fact that you don't just wait for acceleration; 
the tape moves, so the next valid block number over the read head is a 
function of when the tape is up to speed.  For the smart controllers, 
you don't see the block number until up-to-speed.  For the TD8E, I don't 
know.

Dumb hardware doesn't mean that the emulation is easy or simple. 
Sometimes it is; sometimes not.  This is not.


This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 08:17, Johnny Billquist wrote:
> On 2013-03-28 03:08, Bob Supnik wrote:
>> I believe the PDP-10 DECtape images that are floating around the web may
>> not be accurate transcriptions.
>>
>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
>> words in a 32b container (a 36b word in a 72b container). Thus, each
>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
>> Therefore, the unage length, in KB, should equal the number of blocks,
>> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
>> long.
>>
>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
>> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
>> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
>> And that's what we have.
>>
>> This is confirmed by the fact that if you let the simulator "autosize"
>> the 289KB images, it comes up with PDP-11 format.
>>
>> I verified, by patching the simulator, that there is data in both halves
>> of each 32b word in the image. This too points to a PDP-11 image.
>>
>> Even if the PDP-10 DECtape were packed with no  padding, it should be
>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
>> were transcribed on a TC11 and are missing 2b in every 18b.
>>
>> This is not to say that the TD8E simulator is correct. I cannot get it
>> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
>> broken. However, the TD8E is so arcane that it will take a considerable
>> period of time to figure out what the software is trying to do and why
>> the simulator is responding incorrectly.
>
> I don't know if I'd call the TD8E arcane. Like I said before, it is 
> the most stupid controller ever invented.
> I had to write code last year to extract 18b images from a PDP-15 
> using the TD8E. Reading through the documentation, and reading through 
> the TD8E driver as well as PIP10 was enough for me to understand how 
> it worked, so you should be able to do the same.
> Basically, the TD8E gives you almost nothing at all. You need to do 
> just about all the fiddling yourself.
> It is horribly stupid and primitive.
>
>     Johnny
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/0c844f29/attachment-0002.bin>

From bob at supnik.org  Thu Mar 28 11:43:54 2013
From: bob at supnik.org (Bob Supnik)
Date: Thu, 28 Mar 2013 11:43:54 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.133.1364473463.1077.simh@trailing-edge.com>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
Message-ID: <5154653A.8080004@supnik.org>

Johnny Billquist wrote:

I don't know if I'd call the TD8E arcane. Like I said before, it is the
most stupid controller ever invented.
I had to write code last year to extract 18b images from a PDP-15 using
the TD8E. Reading through the documentation, and reading through the
TD8E driver as well as PIP10 was enough for me to understand how it
worked, so you should be able to do the same.
Basically, the TD8E gives you almost nothing at all. You need to do just
about all the fiddling yourself.
It is horribly stupid and primitive.

I agree; and the TD8E simulator reads and writes OS/8 format DECtapes just fine.

The problem is that it doesn't work with Mark Bramhall's handcrafted DECtape drivers in PIP10. Tracing what the TD8E simulator is doing, versus what Mark's driver is expecting, is the complication.

On the TC08, all the cruft is hidden, and the simulator operates on a word-by-word basis. On the TD8E, all the cruft is exposed, and the simulator operates on a line-by-line basis. It also has to simulate the the mark track codes on a bit-by-bit basis. I suspect that the mark track simulation isn't quite right with non-standard block sizes.

/Bob



From bqt at softjar.se  Thu Mar 28 12:47:37 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 17:47:37 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51543A88.5060802@ieee.org>
References: <5153A601.2090004@supnik.org> <515434F5.9090100@softjar.se>
 <51543A88.5060802@ieee.org>
Message-ID: <51547429.1080206@softjar.se>

On 2013-03-28 13:41, Timothe Litt wrote:
>> I don't know if I'd call the TD8E arcane.
>
> I'll side with Bob on this one.  You would too, if you glance at the
> simh code for emulating it.  Even the imperfect emulation has to deal
> with mechanical timing - acceleration, deceleration and timing marks.
> (Imperfect = linear approximation; speed actually varies as a function
> of position due to the diameter changes as tape goes on and off the
> reels.)  And there are other oddities that software may or may not be
> sensitive to.  Like the fact that you don't just wait for acceleration;
> the tape moves, so the next valid block number over the read head is a
> function of when the tape is up to speed.  For the smart controllers,
> you don't see the block number until up-to-speed.  For the TD8E, I don't
> know.
>
> Dumb hardware doesn't mean that the emulation is easy or simple.
> Sometimes it is; sometimes not.  This is not.

I wasn't arguing that it was easy. In this case the opposite is 
definitely true. The TD8E is horrible. I've been saying that a number of 
times now. But I wouldn't call it arcane. It's simple.
That is the problem. It is too simple. It essentially exposes more or 
less just the electrical interface to the TU56, and that's it.

And that is the unfortunate part, because that means it exposes a very 
analog, stupid interface. It is very complex to emulate right, since it 
does so little.
Really. A TD8E does almost nothing. It is so simple and cheap it is 
ridiculous. The board have very little logic. And it was really cheap. 
And easy to design. And easy to manufacture.

It was the super-cheap option for a PDP-8 if you wanted DECtape.

Like I said, it is anything but complex in real life. Emulating it is a 
totally different story, for the same reason.

Depending on what you try to emulate, you can afford a few shortcuts. 
For OS/8, as well as all other DEC software I know of, you don't need to 
emulate the tape acceleration. You can pretend acceleration is 
instantaneous. Since all DEC software run the TD8E in polled mode, it is 
always just sitting there reading data until the right stuff comes. If 
you start feeding data a little earlier from the tape, it don't change 
anything.
Software like MULTOS, which actually try to use the TD8E in a 
timesharing system on the other hand, is a problem, since it does timing 
calculations for the tape to estimate how long before it comes to the 
right place, in order to not just do a polling loop all the time (not 
fun if you timeshare). However, no DEC software ever supported the TD8E 
in anything but just polled I/O.

(Yes, I really dislike the TD8E. And yes, I have a real one.)

	Johnny

>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 28-Mar-13 08:17, Johnny Billquist wrote:
>> On 2013-03-28 03:08, Bob Supnik wrote:
>>> I believe the PDP-10 DECtape images that are floating around the web may
>>> not be accurate transcriptions.
>>>
>>> All the images are 289KB long. An 18b (36b) DECtape consists of 18b
>>> words in a 32b container (a 36b word in a 72b container). Thus, each
>>> 256W x 18b (128W x 36b) DECtape block requires 1KB of dusj storage.
>>> Therefore, the unage length, in KB, should equal the number of blocks,
>>> which is 578. And in fact, all extent 18b PDP DECtape images are 578KB
>>> long.
>>>
>>> A 16b DECtape consists of 16b words in a 16b container. Thus, each 256W
>>> x 16b DECtape block requires 1/2 KB of storage. Therefore, the image
>>> length, in KB, should equal half the number of blocks, or 578 / 2 = 289.
>>> And that's what we have.
>>>
>>> This is confirmed by the fact that if you let the simulator "autosize"
>>> the 289KB images, it comes up with PDP-11 format.
>>>
>>> I verified, by patching the simulator, that there is data in both halves
>>> of each 32b word in the image. This too points to a PDP-11 image.
>>>
>>> Even if the PDP-10 DECtape were packed with no  padding, it should be
>>> 18/16 = 9/8 the size of a PDP-11 image, or 325+KB. So I think the images
>>> were transcribed on a TC11 and are missing 2b in every 18b.
>>>
>>> This is not to say that the TD8E simulator is correct. I cannot get it
>>> to zero (initialize) a fresh 18b DECtape through PIP10, so something is
>>> broken. However, the TD8E is so arcane that it will take a considerable
>>> period of time to figure out what the software is trying to do and why
>>> the simulator is responding incorrectly.
>>
>> I don't know if I'd call the TD8E arcane. Like I said before, it is
>> the most stupid controller ever invented.
>> I had to write code last year to extract 18b images from a PDP-15
>> using the TD8E. Reading through the documentation, and reading through
>> the TD8E driver as well as PIP10 was enough for me to understand how
>> it worked, so you should be able to do the same.
>> Basically, the TD8E gives you almost nothing at all. You need to do
>> just about all the fiddling yourself.
>> It is horribly stupid and primitive.
>>
>>     Johnny
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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


From bqt at softjar.se  Thu Mar 28 12:53:42 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 17:53:42 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <5154653A.8080004@supnik.org>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <5154653A.8080004@supnik.org>
Message-ID: <51547596.8000900@softjar.se>

On 2013-03-28 16:43, Bob Supnik wrote:
> Johnny Billquist wrote:
>
>> Basically, the TD8E gives you almost nothing at all. You need to do just
>> about all the fiddling yourself.
>> It is horribly stupid and primitive.
>
> I agree; and the TD8E simulator reads and writes OS/8 format DECtapes
> just fine.

Even that is actually quite an accomplishment, if you ask me.

> The problem is that it doesn't work with Mark Bramhall's handcrafted
> DECtape drivers in PIP10. Tracing what the TD8E simulator is doing,
> versus what Mark's driver is expecting, is the complication.

I bet.

> On the TC08, all the cruft is hidden, and the simulator operates on a
> word-by-word basis. On the TD8E, all the cruft is exposed, and the
> simulator operates on a line-by-line basis. It also has to simulate the
> the mark track codes on a bit-by-bit basis. I suspect that the mark
> track simulation isn't quite right with non-standard block sizes.

Yes. The TC08 is a sane thing in comparison. Not to mention that the 
emulation can be done at a reasonable level.
I would also suspect the mark track simulation. That is where most of 
the magic happens.

Sorry that I can't offer more help. I'm way too busy with other things 
right now to add yet another project. All I can do is to make some 
comments that I hope might atleast offer encouragement. (I did send some 
patches to the VAX8600 code in simh last week, and I'm trying to fix 
NetBSD working on that emulation, as well as all my pdp11-related work 
(not all simh related though)...)

	Johnny

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


From baker at usgs.gov  Thu Mar 28 14:09:40 2013
From: baker at usgs.gov (Larry Baker)
Date: Thu, 28 Mar 2013 11:09:40 -0700
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.133.1364473463.1077.simh@trailing-edge.com>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
Message-ID: <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>

On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> Google 'AA-JS16A-TC' for some Files-11 format information; I'd 
> have to think a bit on the DOS-11 format.


RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also used HDR3/4 labels for RMS information.  There was a MOUNT option to suppress writing those labels.

I wrote an RSX/VMS  program that will scan an unknown tape and decode it for you.  (If anyone wants it, let me know where I should upload it.)  The DOS format decoder looks for a 14 byte (physical) record at the start of the file.  It is decoded by the following code:

C
C...  DEC DOS labels
C
      Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
      Call R50ASC ( 3, buffer(13), ascbuf( 7) )
      ascbuf(10) = '.'
      Call R50ASC ( 3, buffer( 5), ascbuf(11) )
      ltemp(1) = buffer(7)
      ltemp(2) = 0
      mem = itemp
      ltemp(1) = buffer(8)
      grp = itemp
      ltemp(1) = buffer(11)
      ltemp(2) = buffer(12)
      jday = MOD(itemp,1000)
      year = itemp/1000 + 70
      Call JDCONV ( jday, mon, day, year )
      ltemp(1) = buffer( 9)
      ltemp(2) = buffer(10)
      Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
     1                   year, itemp
  619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
     1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')

The DOS label contents are:

Words 1-2 RAD50 characters 1-6 of the file name part (before the implied period)
Word 3 RAD50 characters 1-3 of the file type (after the implied period)
Word 4 Octal File owner's User Identification Code (group code in high-order byte, member code in low-order byte)
Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
Word 6 Octal File protection (low-order to high-order RWED bits: read, write, extend, delete; grouped low-order to high-order for system, owner, group, world)
Word 7 RAD50 characters 7-9 of the file name part (before the implied period)

The references I used to write the program (back in the 1980's) are below.  Which reference had the DOS label format I don't remember (if any of them did).

6  References

[1]  American National Standards Institute, 1978, Magnetic Tape Labels
     and File Structure for Information Interchange (ANSI X3.27-1978).

[2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
     Manual (Order no. AA-FD10A-TC).

[3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
     Manual (Order no. AA-FD04A-TC).

[4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
     Operations Reference Manual (Order no. AA-FD14A-TC).

[5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus   I/O   Drivers
     Reference Manual (Order no. AA-FD09A-TC).

[6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
     Reference Manual (Order no. AA-Z408A-TE).

[7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
     AA-Z200C-TE).

[8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
     Manual (Order no. AA-Z424C-TE).

[9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
     Tape Operations (Order no. AI-Y506B-TE).

[10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
     Manual:  Part I (Order no. AA-Z600C-TE).

[11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
     (Order No. GC26-3795-1).

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/92355a70/attachment-0002.html>

From litt at ieee.org  Thu Mar 28 14:23:57 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 14:23:57 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov>
Message-ID: <51548ABD.7060708@ieee.org>

Good information, but this thread is about DECtape, not 9-Track magtapes...

The format looks about right for 9-track DOS-11 magtapes; I remember 
writing code to extract files from them on the -10.

It's not right (or at least, not complete) for the block-addressable 
DECtapes.

I don't think DOS-11 would have been documented in any of the references 
cited.

There's now a SIMH repo on github; your utility could go into the tools 
section.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 14:09, Larry Baker wrote:
> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> 
> <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> wrote:
>
>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>> have to think a bit on the DOS-11 format.
>
> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also 
> used HDR3/4 labels for RMS information.  There was a MOUNT option to 
> suppress writing those labels.
>
> I wrote an RSX/VMS  program that will scan an unknown tape and decode 
> it for you.  (If anyone wants it, let me know where I should upload 
> it.)  The DOS format decoder looks for a 14 byte (physical) record at 
> the start of the file.  It is decoded by the following code:
>
> C
> C...  DEC DOS labels
> C
>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>       ascbuf(10) = '.'
>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>       ltemp(1) = buffer(7)
>       ltemp(2) = 0
>       mem = itemp
>       ltemp(1) = buffer(8)
>       grp = itemp
>       ltemp(1) = buffer(11)
>       ltemp(2) = buffer(12)
>       jday = MOD(itemp,1000)
>       year = itemp/1000 + 70
>       Call JDCONV ( jday, mon, day, year )
>       ltemp(1) = buffer( 9)
>       ltemp(2) = buffer(10)
>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>      1                   year, itemp
>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>
> The DOS label contents are:
>
> Words 1-2 RAD50 characters 1-6 of the file name part (before the 
> implied period)
> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
> Word 4 Octal File owner's User Identification Code (group code in 
> high-order byte, member code in low-order byte)
> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
> Word 6 Octal File protection (low-order to high-order RWED bits: read, 
> write, extend, delete; grouped low-order to high-order for system, 
> owner, group, world)
> Word 7 RAD50 characters 7-9 of the file name part (before the implied 
> period)
>
> The references I used to write the program (back in the 1980's) are 
> below.  Which reference had the DOS label format I don't remember (if 
> any of them did).
>
> 6  References
>
> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>      and File Structure for Information Interchange (ANSI X3.27-1978).
>
> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
>      Manual (Order no. AA-FD10A-TC).
>
> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
>      Manual (Order no. AA-FD04A-TC).
>
> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
>      Operations Reference Manual (Order no. AA-FD14A-TC).
>
> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O   Drivers
>      Reference Manual (Order no. AA-FD09A-TC).
>
> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>      Reference Manual (Order no. AA-Z408A-TE).
>
> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>      AA-Z200C-TE).
>
> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
>      Manual (Order no. AA-Z424C-TE).
>
> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>      Tape Operations (Order no. AI-Y506B-TE).
>
> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
>      Manual:  Part I (Order no. AA-Z600C-TE).
>
> [11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
>      (Order No. GC26-3795-1).
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov <mailto:baker at usgs.gov>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/1a6d7fe0/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/1a6d7fe0/attachment-0002.bin>

From bqt at softjar.se  Thu Mar 28 15:19:41 2013
From: bqt at softjar.se (Johnny Billquist)
Date: Thu, 28 Mar 2013 20:19:41 +0100
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <51548ABD.7060708@ieee.org>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov> <51548ABD.7060708@ieee.org>
Message-ID: <515497CD.2020201@softjar.se>

On 2013-03-28 19:23, Timothe Litt wrote:
> Good information, but this thread is about DECtape, not 9-Track magtapes...

Right.

> The format looks about right for 9-track DOS-11 magtapes; I remember
> writing code to extract files from them on the -10.
>
> It's not right (or at least, not complete) for the block-addressable
> DECtapes.

DECtapes (atleast on RSX) are Files-11 ODS-1 volumes, and not ANSI 
labelled tapes. They have nothing in common with each other, apart from 
both being tapes. The closest relative to a DECtape is a floppy.

Also, the DOS-11 tape format is not the same as ANSI labelled tapes. 
They are not compatible.

In RSX, ANSI labelled tapes are accessed through MTAACP, and the tapes 
are mounted as a known format. You then access them with the normal 
tools you'd use for any normal work in RSX. (Such as PIP.)
DOS-11 tapes are instead mounted foreign, and you need FLX to read/write 
to them.

	Johnny

> I don't think DOS-11 would have been documented in any of the references
> cited.
>
> There's now a SIMH repo on github; your utility could go into the tools
> section.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 28-Mar-13 14:09, Larry Baker wrote:
>> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com
>> <mailto:simh-request at trailing-edge.com>>
>> <simh-request at trailing-edge.com
>> <mailto:simh-request at trailing-edge.com>> wrote:
>>
>>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>>> have to think a bit on the DOS-11 format.
>>
>> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also
>> used HDR3/4 labels for RMS information.  There was a MOUNT option to
>> suppress writing those labels.
>>
>> I wrote an RSX/VMS  program that will scan an unknown tape and decode
>> it for you.  (If anyone wants it, let me know where I should upload
>> it.)  The DOS format decoder looks for a 14 byte (physical) record at
>> the start of the file.  It is decoded by the following code:
>>
>> C
>> C...  DEC DOS labels
>> C
>>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>>       ascbuf(10) = '.'
>>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>>       ltemp(1) = buffer(7)
>>       ltemp(2) = 0
>>       mem = itemp
>>       ltemp(1) = buffer(8)
>>       grp = itemp
>>       ltemp(1) = buffer(11)
>>       ltemp(2) = buffer(12)
>>       jday = MOD(itemp,1000)
>>       year = itemp/1000 + 70
>>       Call JDCONV ( jday, mon, day, year )
>>       ltemp(1) = buffer( 9)
>>       ltemp(2) = buffer(10)
>>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>>      1                   year, itemp
>>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>>
>> The DOS label contents are:
>>
>> Words 1-2 RAD50 characters 1-6 of the file name part (before the
>> implied period)
>> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
>> Word 4 Octal File owner's User Identification Code (group code in
>> high-order byte, member code in low-order byte)
>> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian day )
>> Word 6 Octal File protection (low-order to high-order RWED bits: read,
>> write, extend, delete; grouped low-order to high-order for system,
>> owner, group, world)
>> Word 7 RAD50 characters 7-9 of the file name part (before the implied
>> period)
>>
>> The references I used to write the program (back in the 1980's) are
>> below.  Which reference had the DOS label format I don't remember (if
>> any of them did).
>>
>> 6  References
>>
>> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>>      and File Structure for Information Interchange (ANSI X3.27-1978).
>>
>> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR  Operations
>>      Manual (Order no. AA-FD10A-TC).
>>
>> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command  Language
>>      Manual (Order no. AA-FD04A-TC).
>>
>> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and  Micro/RSX  I/O
>>      Operations Reference Manual (Order no. AA-FD14A-TC).
>>
>> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O   Drivers
>>      Reference Manual (Order no. AA-FD09A-TC).
>>
>> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>>      Reference Manual (Order no. AA-Z408A-TE).
>>
>> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>>      AA-Z200C-TE).
>>
>> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility  Reference
>>      Manual (Order no. AA-Z424C-TE).
>>
>> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>>      Tape Operations (Order no. AI-Y506B-TE).
>>
>> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's  Reference
>>      Manual:  Part I (Order no. AA-Z600C-TE).
>>
>> [11] International Business Machines Corp., 1978,  OS/VS  Tape  Labels
>>      (Order No. GC26-3795-1).
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker at usgs.gov <mailto:baker at usgs.gov>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


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


From baker at usgs.gov  Thu Mar 28 15:50:18 2013
From: baker at usgs.gov (Larry Baker)
Date: Thu, 28 Mar 2013 12:50:18 -0700
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <mailman.137.1364498391.1077.simh@trailing-edge.com>
References: <mailman.137.1364498391.1077.simh@trailing-edge.com>
Message-ID: <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>

On 28 Mar 2013, at 12:19 PM, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> It's not right (or at least, not complete) for the block-addressable 
> DECtapes.


Right.  I forgot DECtapes are block addressable.

Does anyone need any RSX Files-11 on-disk format documentation?  I have a paper copy of Andy Goldstein's 1979 Files-11 documentation.  I imagine Al does too.  I could try to find out what the RSX manuals say about the initialization parameters used for a DECtape.  It is quote likely they don't make DECtape a special case, but use the same parameters for any small capacity disk (like a floppy).

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/72893cbc/attachment-0002.html>

From litt at ieee.org  Thu Mar 28 16:09:56 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 16:09:56 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <515497CD.2020201@softjar.se>
References: <mailman.133.1364473463.1077.simh@trailing-edge.com>
 <AFAC523A-E0FD-432D-802F-0224D8A210C1@usgs.gov> <51548ABD.7060708@ieee.org>
 <515497CD.2020201@softjar.se>
Message-ID: <5154A394.70905@ieee.org>

I guess I'm not allowed a convenient memory lapse.

DOS-11 predates RSX & Files-11.  It has a MFD/UFD directory structure, 
vaguely echoing TOPS-10.  I think that the 14-bye tape file header is 
most of the directory entry from the on-disk DOS-11 structure.  This 
caused some grief on tape, as the ANSI standard (and some 
drives/drivers) require a minimum record length of 18 bytes; thus the 
directory entries on MM could be skipped as 'noise records'.

The DECtape file structure for DOS-11 is documented in 
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/dos-batch/DOS_CourseHandouts.pdf, 
mostly in 
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/dos-batch/DosBatchHandbook_v9_Apr74/02.pdf, 
with other random bits in the other chapters.

It's not the same as RSX or RT.  Different design goals - and different 
engineering groups :-)

DOS was serially multi-user.  So it had permissions, contiguous and 
linked files.  RT single user; no permissions, contiguous only.  RSX got 
Files-11 - the everything to everyone format - at the cost of ACPs, 
complexity and memory.

I think - but I'd have to dissect a tape - that KLDCP used the DOS file 
structure on -11 DECtape for simplicity, and the fact that there were 
interchange programs (flx,etc) that could read/write them on the other 
OSs.  It was the least common denominator file structure.

Of course, DTAs were so slow and expensive that you wanted to run from 
disk instead, even when floppies replaced DECtape as the KL's front-end 
device.

In any case, the simh problem appears to be a low-level format 
emulation; my remarks on the file structure were only provided to assist 
in identifying the data.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 15:19, Johnny Billquist wrote:
> On 2013-03-28 19:23, Timothe Litt wrote:
>> Good information, but this thread is about DECtape, not 9-Track 
>> magtapes...
>
> Right.
>
>> The format looks about right for 9-track DOS-11 magtapes; I remember
>> writing code to extract files from them on the -10.
>>
>> It's not right (or at least, not complete) for the block-addressable
>> DECtapes.
>
> DECtapes (atleast on RSX) are Files-11 ODS-1 volumes, and not ANSI 
> labelled tapes. They have nothing in common with each other, apart 
> from both being tapes. The closest relative to a DECtape is a floppy.
>
> Also, the DOS-11 tape format is not the same as ANSI labelled tapes. 
> They are not compatible.
>
> In RSX, ANSI labelled tapes are accessed through MTAACP, and the tapes 
> are mounted as a known format. You then access them with the normal 
> tools you'd use for any normal work in RSX. (Such as PIP.)
> DOS-11 tapes are instead mounted foreign, and you need FLX to 
> read/write to them.
>
>     Johnny
>
>> I don't think DOS-11 would have been documented in any of the references
>> cited.
>>
>> There's now a SIMH repo on github; your utility could go into the tools
>> section.
>>
>> This communication may not represent my employer's views,
>> if any, on the matters discussed.
>>
>> On 28-Mar-13 14:09, Larry Baker wrote:
>>> On 28 Mar 2013, at 5:24 AM, <simh-request at trailing-edge.com
>>> <mailto:simh-request at trailing-edge.com>>
>>> <simh-request at trailing-edge.com
>>> <mailto:simh-request at trailing-edge.com>> wrote:
>>>
>>>> Google 'AA-JS16A-TC' for some Files-11 format information; I'd
>>>> have to think a bit on the DOS-11 format.
>>>
>>> RSX/VMS Files-11 tapes are ANSI labeled tapes.  I know OpenVMS also
>>> used HDR3/4 labels for RMS information.  There was a MOUNT option to
>>> suppress writing those labels.
>>>
>>> I wrote an RSX/VMS  program that will scan an unknown tape and decode
>>> it for you.  (If anyone wants it, let me know where I should upload
>>> it.)  The DOS format decoder looks for a 14 byte (physical) record at
>>> the start of the file.  It is decoded by the following code:
>>>
>>> C
>>> C...  DEC DOS labels
>>> C
>>>       Call R50ASC ( 6, buffer( 1), ascbuf( 1) )
>>>       Call R50ASC ( 3, buffer(13), ascbuf( 7) )
>>>       ascbuf(10) = '.'
>>>       Call R50ASC ( 3, buffer( 5), ascbuf(11) )
>>>       ltemp(1) = buffer(7)
>>>       ltemp(2) = 0
>>>       mem = itemp
>>>       ltemp(1) = buffer(8)
>>>       grp = itemp
>>>       ltemp(1) = buffer(11)
>>>       ltemp(2) = buffer(12)
>>>       jday = MOD(itemp,1000)
>>>       year = itemp/1000 + 70
>>>       Call JDCONV ( jday, mon, day, year )
>>>       ltemp(1) = buffer( 9)
>>>       ltemp(2) = buffer(10)
>>>       Write (STDOUT,619) ifile, grp, mem, ascbuf, day, month(mon),
>>>      1                   year, itemp
>>>   619 Format (//' File ', I4, ':', T34, '"', '[', O3.3, ',', O3.3, ']',
>>>      1        13A1, 2X, I2, '-', A, '-', I2.2, '  <', O3.3, '>', '"')
>>>
>>> The DOS label contents are:
>>>
>>> Words 1-2 RAD50 characters 1-6 of the file name part (before the
>>> implied period)
>>> Word 3 RAD50 characters 1-3 of the file type (after the implied period)
>>> Word 4 Octal File owner's User Identification Code (group code in
>>> high-order byte, member code in low-order byte)
>>> Word 5 Binary File creation date ( 1000 * ( year - 1970 ) + Julian 
>>> day )
>>> Word 6 Octal File protection (low-order to high-order RWED bits: read,
>>> write, extend, delete; grouped low-order to high-order for system,
>>> owner, group, world)
>>> Word 7 RAD50 characters 7-9 of the file name part (before the implied
>>> period)
>>>
>>> The references I used to write the program (back in the 1980's) are
>>> below.  Which reference had the DOS label format I don't remember (if
>>> any of them did).
>>>
>>> 6  References
>>>
>>> [1]  American National Standards Institute, 1978, Magnetic Tape Labels
>>>      and File Structure for Information Interchange (ANSI X3.27-1978).
>>>
>>> [2]  Digital Equipment  Corp.,  1985,  RSX-11M/M-Plus  MCR Operations
>>>      Manual (Order no. AA-FD10A-TC).
>>>
>>> [3]  Digital Equipment  Corp.,  1985,  RSX-11M-Plus  Command Language
>>>      Manual (Order no. AA-FD04A-TC).
>>>
>>> [4]  Digital Equipment Corp., 1985, RSX-11M/M-Plus and Micro/RSX  I/O
>>>      Operations Reference Manual (Order no. AA-FD14A-TC).
>>>
>>> [5]  Digital  Equipment  Corp.,  1985,  RSX-11M/M-Plus I/O Drivers
>>>      Reference Manual (Order no. AA-FD09A-TC).
>>>
>>> [6]  Digital Equipment Corp., 1984, VAX/VMS Command Definition Utility
>>>      Reference Manual (Order no. AA-Z408A-TE).
>>>
>>> [7]  Digital Equipment Corp., 1986, VAX/VMS DCL Dictionary (Order  no.
>>>      AA-Z200C-TE).
>>>
>>> [8]  Digital Equipment Corp., 1984, VAX/VMS  Mount  Utility Reference
>>>      Manual (Order no. AA-Z424C-TE).
>>>
>>> [9]  Digital Equipment Corp., 1986, Guide to VAX/VMS Disk and Magnetic
>>>      Tape Operations (Order no. AI-Y506B-TE).
>>>
>>> [10] Digital Equipment  Corp.,  1986,  VAX/VMS  I/O  User's Reference
>>>      Manual:  Part I (Order no. AA-Z600C-TE).
>>>
>>> [11] International Business Machines Corp., 1978,  OS/VS Tape  Labels
>>>      (Order No. GC26-3795-1).
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> baker at usgs.gov <mailto:baker at usgs.gov>
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/3a3271fb/attachment-0002.bin>

From litt at ieee.org  Thu Mar 28 16:16:05 2013
From: litt at ieee.org (Timothe Litt)
Date: Thu, 28 Mar 2013 16:16:05 -0400
Subject: [Simh] PDP-10 DECtapes
In-Reply-To: <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>
References: <mailman.137.1364498391.1077.simh@trailing-edge.com>
 <AC4EDCFF-A03B-4C08-8F1D-4B2C97A67484@usgs.gov>
Message-ID: <5154A505.6060202@ieee.org>

> Does anyone need any RSX Files-11 on-disk format documentation?

I have hardcopy ODS-1 and ODS-2 documentation.  But it's not necessary 
for the current work; I've identified the tapes by other means.  I'm 
sure Al will chime in if he doesn't have a copy.

No need for further research; thanks.

This communication may not represent my employer's views,
if any, on the matters discussed.

On 28-Mar-13 15:50, Larry Baker wrote:
> On 28 Mar 2013, at 12:19 PM, <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> 
> <simh-request at trailing-edge.com 
> <mailto:simh-request at trailing-edge.com>> wrote:
>
>> It's not right (or at least, not complete) for the block-addressable
>> DECtapes.
>
> Right.  I forgot DECtapes are block addressable.
>
> Does anyone need any RSX Files-11 on-disk format documentation?  I 
> have a paper copy of Andy Goldstein's 1979 Files-11 documentation.  I 
> imagine Al does too.  I could try to find out what the RSX manuals say 
> about the initialization parameters used for a DECtape.  It is quote 
> likely they don't make DECtape a special case, but use the same 
> parameters for any small capacity disk (like a floppy).
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov <mailto:baker at usgs.gov>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/7ee5bf61/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130328/7ee5bf61/attachment-0002.bin>

From radioengr at gmail.com  Fri Mar 29 14:12:52 2013
From: radioengr at gmail.com (Rob Doyle)
Date: Fri, 29 Mar 2013 11:12:52 -0700
Subject: [Simh] PDP8, Adventure, and SIMH
Message-ID: <5155D9A4.5080107@gmail.com>


I just noticed that my PDP8 FPGA implementation differs from SIMH
when dealing with mixed/lower case text.

I also checked the operation on David Gesswein's online PDP8 and the
operation of a real PDP8 matches the operation of my PDP8 FPGA and
differs from SIMH.

I did use exactly the same RK05 disk image for both SIMH and the PDP8
FPGA. The image for the real PDP8 /could/ be different.

I'm guessing that SIMH intentionally forces upper case because I didn't
do anything special to the PDP8 FPGA. I didn't see any SIMH
configuration options to change this.

Is this intentional?

Rob.

*------ Using SIMH ------*

.EX ADVENT.LD

WELCOME TO ADVENTURE!!  WOULD YOU LIKE INSTRUCTIONS?

 > YES
SOMEWHERE NEARBY IS COLOSSAL CAVE, WHERE OTHERS HAVE FOUND FORTUNES
IN TREASURE AND GOLD,THOUGH IT IS RUMORED THAT SOME WHO ENTER ARE NEVER
SEEN AGAIN. MAGIC IS SAID TO WORK IN THE CAVE.  I WILL BE YOUR EYES
AND HANDS.  DIRECT ME WITH COMMANDS OF 1 OR 2 WORDS.  I SHOULD WARN
YOU THAT I LOOK AT ONLY THE FIRST FOUR LETTERS OF EACH WORD,SO YOU'LL
HAVE TO ENTER "NORTHEAST" AS "NE" TO DISTINGUISH IT FROM "NORTH".
(SHOULD YOU GET STUCK, TYPE "HELP" FOR SOME GENERAL HINTS.  FOR
INFORMATION ON HOW TO END YOUR ADVENTURE, ETC., TYPE "INFO".)
       - - -
THIS PROGRAM WAS ORIGINALLY DEVELOPED BY WILLIE CROWTHER. MOST OF
THE FEATURES OF THE CURRENT PROGRAM WERE ADDED BY DON WOODS.
THIS VERSION, FOR THE PDP-8, WAS DONE BY DICK MURPHY. IT IS
BASED ON A VERSION FOR RT-11 DONE BY BOB SUPNIK.

* ------ My PDP8 FPGA: ------ *

.EX ADVENT.LD

Welcome to Adventure!!  Would you like instructions?

 > yes
Somewhere nearby is Colossal Cave, where others have found fortunes
in treasure and gold,though it is rumored that some who enter are never
seen again. Magic is said to work in the cave.  I will be your eyes
and hands.  Direct me with commands of 1 or 2 words.  I should warn
you that I look at only the first four letters of each word,so you'll
have to enter "northeast" as "ne" to distinguish it from "north".
(Should you get stuck, type "help" for some general hints.  For
information on how to end your adventure, etc., type "INFO".)
       - - -
This program was originally developed by Willie Crowther. Most of
the features of the current program were added by Don Woods.
This version, for the PDP-8, was done by Dick Murphy. it is
based on a version for RT-11 done by Bob Supnik.

* ------ David Gesswein's Online PDP8: ------ *

RUN RKB0:ADVENT
 

Welcome to Adventure!! Would you like instructions?

YES
Somewhere nearby is Colossal Cave, where others have found fortunes
in treasure and gold,though it is rumored that some who enter are never
seen again. Magic is said to work in the cave. I will be your eyes
and hands. Direct me with commands of 1 or 2 words. I should warn
you that I look at only the first four letters of each word,so you'll
have to enter "northeast" as "ne" to distinguish it from "north".
(Should you get stuck, type "help" for some general hints. For
information on how to end your adventure, etc., type "INFO".)
- - -
This program was originally developed by Willie Crowther. Most of
the features of the current program were added by Don Woods.
This version, for the PDP-8, was done by Dick Murphy. it is
based on a version for RT-11 done by Bob Supnik.