Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #212313 > unrolled thread

DEC

Back to article view | Back to alt.folklore.computers

Contents

  DEC Iron Spring Software <Peter_Flass@Yahoo.com> - 2020-07-24 09:38 -0700
    Re: DEC Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-07-24 17:12 -0300
    Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 17:14 -0400
      Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-24 19:43 -0700
        Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 23:28 -0400
      Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:06 -0700
        Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 05:27 -0400
          Re: DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 10:58 +0100
            Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-25 17:21 +0000
              Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 13:54 -0400
                Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 14:43 -0700
                  Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 18:05 -0400
                    Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 20:27 -0400
                      Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 21:08 -0400
                        Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:29 -0400
                          Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:30 -0400
                          Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 00:06 -0400
                            Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-05 06:06 +0000
                              Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-07 10:19 -0400
                                Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-07 20:01 +0000
                                  Re: wiki software, not 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-08-07 22:45 +0000
                                    Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-08 13:35 -0400
                                      Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 15:33 +0000
                                        Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 13:16 -0400
                                          Re: wiki software, not 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-08-09 15:00 -0400
                                            Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:35 -0400
                                              Re: wiki software, not 360 PCs was DEC maus <maus@dmaus.org> - 2020-08-10 23:10 +0000
                                          Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 19:18 +0000
                                            Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:40 -0400
                                          Re: wiki software, not 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-09 15:30 -0700
                      Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
                        Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:43 -0700
                        Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:32 -0400
                      Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 21:45 +0000
                        Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 18:01 -0400
                          Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 06:38 +0100
                    Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 01:24 +0000
                      Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
                        Re: 360 PCs was DEC Bob Eager <news0073@eager.cx> - 2020-07-26 20:18 +0000
              Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 19:39 +0100
          Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 12:50 -0700
    Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:26 -0700
    Re: DEC usenet@only.tnx (Questor) - 2020-07-26 19:23 +0000
      Re: DEC Thomas Koenig <tkoenig@netcologne.de> - 2020-07-26 21:05 +0000
      Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-26 16:23 -0700
        Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 21:24 -0400
          Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
        Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 02:41 +0000
          Re: DEC archaeology Andy Burns <usenet@andyburns.uk> - 2020-07-27 07:37 +0100
            Re: DEC archaeology Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 07:10 +0000
              Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 09:03 +0100
                Re: DEC archaeology Michael LeVine <mlevinespmfltr@redshift.com> - 2020-07-27 02:09 -0700
                  Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 11:27 +0100
                Origin of Niven/Pournelle quips (was: DEC archaeology) Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 12:22 +0000
                  Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Rich Alderson <news@alderson.users.panix.com> - 2020-07-27 20:51 -0400
                    Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 06:02 +0100
                      Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 08:29 +0000
                        Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
                          Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 18:18 +0000
                            Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 19:57 +0000
                              Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 21:32 +0100
                                Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 21:34 +0000
                                  Re: Origin of Niven/Pournelle quips (was: DEC archaeology) J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:33 -0400
                          Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 20:55 +0100
            Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 14:53 +0000
              Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-27 11:30 -0500
              Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-27 16:37 +0000
                Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-28 10:24 -0500
                  Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-28 15:59 +0000
          Re: DEC archaeology Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
            Re: DEC archaeology J. Clarke <jclarke.873638@gmail.com> - 2020-07-27 18:47 -0400
            Re: DEC archaeology Quadibloc <jsavard@ecn.ab.ca> - 2020-07-27 17:43 -0700
        Re: DEC usenet@only.tnx (Questor) - 2020-07-28 03:21 +0000
          Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
          Re: ou sont les ordinateurs d'antan, was DEC John Levine <johnl@taugh.com> - 2020-07-28 20:27 +0000
            Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:53 -0400
              Re: ou sont les ordinateurs d'antan, was DEC Gareth Evans <headstone255@yahoo.com> - 2020-07-29 10:36 +0100
                Re: ou sont les ordinateurs d'antan, was DEC Andreas Eder <a_eder_muc@web.de> - 2020-08-02 12:55 +0200
                  Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-02 12:49 -0400
              Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:08 -0700
            Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:04 -0700
          Re: DEC Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2020-07-30 03:49 -0600
            Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 14:41 +0000
              Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 10:12 -0700
                Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 18:40 +0000
                  Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 12:02 -0700
                    Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-07-31 02:38 -0700
                      Re: DEC large computers John Levine <johnl@taugh.com> - 2020-07-31 20:21 +0000
                        Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-07-31 23:23 +0000
                          Re: DEC large computers J. Clarke <jclarke.873638@gmail.com> - 2020-07-31 21:13 -0400
                            Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-08-01 10:39 +0000
                          Re: vectors, was DEC large computers John Levine <johnl@taugh.com> - 2020-08-01 02:21 +0000
                            Re: vectors, was DEC large computers Bob Eager <news0073@eager.cx> - 2020-08-01 11:14 +0000
                        Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-07-31 20:30 -0700
                          Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 00:00 -0400
                            Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:20 -0700
                              Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 07:00 -0700
                                Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 08:18 -0700
                                  Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 11:52 -0400
                                    Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-02 21:58 +0000
                                      Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-02 18:50 -0400
                                        Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
                                          Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 13:34 -0700
                          Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:55 -0700
                            Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:27 -0700
                              Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 17:27 +0000
                                Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 12:11 -0700
                                Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 19:56 +0000
                                  Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 20:18 +0000
                                    Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 23:42 +0000
                                    Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:32 -0700
                                    Re: IBM models 91, 195 & CDC 7600 Gerard Schildberger <gerard46@rrt.net> - 2020-08-02 12:58 -0700
                                  Re: IBM models 91, 195 & CDC 7600 J. Clarke <jclarke.873638@gmail.com> - 2020-08-01 16:28 -0400
                                    Re: IBM models 91, 195 & CDC 7600 David Lesher <wb8foz@panix.com> - 2020-08-02 20:42 +0000
                                Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:27 -0700
                                Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-02 00:28 -0700
                                  Re: IBM models 91, 195 & CDC 7600 Thomas Koenig <tkoenig@netcologne.de> - 2020-08-02 08:01 +0000
                                  Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:47 -0700
                                    Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 19:45 -0700
                                  Re: IBM models 91, 195 & CDC 7600 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-08-03 21:00 -0600
                                Re: IBM models 91, 195 & CDC 7600 scott@slp53.sl.home (Scott Lurndal) - 2020-08-02 22:45 +0000
                                  Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
                          Re: IBM models 91, 195 & CDC 7600 "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-01 08:24 +0000
                            Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:30 -0700
                            Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:34 -0700
                        Re: DEC large computers Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:51 -0700
                          Re: DEC large computers robin.vowels@gmail.com - 2020-08-01 02:23 -0700
                      Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-07-31 21:16 -0400
                        Re: Jupiter alternatives [was Re: DEC] Robert Swindells <rjs@fdy2.co.uk> - 2020-08-01 01:56 +0000
                          Re: Jupiter alternatives [was Re: DEC] Adam Sampson <ats@offog.org> - 2020-08-01 15:59 +0100
                            Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:09 -0400
                          Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:07 -0400
                      Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
                        Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-02 23:54 -0700
                          Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
                            Re: DEC robin.vowels@gmail.com - 2020-08-03 09:16 -0700
                              Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 10:10 -0700
                                Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 10:35 -0700
                            Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:28 -0700
                              Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 21:26 +0000
                                Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:38 -0700
                                  Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-03 21:44 -0400
                                    Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 23:55 -0700
                                      Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-04 08:05 -0400
                                        Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-04 08:59 -0400
                                          Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 06:29 -0700
                                            Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-04 07:48 -0700
                                            Re: DEC Niklas Karlsson <anksil@yahoo.se> - 2020-08-05 04:13 +0000
                                              Re: DEC robin.vowels@gmail.com - 2020-08-04 22:45 -0700
                                                Re: DEC JimP <chucktheouch@gmail.com> - 2020-08-05 12:33 -0500
                                                  Re: DEC "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-05 19:31 +0000
                                              Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 22:57 -0700
                                                Re: DEC Bob Eager <news0073@eager.cx> - 2020-08-05 08:13 +0000
                                                  Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-05 10:58 -0700
                                            Re: DEC drb@ihatespam.msu.edu (Dennis Boone) - 2020-08-05 13:28 -0500
                                              Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-06 16:21 -0700
                          Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
                            Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:31 -0700
                              Re: DEC danny burstein <dannyb@panix.com> - 2020-08-03 18:38 +0000
                            Re: DEC "m. thompson" <michael.99.thompson@gmail.com> - 2020-08-04 05:38 -0700
                              Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-04 18:54 +0000
                    Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
                  Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-30 13:29 -0700
            Re: DEC usenet@only.tnx (Questor) - 2020-07-30 20:27 +0000

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

