Re: Other then being original is there any reason to get a RX02 ?

[Ethan Dicks]

On Thu, Jun 23, 2016 at 1:17 PM, Pete Lancashire
 wrote:
> Someday I want to have a PDP11 even if it is a QBUS version
>
> I can get a clean RX02 for about $150. When my life involved PDP11's
> starting with 34A and ending with 44's I never used one.

They are useful on low-end systems, like an RT-11 machine when you
don't have some form of hard drive (RQDXn + RD5x or RL(V)11 + RL01 or
RL02, etc...)  If you have a PDP-11 with a hard drive, they can be
handy for trading files with another machine with an RX02, but if you
don't need 8" floppies, and you have another option, they aren't
essential.  As you have already experienced, there are plenty of
machines that don't/didn't have them.

At one point, they were an obvious choice for a small machine.  Unless
you are dead set on a 100% DEC box, I think there are plenty of
options that don't involve floppies.  One inexpensive one is TU58
emulation (via PC-based or microcontroller-based tape emulator + one
spare serial port on your PDP-11, easy in the Qbus world because the
DLV11J is cheap and plentiful)

If you want a 100% authentic machine, there are lots of configurations
that would include an RX02.

Oh... and if you want to also dabble with the PDP-8, the same RX02
would be useful on an RX8E, and that was a very ordinary PDP-8
configuration (and much easier to put together than a hard-disk-based
machine, because there are fewer options there).

-ethan

Other then being original is there any reason to get a RX02 ?

[Pete Lancashire]

Someday I want to have a PDP11 even if it is a QBUS version

I can get a clean RX02 for about $150. When my life involved PDP11's
starting with 34A and ending with 44's I never used one.

-pete

Re: CDC 6600 - Why so awesome?

[Jon Elson]

On 06/23/2016 10:28 PM, James Vess wrote:

Hey guys,

I was looking and found that the Tektronix 4010 is a calligraphic display,
for which I found a video!
https://www.youtube.com/watch?v=IztxeoHhoyM

Let me know if it bares a resemblance to the display on the 6600


It wasn't normally used in that manner, except for 
graphing.  It had a 5 x 7 dot matrix generator and would 
display essentially a similar way to a glass TTY terminal.  
But, if you had graphs, 3D drawings or fancy lettering, you 
could draw it stroke by stroke.  That was a lot slower, of 
course.


Jon

Re: CDC 6600 - Why so awesome?

[James Vess]

Hey guys,

I was looking and found that the Tektronix 4010 is a calligraphic display,
for which I found a video!
https://www.youtube.com/watch?v=IztxeoHhoyM

Let me know if it bares a resemblance to the display on the 6600

On Wed, Jun 22, 2016 at 10:32 AM, Swift Griggs 
wrote:

