date:20130319

Re: [Simh] Non-2^n architectures - Re: PIP10 on PDP-8 SIM

2013-03-19 Thread Rob Doyle


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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Non-2^n architectures - Re: PIP10 on PDP-8 SIM

2013-03-19 Thread Toby Thain


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



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Why 36-bit computing?

2013-03-19 Thread Dave L

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-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com]
On Behalf Of Ian King
Sent: 19 March 2013 19:05
To: simh@trailing-edge.com
Subject: Re: [Simh] Why 36-bit computing?

> -Original Message-
> From: simh-boun...@trailing-edge.com [mailto:simh-bounces@trailing- 
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh@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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Johnny Billquist


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

Re: [Simh] Why 36-bit computing?

2013-03-19 Thread Ian King

> -Original Message-
> From: simh-boun...@trailing-edge.com [mailto:simh-bounces@trailing-
> edge.com] On Behalf Of Michael Mondy
> Sent: Tuesday, March 19, 2013 7:37 AM
> To: simh@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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Why 36-bit computing?

2013-03-19 Thread Sergey Oboguev

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 
To: simh@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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] DECtape format(s)

2013-03-19 Thread Bob Supnik

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 077 (-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






___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Why 36-bit computing?

2013-03-19 Thread Bob Armstrong

>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



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Why 36-bit computing?

2013-03-19 Thread Michael Mondy

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@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Timothe Litt

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:

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 Mo

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Shoppa, Tim

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-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Armistead, Jason
Sent: Tuesday, March 19, 2013 9:30 AM
To: simh@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-boun...@trailing-edge.com 
[mailto:simh-boun...@trailing-edge.com] On Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh@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 befor

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Johnny Billquist

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-boun...@trailing-edge.com
[mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Timothe Litt
*Sent:* Tuesday, 19 March 2013 9:03 AM
*To:* simh@trailing-edge.com
*Subject:* Re: [Simh] PIP10 on PDP-8 SIM

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 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,
whe

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Armistead, Jason

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-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh@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 diffe

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Johnny Billquist


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

Re: [Simh] PIP10 on PDP-8 SIM

2013-03-19 Thread Timothe Litt

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 gory details of the format are in the Monitor Calls manual (TOPS-10).

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

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 writ

Re: [Simh] Non-2^n architectures - Re: PIP10 on PDP-8 SIM

[Simh] Non-2^n architectures - Re: PIP10 on PDP-8 SIM

Re: [Simh] Why 36-bit computing?

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] Why 36-bit computing?

Re: [Simh] Why 36-bit computing?

[Simh] DECtape format(s)

Re: [Simh] Why 36-bit computing?

[Simh] Why 36-bit computing?

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] PIP10 on PDP-8 SIM

Re: [Simh] PIP10 on PDP-8 SIM

15 matches

Site Navigation

Mail list logo

Footer information