#212509 — Re: IBM models 91, 195 & CDC 7600

John Levine <johnl@taugh.com> writes:
>In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>,
> <robin.vowels@gmail.com> wrote:
>>On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote:
>>> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote:
>>> > the fact that CDC had 65 characters stored in
>>> > 6-bits.
>>> 
>>> At first I thought that meant they had a 390 bit word, but then I realized that 
>>> what was meant was that... they were using a double-byte character set?
>>
>>No; characters were only 6 bits.
>
>How do you store 65 characters in 6 bits?

I believe that he meant that the character _set_ could only include
64 values (2^6).

[toc] | [prev] | [next] | [standalone]

#212517 — Re: IBM models 91, 195 & CDC 7600

Scott Lurndal <scott@slp53.sl.home> wrote:
> John Levine <johnl@taugh.com> writes:
>> In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>,
>> <robin.vowels@gmail.com> wrote:
>>> On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote:
>>>> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote:
>>>>> the fact that CDC had 65 characters stored in
>>>>> 6-bits.
>>>> 
>>>> At first I thought that meant they had a 390 bit word, but then I realized that 
>>>> what was meant was that... they were using a double-byte character set?
>>> 
>>> No; characters were only 6 bits.
>> 
>> How do you store 65 characters in 6 bits?
> 
> I believe that he meant that the character _set_ could only include
> 64 values (2^6).
> 