> On Tue, 21 Jun 2016, Chuck Guzis wrote:
> > > - It had some wicked cool "demos", to cop a C64 term. (ADC, PAC, EYE)
> > Those were mostly toys to amuse the CEs, like the baseball game BAT.
>
> I was trying to find some video of one of those actually running. I wanted
> to see how the "calligraphic displays" painted the graphics. Do you happen
> to know why they went with two displays like that? Did the two have
> different purposes?
>
> > Chess 3.0 was implemented on Northwestern's machine and probably was the
> > first computer chess program of note.  This was before kids thought that
> > computer games were *cool*.  I never developed a taste for computer
> > gaming.
>
> Most folks I know who were in their 20s or 30s in the 60s or 70s didn't,
> either. However, computer games were the "hook" that got a lot of people
> like me interested in computing as children. I instantly became more
> interested in creating the games, not just playing them. I've known a lot
> of others with the same sort of instincts.
>
> > Much of the architectural concept was shared with IBM 7030 STRETCH
> > (another system worth researching).
>
> Hmm, I've never heard of it. I'll check it out. Thanks.
>
> > > - It wasn't DEC and it wasn't IBM and it was faster than both when it
> hit
> > >   the street?
> > With a 10 MHz clock.
>
> Impressive.
>
> > It had several *cool* OSes, but really only two major ones for general
> > consumption (Special Systems Dvision had several more).  SCOPE (later
> > NOS/BE), pretty much initially a PP-resident OS based on the old
> > Chippewa Operating System--and NOS (was KRONOS, originally MACE),
>
> I tried to find some info on SCOPE, but it's very sparse. Did it have an
> interactive command line? What was your main "interface" to the OS?
>
> > started as a "bootleg" project by Greg Mansfield and (Dr.) Dave
> > Callender at Arden Hills.  (MACE stood for "(Greg) Mansfield's Answer to
> > Customer Engineering".
>
> Lots of great and interesting operating systems start as a reaction to the
> status quo or some idea they find abhorrent. UNIX and many variants
> certainly have. Ie.. Ken & Dennis working on side-projects while bored and
> demotivated by Multics, BSD guys reacting to AT clamping down, Linus
> reacting to his profs, Theo forking NetBSD, I could go on and on...
>
> UNIX: Born in rebellion.
>
> > Most batch programs written for SCOPE would run fine on MACE with few,
> > if any, modifications.
>
> Did Control Data sell both or was one from an alternative vendor?
>
> >  In retrospect, CDC keeping two operating systems (SCOPE was part of CPD
> > in Sunnyvale, while KRONOS stayed home in Arden Hillls) was probably a
> > strategic blunder, since much duplicate effort was wasted.  Eventually,
> > the two were merged into NOS (for Network Operating System).
>
> I found this PDF:
>
>
> http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/nos/60435400J_NOS_Version_1_Reference_Volume_1_Aug79.pdf
>
> It's interesting to me because of how "different" everything is. I'm not
> well versed in mainframe operating systems. It's interesting.
>
> > There aren't any alignment issues, since the CPU was only
> > word-addressable.  This was when a character was 6 bits (think IBM 709x,
> > UNIVAC 1100, etc.)  So a word with 10 characters was logical.
>
> I figured it was something like that, but I'm so used to 8-bit bytes and
> such. It takes a minute to adjust my thinking to a different base, but
> it's not that hard.
>
> > Given that PP words 12 bits (5 to a CM word) and there were 10 PPUs,
> > each executing at a speed 1/10th the CPU, it had a very pleasant sort of
> > symmetry.
>
> I suppose it doesn't matter as long as things factor out properly: no
> worries.
>
> > COMPASS was indeed advanced for its time, but then so was OS/360
> > assembly language.  Given that assembly was the lingua franca of system
> > programming, assemblers had to be good.  Most of the readability was due
> > to attention to detail by the programmer, not any particular language
> > feature.
>
> Well, the sample code I could find was particularly well put together by
> someone who knew they were doing. I'm a pretty poor ASM programmer, since
> the only one I ever put much effort into was for the M68k (which is really
> easy compared to some).  I've got a big crush on MIPS ASM but I never was
> any good with it. C ruined me. :-)
>
> > > ... Is super-readable, in fact, probably a bit more than several
> > > much-newer dialects on different platforms. There was one instruction
> > > "PROTECT" I found pretty interesting, too.
> > Where did you find that?  I've never heard of such an instruction.
>
> I was mistaken, it's only a control 

Re: LINC-8 and PDP-8 manuals

[Pontus Pihlgren]

Hmm, I'm thinking hard of what I should bring on saturday that might 
interrest you. This is right up my alley.

You already have one of each of what I own :D

/P

On Thu, Jun 23, 2016 at 07:20:13PM +0200, Mattis Lind wrote:
> I have been going through our library of documentation and found some items
> that are duplicates.
> 
> There are a LINC-8 programming manual, PDP-8 DecTape programming manual,
> PDP-8/L maintenance manual, PDP-8/e maintenance manual volume I and volume
> III.
> 
> http://i.imgur.com/YEAdnZV.jpg?1
> http://i.imgur.com/pvsypvY.jpg?1
> 
> Trade for something interesting!
> 
> Other things that is also for trade:
> 
> http://www.datormuseum.se/available
> 
> /Mattis

RE: CDC 6600 - Why so awesome?

[Rich Alderson]

From: Swift Griggs
Sent: Wednesday, June 22, 2016 6:46 PM

>On Wed, 22 Jun 2016, Rich Alderson wrote:

>> We have [a DD60] running at LCM, attached to an instance of dtCyber, the
>> 6000/Cyber simulator, via John Zabolitzky's Xilinx-based display adapter.
>> We're in the process of refurbing the one that came with the 6500, which
>> we may attach to the system at some point.

> Is that "Living Computer Museum" ? You are in Seattle, right? I'll stop by 
> for sure if I'm in the area. I'm in Denver.

That's correct.  We're building out the first floor of the building right
now (open during construction), for a grand reopening in early November.
The new exhibit space will take us beyond vintage systems to the important
work being done by their descendants.

A pointer to the web site is in my .sig, of course.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Forth for RSTS

[Paul Koning]

> On Jan 3, 2016, at 4:56 PM, Paul Koning  wrote:
> 
> ...
> This Forth implementation is a port of Fig-FORTH by John S. James, with some 
> RSTS-specific magic added.  I just realized the file header says that it is 
> in the public domain, so I suppose I should post the source...

Done.  Thanks to Al Kossow, it now lives on Bitsavers, in 
bits/DEC/pdp11/forth/forth.mac

This is the RSTS run-time system, from V9.6 and later.  I haven't tried 
building it on older versions; the comments say it works back to V7.2.  I don't 
remember why that version is mentioned.  Run time systems existed before then, 
though a few details did change over time.

The original version was for RSX and RT-11.  I did the RSTS port, and Kevin 
Herbert added some more stuff to it later on.  The biggest change is to make 
the vocabulary machinery match the ANSI Forth 83 standard, which allows for 
lots of separate vocabularies and arranging their search order.  This was 
needed to allow SDA to define a set of 32 bit replacements for the standard (16 
bit) arithmetic operators of native Forth, without getting itself all confused.

Build instructions are in the comments near the top of the file.  There's very 
little to it.

Enjoy.

paul

Re: two's complement, was Re: Now OT

[Lars Brinkhoff]

Paul Koning  writes:
> in the Electrologica machines (Dutch computers from the late 1950s to
> mid 1960s), double-length values are encoded with the sign bit
> replicated in each word.

The PDP-10 double integer format also duplicates the sign bit, but is
two's complement.

LINC-8 and PDP-8 manuals

[Mattis Lind]

I have been going through our library of documentation and found some items
that are duplicates.

There are a LINC-8 programming manual, PDP-8 DecTape programming manual,
PDP-8/L maintenance manual, PDP-8/e maintenance manual volume I and volume
III.

http://i.imgur.com/YEAdnZV.jpg?1
http://i.imgur.com/pvsypvY.jpg?1

Trade for something interesting!

Other things that is also for trade:

http://www.datormuseum.se/available

/Mattis

Re: two's complement, was Re: Now OT

[Chuck Guzis]

On 06/23/2016 09:09 AM, Paul Koning wrote:

> The CDC 6000 did that in part.  It has full 60 bit integer
> add/subtract, but multiply and divide are done using the floating
> point operations so they work only for numbers up to 47 bits.

The CYBER 200/STAR 100 limited integers to 48 (of 64) or 24 (of 32)
bits.  The same held for addresses (this was a bit-addressable machine).
 The upper 16 bits of a 64 bit word is reserved for exponents and lengths.

Integer instructions were available for adding and subtracting the lower
48 bits without affecting the upper 16.  Boolean operations, of course,
worked on all bits of a word.

If the user needed extended-precision binary (or decimal) arithmetic, he
could turn to the string instructions which provided 4-banger math on
integers up to 65KB in length.

--Chuck

Re: two's complement, was Re: Now OT

[Paul Koning]

> On Jun 23, 2016, at 12:11 PM, Paul Koning  wrote:
> 
> 
>> On Jun 23, 2016, at 12:07 PM, Al Kossow  wrote:
>> ...
>> I have also heard that 2s compliment was popular in shorter word length
>> machines because 1s compliment multiple precision arithmetic is a PITA
>> to implement.
> 
> That's true.  It certainly can be done and has been. But since one's 
> complement arithmetic uses end around carry, when you have multiple word you 
> have to defeat the word carry and instead do the carry around the whole 
> number.