You can store lots of data in one bit. RETRIEVAL, however, is a bit more
difficult. ;-)

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212475 — Re: IBM models 91, 195 & CDC 7600

On Sat, 01 Aug 2020 03:30:31 GMT, robin.vowels@gmail.com wrote:

[]
> The problems with the 7600 were lack of software,
> and in the fact that it did not have character-handling
> instructions.
> Plus the silly integer multiplication instruction,
> plus the fact that CDC had 65 characters stored in
> 6-bits.

How did they manage that?

[]
https://en.wikipedia.org/wiki/CDC_7600
says 65k words main memory with a 60bit word.

-- 
Bah, and indeed, Humbug.

[toc] | [prev] | [next] | [standalone]

#212479 — Re: IBM models 91, 195 & CDC 7600

On Saturday, August 1, 2020 at 6:24:42 PM UTC+10, Kerr-Mudd,John wrote:
> On Sat, 01 Aug 2020 03:30:31 GMT, r......@gmail.com wrote:
> 
> []
> > The problems with the 7600 were lack of software,
> > and in the fact that it did not have character-handling
> > instructions.
> > Plus the silly integer multiplication instruction,
> > plus the fact that CDC had 65 characters stored in
> > 6-bits.
> 
> How did they manage that?

By declaring that :: represented a new line.
Thus, if the output contained the characters ::
you got a superfluous line feed, and the remainder
of the line was printed on the next line.

[toc] | [prev] | [next] | [standalone]

#212480 — Re: IBM models 91, 195 & CDC 7600

On Saturday, August 1, 2020 at 6:24:42 PM UTC+10, Kerr-Mudd,John wrote:
> On Sat, 01 Aug 2020 03:30:31 GMT, r......@gmail.com wrote:
> 
> []
> > The problems with the 7600 were lack of software,
> > and in the fact that it did not have character-handling
> > instructions.
> > Plus the silly integer multiplication instruction,
> > plus the fact that CDC had 65 characters stored in
> > 6-bits.
> 
> How did they manage that?

By declaring that :: represented a new line.
Thus, if the output contained the characters ::
you got a superfluous line feed, and the remainder
of the line was printed on the next line.

The double colon (::) was not printed, so the unsuspecting user
lost some output.

[toc] | [prev] | [next] | [standalone]

#212473 — Re: DEC large computers

Quoted from a post by Terry Kennedy that didn't contain it:

> > IBM cut the price of the Stretch in half for both existing customers
> >and open orders (taking a loss on each one) and discontinued it after all open orders had been fulfilled.

Whoever wrote this... there are some additional details needed.

It is true that the STRETCH did not meet its original performance goals. The 
price cut, however, was not necessitated either by the terms of IBM's contracts 
with its  customers, or because the customers would not have accepted the 
computers at their original price with the reduced performance.

Particularly as IBM customer engineers eventually got the 7030s in the field to 
meet the original performance goal.

And even if IBM did feel an obligation to cut the price to those who already had 
the machine on order, nothing prevented it from continuing to offer more 7030 
computers at tge profitable original price; it is likely there would still have 
been demand, as at that performance level there was little competition.

The decision to cut the price in direct proportion to the performance deficit 
_and_ discontinue sales and production was made by Watson in a fit of pique; it 
was an emotional decision because he was angry at the engineers who had failed 
him, not a rational business decision.

John Savard

[toc] | [prev] | [next] | [standalone]

#212477 — Re: DEC large computers

On Saturday, August 1, 2020 at 5:51:30 PM UTC+10, Quadibloc wrote:
> Quoted from a post by Terry Kennedy that didn't contain it:
> 
> > > IBM cut the price of the Stretch in half for both existing customers
> > >and open orders (taking a loss on each one) and discontinued it after all open orders had been fulfilled.
> 
> Whoever wrote this... there are some additional details needed.
> 
> It is true that the STRETCH did not meet its original performance goals. The 
> price cut, however, was not necessitated either by the terms of IBM's contracts 
> with its  customers, or because the customers would not have accepted the 
> computers at their original price with the reduced performance.

The price reduction was necessitated because a competitor produced
a machine with equivalent performance at a much lower price,
and IBM was obliged to match it.

> Particularly as IBM customer engineers eventually got the 7030s in the field to 
> meet the original performance goal.
> 
> And even if IBM did feel an obligation to cut the price to those who already had 
> the machine on order, nothing prevented it from continuing to offer more 7030 
> computers at tge profitable original price; it is likely there would still have 
> been demand, as at that performance level there was little competition.
> 
> The decision to cut the price in direct proportion to the performance deficit 
> _and_ discontinue sales and production was made by Watson in a fit of pique; it 
> was an emotional decision because he was angry at the engineers who had failed 
> him, not a rational business decision.

[toc] | [prev] | [next] | [standalone]

#212468 — Jupiter alternatives [was Re: DEC]

Terry Kennedy <terry-groups@glaver.org> writes:

> In retrospect, DEC might have been better served by canceling Jupiter but
> marketing one of the 3rd party compatible 36-bit CPUs as a DEC model.  This
> had been considered (and dismissed) when Jupiter was in the early planning
> stages.

"one of the 3rd party compatible" CPUs?  Which one would that be?  When Jupiter
was thought up, there was exactly 1 company making such systems, Foonly--and
every Foonly system was a prototype, according to a friend at SRI who had to
support an installation.  (Boards were not interchangeable.)

Systems Concepts marketed their competing system with Fred Wright's memorable
statement that "Mars may be smaller than Jupiter, but it's a lot closer."  It
wasn't that much closer.  We took delivery of the first customer ship--which
was Mike and Stewart's prototype mahcine!--at LOTS on All Hallows' Eve, 1986,
three and a half years after the Jupiter cancellation.

And the SC-30M was not a Jupiter class machine (as the latter was planned,
although it was probalby a little faster than what was getting built).  The
entire point of Mars was a KL-10 clone which was bug-for-bug compatible but
simply faster, built with TTL instead of ECL.  They even created Massbus and CI
interfaces to meet the LOTS requirements.