Something to look into in the Electrologica machines (Dutch computers from 
the late 1950s to mid 1960s), double-length values are encoded with the sign 
bit replicated in each word.  I wonder if that makes this problem go away 
(entirely or mostly).

paul

Re: two's complement, was Re: Now OT

[Paul Koning]

> On Jun 23, 2016, at 12:07 PM, Al Kossow  wrote:
> ...
> I have also heard that 2s compliment was popular in shorter word length
> machines because 1s compliment multiple precision arithmetic is a PITA
> to implement.

That's true.  It certainly can be done and has been. But since one's complement 
arithmetic uses end around carry, when you have multiple word you have to 
defeat the word carry and instead do the carry around the whole number.

paul

Re: two's complement, was Re: Now OT

[Paul Koning]

> On Jun 23, 2016, at 11:17 AM, Chuck Guzis  wrote:
> 
> ...
> Of course, there were also machines that used the floating point
> facility for all arithmetic.  Integer computations is performed as a
> subset of floating-point.  This has the ramification that an integer
> does not occupy an entire word, but only part of it.

The CDC 6000 did that in part.  It has full 60 bit integer add/subtract, but 
multiply and divide are done using the floating point operations so they work 
only for numbers up to 47 bits.

The Electrologica X8 is yet another take on this.  There, the mantissa is 
viewed as an integer, and the normalization rule is to make the exponent as 
close to zero as possible without losing bits.  The consequence is that all 
integral values under 2**40 are represented as exponent zero and the mantissa 
equal to the number, which amounts to simply the integer representation of that 
number.  This makes conversion from float to integer rather easy (and of 
course, conversion in the other direction takes no code at all).

paul

Re: two's complement, was Re: Now OT

[Al Kossow]

On 6/23/16 8:17 AM, Chuck Guzis wrote:
> On 06/23/2016 07:31 AM, Paul Koning wrote:
> 
>> I have a copy of 1948 (!) lecture notes on computer design.  It
>> discusses one's complement and two's complement.  It points out the
>> advantage of two's complement (no two zeroes) but also the
>> disadvantage that negating is harder (requiring two steps).  In early
>> computers that was significant, which explains why you see one's
>> complement there.
> 
> There are also a few obscure bit-twiddling tricks that work in ones
> complement, but not in two's.
>

I have also heard that 2s compliment was popular in shorter word length
machines because 1s compliment multiple precision arithmetic is a PITA
to implement.

Re: two's complement, was Re: Now OT

[Paul Koning]

> On Jun 23, 2016, at 10:50 AM, Camiel Vanderhoeven  wrote:
> 
> ...
> There are many, many varieties of floating point formats. This page
> gives a nice overview: http://www.quadibloc.com/comp/cp0201.htm

Nice.  The CDC 6000 description isn't quite right (or not clear) because a 
negative float is formed by complementing the entire word, not just the 
mantissa part.

I'll feed the Electrologica details to the author of that page; they are 
different from everything shown there and have some interesting/useful 
properties.

paul

Re: two's complement, was Re: Now OT

[Chuck Guzis]

On 06/23/2016 07:31 AM, Paul Koning wrote:

> I have a copy of 1948 (!) lecture notes on computer design.  It
> discusses one's complement and two's complement.  It points out the
> advantage of two's complement (no two zeroes) but also the
> disadvantage that negating is harder (requiring two steps).  In early
> computers that was significant, which explains why you see one's
> complement there.

There are also a few obscure bit-twiddling tricks that work in ones
complement, but not in two's.

> Another interesting aspect where people may not be aware of how much
> variety existed is in the encoding of floating point numbers.  IEEE
> is now the standard, but PDP-11 users will remember the DEC format
> which is a bit different.  

And by the time you got to the VAX, the issue became *which* floating
point format? (D,E,F or G).

> CDC and IBM were different still.  The Dutch machine Electrologica X8
> had a particularly interesting approach (parts of which were adopted,
> many years later, by the IEEE standard).

IBM's S/360 FP format was a big weakness of that machine.
Single-precision 32-bit word with an exponent that indicated the power
of 16 (not 2) to be applied to the mantissa (i.e., normalizing the
mantissa only shifted to the nearest 4 bits, not 1).

CDC, on the other hand, dedicated 48 bits to the mantissa of
single-precision numbers,  In other words, CDC's single-precision was
roughly the equivalent of IBM's double-precision.

To the scientific community, this was a big selling point.

Of course, there were also machines that used the floating point
facility for all arithmetic.  Integer computations is performed as a
subset of floating-point.  This has the ramification that an integer
does not occupy an entire word, but only part of it.

--Chuck

Re: two's complement, was Re: Now OT

[Camiel Vanderhoeven]

On Thu, Jun 23, 2016 at 4:31 PM, Paul Koning  wrote:
>
> Another interesting aspect where people may not be aware of how much
> variety existed is in the encoding of floating point numbers.  IEEE
> is now the standard, but PDP-11 users will remember the DEC format
> which is a bit different.  CDC and IBM were different still.  The
> Dutch machine Electrologica X8 had a particularly interesting
> approach (parts of which were adopted, many years later, by the IEEE
> standard).

DEC floating point is still very much around, as VAX floating point.
Alpha had both IEEE and VAX floating point, and compilers on VMS
defaults to VAX floating point. On Itanium CPU's, the chip only has
IEEE floating point, but VAX floating point formats are provided by
the OS, and many customers still compile their code to use VAX
floating point formats.

There are many, many varieties of floating point formats. This page
gives a nice overview: http://www.quadibloc.com/comp/cp0201.htm

Camiel.

Re: CDC 6600 - Why so awesome?

[Toby Thain]

On 2016-06-23 3:20 AM, Lionel Johnson wrote:

...
I joined CDC in Melbourne, Aust in 1972, worked mostly on 3200 machines
- Didn't like the Cybers, but admired the horsepower. I could fix a
3200, every time, that was the best training I ever had, alone with my
machine in Hobart, I loved it. When that ended, got into PDP 3rd party
maint. Thus was a career made.
Lionel.




Hi Lionel

I heard that the Royal Melbourne Institute of Technology had a 6600? 
Presumably you worked on it?


--Toby

Re: two's complement, was Re: Now OT

[Paul Koning]

> On Jun 22, 2016, at 11:05 PM, Swift Griggs  wrote:
> 
> ...
> Just some internet bungholes on reddit. Brother, just remember, *you* 
> asked, and you can never get the time back:
> 
> https://www.reddit.com/r/programming/comments/d92jj/why_computers_use_twos_complement_to_represent/

Nice.

I have a copy of 1948 (!) lecture notes on computer design.  It discusses one's 
complement and two's complement.  It points out the advantage of two's 
complement (no two zeroes) but also the disadvantage that negating is harder 
(requiring two steps).  In early computers that was significant, which explains 
why you see one's complement there.

Another consideration which may have played a role is that with one's 
complement you need fewer instructions: bitwise complement serves both for 
Boolean logic and for negate, for example.

The "two zeroes" problem is handled best by using the CDC 6000 technique: it 
doesn't use an adder, but rather a subtractor (so adding is done by subtracting 
the complement).  If you do that -- an exercise for the student to demonstrate 
why -- the result will never be negative zero unless there were negative zeroes 
in the inputs.  In particular, adding x and -x will produce +0 for all x.

I just added a few more machines to the table in the Wikipedia article 
referenced by the comments you mentioned.  
https://en.wikipedia.org/wiki/Word_(computer_architecture)

Another interesting aspect where people may not be aware of how much variety 
existed is in the encoding of floating point numbers.  IEEE is now the 
standard, but PDP-11 users will remember the DEC format which is a bit 
different.  CDC and IBM were different still.  The Dutch machine Electrologica 
X8 had a particularly interesting approach (parts of which were adopted, many 
years later, by the IEEE standard).

paul

Re: CDC 6600 - Why so awesome?

[Lionel Johnson]

On 23/06/2016 2:38 AM, Brian Walenz wrote:

On Wed, Jun 22, 2016 at 12:01 PM, Noel Chiappa 
wrote:

Werner Buchholz (editor), "Planning a Computer System: Project Stretch",

 McGraw-Hill, New York, 1962


http://ed-thelen.org/comp-hist/IBM-7030-Planning-McJones.pdf