It's a hell of a nice system, but it's not what KL-10 customers were looking
for in the Jupiter.

Cisco never got started on building the ToaD, so they weren't in the running,
and XKL was founded in December 1990.  The Toad-1 System was delivered to our
first customers in 1995, more than a decade after the Jupiter cancellation, and
it's in the same speed class as, and a little faster than, SC's Mars.  It's
just a whackingly great space reduction on the original with modern (for 1995)
peripherals instead of clinging to Massbus.

NB: The SC-40, the engine which Mike and Stewart licensed to CI$ to build for
    themselves, is roughly the same as the SC-30M, with a superspeed floating
    point processor built in for roughly 10x improvement over the KL-10 on the
    relevant benchmarks.

The only other possibility which even existed when Jupiter was a going concern
was MAXC, a one-off (well, two-off) purpose built clone at Xerox PARC, which
existed only because Xerox management would not buy a DECsystem-10 for the
scientists at PARC to run TENEX on.  It was even further from a commercial
possibility than the Foonly systems.

So I repeat:  Who are you talking about?

-- 
Rich Alderson					  news@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

[toc] | [prev] | [next] | [standalone]

#212469 — Re: Jupiter alternatives [was Re: DEC]

On Fri, 31 Jul 2020 21:16:08 -0400, Rich Alderson wrote:

> Terry Kennedy <terry-groups@glaver.org> writes:
> 
>> In retrospect, DEC might have been better served by canceling Jupiter
>> but marketing one of the 3rd party compatible 36-bit CPUs as a DEC
>> model.  This had been considered (and dismissed) when Jupiter was in
>> the early planning stages.
> 
> "one of the 3rd party compatible" CPUs?  Which one would that be?  When
> Jupiter was thought up, there was exactly 1 company making such systems,
> Foonly--and every Foonly system was a prototype, according to a friend
> at SRI who had to support an installation.  (Boards were not
> interchangeable.)

Maybe Foonly was a possibility:

<http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/
memos/uhler_Impressions_from_a_visit_to_Foonly_19830719.pdf>

[toc] | [prev] | [next] | [standalone]

#212484 — Re: Jupiter alternatives [was Re: DEC]

Robert Swindells <rjs@fdy2.co.uk> writes:

> Maybe Foonly was a possibility:
>
> <http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/
> memos/uhler_Impressions_from_a_visit_to_Foonly_19830719.pdf>

And there's also a memo in there from a few months earlier about
discussions with Systems Concepts:

http://bitsavers.org/pdf/dec/pdp10/KC10_Jupiter/memos/uhler_A_Systems_Concepts_PDP-10_Mar83.pdf

-- 
Adam Sampson <ats@offog.org>                         <http://offog.org/>

[toc] | [prev] | [next] | [standalone]

#212494 — Re: Jupiter alternatives [was Re: DEC]

Adam Sampson <ats@offog.org> writes:

> Robert Swindells <rjs@fdy2.co.uk> writes:

>> Maybe Foonly was a possibility:

>> <http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/
>> memos/uhler_Impressions_from_a_visit_to_Foonly_19830719.pdf>

> And there's also a memo in there from a few months earlier about
> discussions with Systems Concepts:

> http://bitsavers.org/pdf/dec/pdp10/KC10_Jupiter/memos/uhler_A_Systems_Concepts_PDP-10_Mar83.pdf

And did you read what I wrote about SC?  Mike and Stewart are friends of mine.
That doesn't blind me to the fact that they did not deliver a system until
years after the Jupiter cancellation.

Did you bother to read what I wrote?

-- 
Rich Alderson					  news@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

[toc] | [prev] | [next] | [standalone]

#212493 — Re: Jupiter alternatives [was Re: DEC]

Robert Swindells <rjs@fdy2.co.uk> writes:

> On Fri, 31 Jul 2020 21:16:08 -0400, Rich Alderson wrote:

>> Terry Kennedy <terry-groups@glaver.org> writes:

>>> In retrospect, DEC might have been better served by canceling Jupiter
>>> but marketing one of the 3rd party compatible 36-bit CPUs as a DEC
>>> model.  This had been considered (and dismissed) when Jupiter was in
>>> the early planning stages.

>> "one of the 3rd party compatible" CPUs?  Which one would that be?  When
>> Jupiter was thought up, there was exactly 1 company making such systems,
>> Foonly--and every Foonly system was a prototype, according to a friend
>> at SRI who had to support an installation.  (Boards were not
>> interchangeable.)

> Maybe Foonly was a possibility:

> <http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp10/KC10_Jupiter/
> memos/uhler_Impressions_from_a_visit_to_Foonly_19830719.pdf>

You quote a paragraph which tells you why Foonly was only a theoretical
possibility.  Did you actually read why I wrote?

-- 
Rich Alderson					  news@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

[toc] | [prev] | [next] | [standalone]

#212513

On Fri, 31 Jul 2020 02:38:12 -0700 (PDT), Terry Kennedy
<terry-groups@glaver.org> wrote:
>On Thursday, July 30, 2020 at 3:02:23 PM UTC-4, Peter Flass wrote:
>>The VAX certainly had more growth potential, maybe DEC really couldn't
>>afford to support both the VAX and the -10, at any level of support, maybe
>>the -10 people screwed up their next-generation design badly enough to make
>>it much too late to market. We've heard all those, possibly any or all are
>>correct. For sure most of the VAX people are still around, is there
>>anything like Bell's article on PDP-11 around for the VAX?

I'd say that Mr. Kennedy's recollections below are pretty much spot on.
LSG = Large Systems Group, largely responsible for high-end hardware


>DEC had 2 LSG projects going at the same time and both foundering - the VAX
>-11/790 (released as the 8600) and the 36-bit Jupiter project. They apparently
>decided to focus on the 8600, even though it didn't meet its performance
>goals (but by a smaller amount than Jupiter). By the time the 8600 project
>got told "ship it now or else" they were very very close to meeting their
>original performance goal - upgrading an 8600 to an 8650 was a simple 2 board
>swap. The "mid-life kicker" to upgrade the 8650 (which, remember, was the
>original performance target for the 8600) would likely have been the 8670
>but never got anywhere as a project.
>
>But DEC badly misjudged the 36-bit community's response to the Jupiter
>cancellation - as one university put it, "all new systems will be Unix-based
>because we will have a much wider choice of vendors to screw us".

Yep.  If you're going to have to re-write your software anyway to move to a new
machine, it opens up your choices beyond your existing vendor.  DEC did sell
VAXes to some of its PDP-10 customers, and many of those customers ran Unix
instead of VMS.


>Meanwhile, LSG continued their tradition of building ever larger systems out
>of esoteric hardware that were late to market and under-performing, like
>the VAX 9000. The blame can't be laid solely at LSG's feet - DEC upper
>management refused to believe that their in-house semiconductor group could
>fabricate a chip (the NVAX) that outperformed the 9000. And how do you tell your
>customers that just bought a hugely expensive and large computer that there
>is another model with better performance, a much smaller form factor, and
>vastly reduced power consumption? IBM cut the price of the Stretch in half
>for both existing customers and open orders (taking a loss on each one)
>nd discontinued it after all open orders had been fulfilled. DEC didn't have
>the resources to take a financial hit like that, and it would still have
>saddled the 9000 customers with oversized power-hungry boxes.
>
>In retrospect, DEC might have been better served by canceling Jupiter but
>marketing one of the 3rd party compatible 36-bit CPUs as a DEC model. This
>had been considered (and dismissed) when Jupiter was in the early planning
>stages. I guess the "we've gone this far, we may as well keep going" (AKA the
>sunk cost fallacy) convinced them to keep going long after they should have
>changed strategy.

Also there was a strong resistance by management to selling anything that wasn't
made in-house.  DEC wanted to "do it all," and be a one-stop vendor for all
computing needs.

This web page has a couple of dozen answers to the question, "why did DEC fail?"
mostly by former DEC employees.  I recommend it.  Reading all the replies will
reveal several different themes and give a clearer picture of what went wrong.
As is usually the case with a company the size of DEC, "it's complicated."

http://www.quora.com/Why-did-Digital-Equipment-Corporation-DEC-fail

[toc] | [prev] | [next] | [standalone]

#212514

On Sunday, August 2, 2020 at 8:34:24 PM UTC-4, Questor wrote:
> Also there was a strong resistance by management to selling anything that wasn't
> made in-house.  DEC wanted to "do it all," and be a one-stop vendor for all
> computing needs.

DEC did quite well sourcing their high end disk and tape products from other manufacturers. The RM02/3/5 and RP06/7 drives were fine products from CDC and Memorex, respectively. Didn't DEC drop 36-bit support from the RAxx series in-house drives after the RA81 (or maybe the RA80)? The TU77/78/79 were wonderful drives. Most of the bad reputation of the TU78 was due to the TM78 formatter which was done by DEC, along with failing to implement changes from the drive manufacturer as FCOs. Here's a trivia question for you - what are the 3 small rectangular indentations in the TU79's door for? The answer is for channel and unit numbers (like 280) for the IBM-compatible market. By that time DEC wasn't buying enough drives to be able to convince the manufacturer to do a custom door for them.

My point being that the disk and tape peripherals for a Jupiter class system would likely have been non-DEC with DEC badges, so doing that for the CPU as well may not have been such a reach.

[toc] | [prev] | [next] | [standalone]

#212518

Terry Kennedy <terry-groups@glaver.org> wrote:
> On Sunday, August 2, 2020 at 8:34:24 PM UTC-4, Questor wrote:
>> Also there was a strong resistance by management to selling anything that wasn't
>> made in-house.  DEC wanted to "do it all," and be a one-stop vendor for all
>> computing needs.
> 
> DEC did quite well sourcing their high end disk and tape products from
> other manufacturers. The RM02/3/5 and RP06/7 drives were fine products
> from CDC and Memorex, respectively. Didn't DEC drop 36-bit support from
> the RAxx series in-house drives after the RA81 (or maybe the RA80)? The
> TU77/78/79 were wonderful drives. Most of the bad reputation of the TU78
> was due to the TM78 formatter which was done by DEC, along with failing
> to implement changes from the drive manufacturer as FCOs. Here's a trivia
> question for you - what are the 3 small rectangular indentations in the
> TU79's door for? The answer is for channel and unit numbers (like 280)
> for the IBM-compatible market. By that time DEC wasn't buying enough
> drives to be able to convince the manufacturer to do a custom door for them.
> 
> My point being that the disk and tape peripherals for a Jupiter class
> system would likely have been non-DEC with DEC badges, so doing that for
> the CPU as well may not have been such a reach.
> 

One of their printers for the VAX was second-sourced, and also a terrific
printer. Forget the model number after 30+ yers, but it was a band printer.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212519

On Tuesday, August 4, 2020 at 12:45:35 AM UTC+10, Peter Flass wrote:
> Terry Kennedy <t......@glaver.org> wrote:
> > On Sunday, August 2, 2020 at 8:34:24 PM UTC-4, Questor wrote:
> >> Also there was a strong resistance by management to selling anything that wasn't
> >> made in-house.  DEC wanted to "do it all," and be a one-stop vendor for all
> >> computing needs.
> > 
> > DEC did quite well sourcing their high end disk and tape products from
> > other manufacturers. The RM02/3/5 and RP06/7 drives were fine products
> > from CDC and Memorex, respectively. Didn't DEC drop 36-bit support from
> > the RAxx series in-house drives after the RA81 (or maybe the RA80)? The
> > TU77/78/79 were wonderful drives. Most of the bad reputation of the TU78
> > was due to the TM78 formatter which was done by DEC, along with failing
> > to implement changes from the drive manufacturer as FCOs. Here's a trivia
> > question for you - what are the 3 small rectangular indentations in the
> > TU79's door for? The answer is for channel and unit numbers (like 280)
> > for the IBM-compatible market. By that time DEC wasn't buying enough
> > drives to be able to convince the manufacturer to do a custom door for them.
> > 
> > My point being that the disk and tape peripherals for a Jupiter class
> > system would likely have been non-DEC with DEC badges, so doing that for
> > the CPU as well may not have been such a reach.
> > 
> 
> One of their printers for the VAX was second-sourced, and also a terrific
> printer. Forget the model number after 30+ yers, but it was a band printer.