Speaking of books, there's also a CDC 6600 book:

   Jim E. Thornton, "Design of A Computer: The Control Data 6600",
 Scott, Foresman, Glenview, 1970


http://www.textfiles.com/bitsavers/pdf/cdc/6x00/books/DesignOfAComputer_CDC6600.pdf

(apologies for using the non-official link)

Really gotta do that Bibliography!

 Noel

Here's a Dr Dobbs article with a couple of pics. Takes me back.
http://www.drdobbs.com/control-data-6600-the-supercomputer-arri/184404102
I joined CDC in Melbourne, Aust in 1972, worked mostly on 3200 machines 
- Didn't like the Cybers, but admired the horsepower. I could fix a 
3200, every time, that was the best training I ever had, alone with my 
machine in Hobart, I loved it. When that ended, got into PDP 3rd party 
maint. Thus was a career made.

Lionel.

Re: PDP-11/40 modified to be a PDP-11/23

[COURYHOUSE]

now, there is a 11/23 I could love!  ---Ed#
 
 
In a message dated 6/22/2016 9:44:20 P.M. US Mountain Standard Time,  
glen.sl...@gmail.com writes:

BACKPLANE",
> so the operation is not so mysterious. I had  never seen a hex-wide Q-bus
> backplane before this.
>
>  There are some pictures of the system and the Q-Bus to 11/40 front  panel
> interface here:  
http://www.ricomputermuseum.org/Home/equipment/dec-pdp-1140
>

Re: CDC 6600 - Why so awesome?

[Chuck Guzis]

On 06/22/2016 06:15 PM, Paul Koning wrote:

> Slightly different.  A rolled out job was a file, containing the
> whole job state, including stuff like currently attached files,
> memory content, exchange package (program registers).  Like any other
> "local file" it would show up in memory as an entry in the file table
> -- just 2 60-bit words if I remember right.  When selected by one of
> the scheduler components to be run again, it would be assigned a
> control point, memory, rolled back in, and execution resumed.

Yes, it was a file, but it still occupied a control point--at least it
did under SCOPE.

On CYBER 200 SOS, each controlee maintained a "drop file", which held
modified pages, the "invisible package"  and file information, so that a
job could be stopped and restarted any time later by the user.
Of course, we also had memory-mapped files.

> Jobs could also be moved in memory without being rolled out; this
> could happen if they or some other job changed memory size, forcing
> something to move to make room.  PPU programs would have to watch out
> for that to happen and "pause for storage relocation".  Getting that
> wrong was a great way to wedge the OS; I've got that t-shirt...

Basic memory management that I referred to.  Initially, under SCOPE,
this was pretty much the only OS task that the CPU took part
in--"storage move", as moving memory was much faster if done by the CPU
than PPUs.  If you had a 6600, you could do it with a simple in-stack
loop that moved two words per iteration with no wasted cycles.

If you had a 6400/Cyber 73, you could use the CMU (Cyber) or ECS if
available.  That was the only way to keep memory busy on the lower Cybers.

Performance was always an issue.   When SCOPE 3.4 came out, a new CIO
request was introduced for the benefit of the the loader.  You presented
CIO with a request "Read List String", which was nothing more than a
linked list of disk addresses (well, RBT numbers) which were passed to
1SP, and 1SP would do its best to keep the program's read buffer full.
It made for very fast loader operation.   Unfortunately, some wiseacre
decided that he could keep adding to the list of addresses and keep 1SP
busy forever--which meant that any disk-resident PP code, such as 1EJ
couldn't be loaded either.  Fortunately, a fix was easy--simply have 1SP
drop any too-long requests back into the queue.

That business with a PP not being able to do I/O on a job with a storage
move pending was one reason that we had to write our own 844 servicing
program for Zodiac--DBD.  All buffers were permanently allocated in CM
and data moved in an out of those.

I think that 1SP--the SCOPE "stack processor" was one area where SCOPE
and KRONOS differed significantly.  On SCOPE, pending requests were
sorted according to priority based on nearness to the current disk
position and the number of times it had been passed over for a more
favorable request.  From my discussions with Greg, I seem to recall that
KRONOS processed disk requests on a first-come, first-served basis.

--Chuck