Memorex made band printers.
So did GE.

[toc] | [prev] | [next] | [standalone]

#212520

On Monday, August 3, 2020 at 10:16:13 AM UTC-6, robin...@gmail.com wrote:
> On Tuesday, August 4, 2020 at 12:45:35 AM UTC+10, Peter Flass wrote:
 
> > One of their printers for the VAX was second-sourced, and also a terrific
> > printer. Forget the model number after 30+ yers, but it was a band printer.

> Memorex made band printers.
> So did GE.

I think Dataproducts and Manessman/TALLY did too.

John Savard

[toc] | [prev] | [next] | [standalone]

#212521

Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Monday, August 3, 2020 at 10:16:13 AM UTC-6, robin...@gmail.com wrote:
>> On Tuesday, August 4, 2020 at 12:45:35 AM UTC+10, Peter Flass wrote:
>  
>>> One of their printers for the VAX was second-sourced, and also a terrific
>>> printer. Forget the model number after 30+ yers, but it was a band printer.
> 
>> Memorex made band printers.
>> So did GE.
> 
> I think Dataproducts and Manessman/TALLY did too.
> 

This might have been a Dataproducts. Might have been an LP27. When I went
to look it up I found one on Ebay for $300.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#212524

On Monday, August 3, 2020 at 10:45:35 AM UTC-4, Peter Flass wrote:
> One of their printers for the VAX was second-sourced, and also a terrific
> printer. Forget the model number after 30+ yers, but it was a band printer.

LP25/LP26 were Dataproducts B300/B600. The DEC version was much nicer* in that
you could rest printouts or other things on the nice flat cover instead of the
Dataproducts clamshell cover.

* Unless the gas shocks went bad, in which case the cover would slam down on
your head while you were doing something inside.

DEC also used the Dataproducts 2230/2260 (and maybe 2290) drum printers as 
older LPxx models. If you see a printout where the characters on one line
are randomly shifted up or down, that's always a badly aligned drum printer.

To address another poster's comment of finding one on eBay, you will abso-
lutely have to replace the "ribbon stuffer" roller. If left in the latched
(in-use position) it will have flat-spotted. Even if it was in the open pos-
ition, the solvent in the ribbon ink will have turned the 3 rubber "donuts"
to mush. If you really want to buy one, take a look at the paper feed pins
on the side sprocket wheels. If the wheels / pins are not chromed, don't buy
it. This was an ECO because paper eventually wore grooves into the plain
black sprockets, to the point they would not let go of the paper holes and
lead to paper jams.

[toc] | [prev] | [next] | [standalone]

#212529

On 2020-08-03, Terry Kennedy <terry-groups@glaver.org> wrote:

> On Monday, August 3, 2020 at 10:45:35 AM UTC-4, Peter Flass wrote:
>
>> One of their printers for the VAX was second-sourced, and also a terrific
>> printer. Forget the model number after 30+ yers, but it was a band printer.
>
> LP25/LP26 were Dataproducts B300/B600. The DEC version was much nicer* in that
> you could rest printouts or other things on the nice flat cover instead of the
> Dataproducts clamshell cover.

The Univac 773 printer's top cover was fiendishly designed to be close enough
to level that you could set printouts on it, but slanted just enough that
they would slide off onto the floor as soon as you turned your back.

> * Unless the gas shocks went bad, in which case the cover would slam down on
> your head while you were doing something inside.

Ouch.  Fortunately I never saw a gas shock go bad.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [prev] | [next] | [standalone]

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web